Conversion String vers char

Version imprimable

Bonjour,

Connaissez vous une méthode de l'API Java qui permette de convertir une chaine représentant un caractère en ce caractère ?

Une méthode qui ferait quelque chose comme ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
    public static char toChar(String s)
    {
        if (s == null)
            throw new NullPointerException("La chaîne ne doit pas être null");
 
        if (s.length() == 0)
            throw new IllegalArgumentException("La chaine ne doit pas être vide");
 
        if (s.equals("\\n"))
            return '\n';
 
        if (s.equals("\\t"))
            return '\t';
 
        // ...
 
        if (s.startsWith("\\u") && s.length() > 2)
            return (char) Integer.valueOf(s.substring(2), 16).intValue();
 
        return s.charAt(0);
    }

ou bien une meilleure manière de faire cela ?

Merci par avance.

29/03/2007, 10h49
willoi
la methode charAt :
Code:

1 2 String chaine="x"; char c=chaine.charAt(0);
29/03/2007, 11h06
LittleBean
Citation:
Envoyé par willoi

la methode charAt :

Code:

1 2 String chaine="x"; char c=chaine.charAt(0);
ça marche pas pour
Citation:
Code:

1 2 if (s.equals("\\n")) return '\n';
tu peux limiter la casse en utlilisant toCharArray() et les switch qui marchent avec char !
mais si tu veux gérer des char non simple \t .... je vois pas de solution en 2 lignes
29/03/2007, 11h11
Clorish

de toute facon cette fonction recherche ne fera rien de plus que ce que tu fais deja ..... ;)
Par contre rien ne t'empeche de te creer une classe "API" qui te met a disposition une bonne fois pour toutes cette api.

Si j'ai bien compris, le string "s" est toujours un caractère, que tu veux convertir en char ?
Code:

1 2 3 4 5 public static char toChar(String s) { // Traitement de sécurité (null, lenght, ...) return s.toCharArray()[0]; }

29/03/2007, 13h14
Clorish

Citation:

Si j'ai bien compris, le string "s" est toujours un caractère, que tu veux convertir en char ?

visiblement non.
Il a l'air de vouloir convertir aussi les carteres speciaux tels de "\n", "\t", etc ... qui prennent plusieurs caracteres dans une chaine "texturelle"

Je ne pense pas, d'après
Citation:
Envoyé par benwit
Code:

1 2 3 4 5 6 7 8 9 10 public static char toChar(String s) { if (s.equals("\\n")) return '\n'; if (s.equals("\\t")) return '\t'; return s.charAt(0); }
A mon avis, le string "s" est toujours une chaine comprenant un caractère et un seul. Et même si ce n'est pas le cas, ma méthode est plus simple :mrgreen:

29/03/2007, 17h30
benwit
Si vous regardez bien mon exemple, la chaîne s peut représenter aussi bien
- un caractère spécial tel que "\n", "\t" : (2 caractères),
- un caractère codé en unicode "\uxxxx" ou xxxx est la valeur hexadécimale (3 à 6 caractères)
- un simple caractère tel que "a" (1 caractère) - cas trivial -.
JohnNC, en quoi

Code:

s.toCharArray()[0]

est plus simple que

Code:

s.charAt(0);

?

Et en plus, aussi bien l'une que l'autre ne traite pas les cas partculiers :
"\n".toCharArray()[0] retourne '\' et "\n".toCharArray()[1] retourne 'n'
29/03/2007, 17h34
LittleBean

c'est ce que je t'ai dis tu peux pas couper à faire une fonction traitant tout les cas qui t'intéressent à l'aide de toCharArray() et des switch
29/03/2007, 17h49
benwit

C'est aussi ce que je pense : charAt(0) lorsque la chaine est de longueur 1, et tests pour les autres.
En revanche, le switch ne m'est d'aucune utilité (tant qu'il ne traitera pas les chaînes) !!!

Je voulais juste savoir si quelqu'un avait une autre idée (ne perdez pas votre temps à me redire ce qu'il y a dans mon exemple ;) ).
Ce que je repproche à ma méthode, c'est d'oublier potentiellement certains caractères spéciaux ! Je vais rajouter \r, \f, ... mais j'en oublie surement ?
29/03/2007, 19h02
Clorish

Citation:

Envoyé par benwit

En revanche, le switch ne m'est d'aucune utilité (tant qu'il ne traitera pas les chaînes) !!!

Il traite les chaines ....
Suffit de creer un tableau de string ou liste quelconque contenant les chaines non unitaires et de recuperer l'index de l'element egal a la chaine passe en argument.
Je ne connait pas la syntaxe mais il me semble avoir vu un truc qui fait ca.

Le case s'applique donc sur l'index renvoyé.
C'ets une astuce Delphi qui n'accepte que des entier (meme pas des caracteres) dans ses cases.

autre astuce :

Code:

1
2
3
4
5
6
 
String specialChar = "\\n \\t";
switch specialChar.indexOf(s) {
    0 : // Traitement de "\\n"; 
    4 : // Traitement de "\\t";
[...]

29/03/2007, 19h37
benwit

ok pour ta 2° astuce si on supose qu'une des chaine n'est pas une sous chaine de l'autre (ce qui semble être le cas dans mon exemple) sinon il y aura des probléme avec le indexOf().

En en ce qui concerne le switch avec le tableau de string, je demande à voir l'implémentation (comment tu fais la comparaison ?)... car je crois avoir lu que justement la gestion des string dans le swicth (similaire au int, char et enum) est prévu pour une prochaine version de java.
29/03/2007, 19h51
Clorish
Citation:

Envoyé par benwit

ok pour ta 2° astuce si on supose qu'une des chaine n'est pas une sous chaine de l'autre (ce qui semble être le cas dans mon exemple) sinon il y aura des probléme avec le indexOf().

Bien sur .... ;)
Ce n'est qu'une astuce pas une technique de prog ;)
La difference reside dans les limites d'utilisation plus forte de la premiere :p

Citation:

Envoyé par benwit

En en ce qui concerne le switch avec le tableau de string, je demande à voir l'implémentation (comment tu fais la comparaison ?)... car je crois avoir lu que justement la gestion des string dans le swicth (similaire au int, char et enum) est prévu pour une prochaine version de java.
Code:

1 2 3 4 5 6 7 index = -1; for (i=0; i<tab.length; i++) if (tab[i].equals(s)) { index = i; break; } switch (index) { [...] }
:D
Tu peux aussi utiliser une list (avec des add et un "find" ou "getIndex") mais quoi qu'il arrive tu passe pas un "for".
Le mieux est d'externaliser le for dans une fonction qui renvoie l'index .... ca allege pas mal le code ;) (mieux qu'une serie de if)
29/03/2007, 21h03
benwit
Ok, je t'accorde qu'on peut dire d'une certaine manière qu'on peut gérer des strings dans un switch même si ce n'est pas encore de la manière classique (jdk 1.7 ?) :
Code:

1 2 3 4 5 6 switch(chaine) { case "c1" : case "c2" : ... }
Sinon, avec ta façon de faire (l'utilisation d'un tableau), quitte à le parcourir, je pense qu'on peut dès lors se passer du switch par la suite et utiliser l'équivalent d'un pointeur de fonction pour executer le code directement.

Autrement dit, en java, cela consisterait à avoir un tableau d'objet fonction qui contiendrait à la fois la chaine de comparaison et le code à executer (même si dans mon exemple, le code étant tellement léger qu'il ne justifie peut être pas la création d'objet fonction). ;)
29/03/2007, 21h23
Clorish

Citation:

Sinon, avec ta façon de faire (l'utilisation d'un tableau), quitte à le parcourir, je pense qu'on peut dès lors se passer du switch par la suite et utiliser l'équivalent d'un pointeur de fonction pour executer le code directement.

Si c'est pour faire ca .. autant garder la serie de IF ;)
Le but de telles choses et de clarifier le code, plus au niveau de la lisibilité que des performances.

ca sert pasa grand chose de faire des moteurs a faible conso si c'ets pour appuyer comme un bourrin derriere :D
29/03/2007, 23h26
JohnNC
Citation:
Envoyé par benwit

Si vous regardez bien mon exemple, la chaîne s peut représenter aussi bien

un caractère spécial tel que "\n", "\t" : (2 caractères),
un caractère codé en unicode "\uxxxx" ou xxxx est la valeur hexadécimale (3 à 6 caractères)
un simple caractère tel que "a" (1 caractère) - cas trivial -.

JohnNC, en quoi

Code:

s.toCharArray()[0]

est plus simple que

Code:

s.charAt(0);

?

Et en plus, aussi bien l'une que l'autre ne traite pas les cas partculiers :
"\n".toCharArray()[0] retourne '\' et "\n".toCharArray()[1] retourne 'n'
Alors ça, je demande à voir ! "\n" ne contient qu'un seul caractère, et non 2 !
"\n".toCharArray()[1] te sortira un indexArrayOutOfBoundException ! et "\n".toCharArray()[0] retournera '\n'.

P.S : Par contre, je n'avais pas vu que les "\\n" dans le string, auquel cas il y a bien 2 caractères là. J'étais parti sur un string ne contenant qu'un seul caractère, y compris caractères spéciaux.
30/03/2007, 10h05
benwit
JohnNC,
je me suis en effet trompé en écrivant, je voulais dire :

Code:

"\\n".toCharArray()[0] retourne '\' et "\\n".toCharArray()[1] retourne 'n'

Je sais que \n dans une chaine ne réprésente qu'un seul caractère mais si je tape les 2 caractères \n dans un JTextfield par exemple, texfield.getText().toCharArray()[0] retourne '\' et texfield.getText().toCharArray()[1] etourne 'n'
C'est pour cela que je me suis trompé car en écrivant directement la chaîne dans le code, j'ai oublié d'échappé la caractère \ comme je l'avais fait dans mon exemple.

Donc, si elle reste d'actualité (à toi de voir), je réitère ma question :
en quoi
Code:

1 2 3 4 5 6 s.toCharArray()[0] est plus simple que s.charAt(0);
?

Citation:

Si c'est pour faire ca .. autant garder la serie de IF
Le but de telles choses et de clarifier le code, plus au niveau de la lisibilité que des performances.

Clorish,
Je suis à peu près d'accord :
- dans mon cas, autant garder les if pour ce que je fais au lieu d'utiliser un tableau d'objets fonctions (moins clair).
- d'accord aussi sur le fait que ta proposition clarifie le code avec le switch de String :
switch(methodeQuiFaitLeForEtRetourneIndice(chaine))
{
case 0 : //
case 1 : //
//...
}

- en revanche, si dans chaque case, j'avais du code lourd, je reste convaincu que l'utilisation d'un tableau d'objets fonctions reste non seulement plus performant et aussi beaucoup plus propre !!!
30/03/2007, 10h14
Clorish

Citation:

- en revanche, si dans chaque case, j'avais du code lourd, je reste convaincu que l'utilisation d'un tableau d'objets fonctions reste non seulement plus performant et aussi beaucoup plus propre !!!

ce la va de soit :)

Je ne depasse rarement les 2 lignes dans les cases ;)
Je prefere appeler une methode privee qui effectue le traitement lourd.

Note : J'aime bien aussi declarer des constantes pour clarifier l'indexation du case ....

C'est avec du code clair et des astuces de codages que l'on gagne enormement du temps sur le debugage. Il faut savoir jouer avec les messages du compilo.

Petite astuce gratuite ;) :
il vaut mieux :

Code:

if (2 == n) {...}

que :

Code:

if (n == 2) {...}

une mauvaise habitude de langages comme delphi ou une simple etourderie du type :

Code:

if (n = 2) {...}

genere une erreur de compilation dans le premier cas : "partie gauche non affectable", mais rien dans le 2e. Bien au contraire, l'affectaiton retourne 2 qui est synonyme de vrai (ou faux, je sais jamais ;)) ....
30/03/2007, 10h43
®om

Citation:

Envoyé par Clorish

genere une erreur de compilation dans le premier cas : "partie gauche non affectable", mais rien dans le 2e. Bien au contraire, l'affectaiton retourne 2 qui est synonyme de vrai (ou faux, je sais jamais ;)) ....

Pas en java... un int n'est pas castable en boolean...
Donc, if(n=2) ça ne fait ni vrai ni faux (le n=2, ça vaut 2), ça ne compile pas...
30/03/2007, 10h49
Clorish

Citation:

Envoyé par ®om

Pas en java... un int n'est pas castable en boolean...
Donc, if(n=2) ça ne fait ni vrai ni faux (le n=2, ça vaut 2), ça ne compile pas...

Ca c'est une bonne nouvelle :)
En C c'etait le cas .. et j'ai passe 3 jours a trouver d'ou venais mon erreur (test toujours vrais .....)
30/03/2007, 10h53
benwit
Citation:

Envoyé par Clorish

Je ne depasse rarement les 2 lignes dans les cases ;)
Je prefere appeler une methode privee qui effectue le traitement lourd.

C'est plus clair en effet et suffit la pupart du temps.
L'intérêt des objets Fonctions, c'est qu'on peut bénéficer de l'héritage, de la redéfinition, etc ...

Citation:

Envoyé par Clorish

Note : J'aime bien aussi declarer des constantes pour clarifier l'indexation du case ....

Moi aussi. On peut ainsi mettre des noms plus explicite. On peut aussi retrouver une même valeur plus facilement (c'est mieux que du recherche/remplacement de chaine lorsqu'on fait du refactoring)

Citation:

Envoyé par Clorish

Petite astuce gratuite ;) :
il vaut mieux :

Code:

if (2 == n) {...}

que :

Code:

if (n == 2) {...}

une mauvaise habitude de langages comme delphi ou une simple etourderie du type :

Code:

if (n = 2) {...}

genere une erreur de compilation dans le premier cas : "partie gauche non affectable", mais rien dans le 2e. Bien au contraire, l'affectaiton retourne 2 qui est synonyme de vrai (ou faux, je sais jamais ;)) ....

Merci pour l'astuce même si je pense qu'elle sert davantage au C ou à Delphi car en Java, tout du moins avec un IDE comme Eclipse qui fait de la compilation incrémentale, tu ne peux pas commettre ce genre d'erreur puisque l'affectation dans un if ne peut se faire que si au final, l'expression du if retourne un booléen.
- si i est un int, if (i = 2) est donc immédiatement souligné comme une erreur !
- si b est un booleen, il est vrai que ton astuce fonctionne if (true == b) en place de (b == true) mais finalement ne me sert pas puisque je ferai directement if (b)
A mon tour, tu m'as fait pensé à une astuce :

au lieu de faire

Code:

if (maString.equals("toto"))

, mieux vaut faire

Code:

if ("toto".equals(maString))

qui évite de contrôler le cas du null :

Code:

if (maString!=null && maString.equals("toto"))

Et pour les chaines vide, je préfère

Code:

if (maStringNonNull.length() > 0)

à

Code:

if (maStringNonNull.equals(""))
30/03/2007, 11h00
®om
Citation:

Envoyé par benwit

si b est un booleen, il est vrai que ton astuce fonctionne if (true == b) en place de (b == true) mais finalement ne me sert pas puisque je ferai directement if (b)

Le seul cas où on peut se tromper en java pour l'affectation / test d'égalité (il faut quand même le vouloir):
Code:

1 2 3 boolean a = ...; boolean b = ...; if(b=a) {...} // au lieu de if(b==a) {...}
30/03/2007, 11h02
®om

Citation:

Envoyé par benwit

Et pour les chaines vide, je préfère

Code:

if (maStringNonNull.length() > 0)

à

Code:

if (maStringNonNull.equals(""))

Euh, plusieurs remarques.
La première, c'est qu'il faut tester == 0 et non > 0 (sinon c pour les chaines non vides). (faute de frappe je suppose)
Ensuite, suite à ta première remarque, autant faire "".equals(maString) :)

Enfin, pour tester si une chaine est vide, le plus simple est .isEmpty() (c'est fait pour ça) :)
30/03/2007, 11h12
benwit

rom,

oui, faute de frappe :lol:

Code:

if (maStringNonNull.length() == 0)

oui aussi pour "".equals(maString) mais pour les chaines non null (c'est pour cela que j'ai écris maStringNonNull), je préfère éviter l'utilisation de chaîne "" dans le code (goût perso).

Euh, une autre remarque :
isEmpty est peut être fait pour cela mais pour les Collection ou d'autres mais pas pour les String !!! (faute de précipitation je suppose) ;)
30/03/2007, 11h19
®om

Citation:

Envoyé par benwit

Euh, une autre remarque :
isEmpty est peut être fait pour cela mais pour les Collection ou d'autres mais pas pour les String !!! (faute de précipitation je suppose) ;)

Citation:

Envoyé par javadoc

isEmpty

public boolean isEmpty()

Returns true if, and only if, length() is 0.

Returns:
true if length() is 0, otherwise false
Since:
1.6

Effectivement je n'avais pas vu que c'était que à partir de java 6 (c'est mon jdk par défaut, donc ma javadoc par défaut, donc je ne fais pas attention) :)
Mais bon donc isEmpty() existe maintenant pour les String :)
30/03/2007, 11h29
benwit

désolé, je suis tout autant fautif puisque je n'ai pas vérifier que ce que je disais était vrai dans ma version de java (< 1.6)

Merci donc pour l'info ;)

D'ailleurs, il serait bien que le site Developpez mette à jour la doc accessible par Javasearch
Merci.:)
30/03/2007, 14h01
Clorish
Citation:
Envoyé par ®om

Le seul cas où on peut se tromper en java pour l'affectation / test d'égalité (il faut quand même le vouloir):

Code:

1 2 3 boolean a = ...; boolean b = ...; if(b=a) {...} // au lieu de if(b==a) {...}
et

Code:

if(true=a) {...} // au lieu de if(true==a) {...}

;)