[Java] Manipuler des caractères diacritiques

Manipuler des caractères diacritiques [Java] - Java - Programmation

Marsh Posté le 07-01-2004 à 16:20:25    

Salut
 
J'ai cherché un peu partout dans l'API Java une classe qui permet de récupérer des caractères ASCII depuis une String avec des caractères diacritiques dedans... La seule chose que j'ai trouvé (dans java.text), c'est la possibilité de comparer des caractères diacritiques avec des caractères ASCII, mais aucune possibilité de passer du premier au second :heink:
 
Vous connaissez un moyen de faire ça ? Merci :hello:

Reply

Marsh Posté le 07-01-2004 à 16:20:25   

Reply

Marsh Posté le 07-01-2004 à 18:52:00    

ben pour récupérer ton caractère tu fais juste taString.charAt(lIndexDeTonCaractere);
Ca te retourne un char. (Les chars java sont des caractère unicodes).
 
Pour récupérer le code de ce caractère, tu as juste à le cast en int :  
int code = (int) tonChar;
 
 
J'ai répondu à la question ?


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 07-01-2004 à 22:43:41    

benou a écrit :

ben pour récupérer ton caractère tu fais juste taString.charAt(lIndexDeTonCaractere);
Ca te retourne un char. (Les chars java sont des caractère unicodes).
 
Pour récupérer le code de ce caractère, tu as juste à le cast en int :  
int code = (int) tonChar;
 
 
J'ai répondu à la question ?


 
heu ça dépend...
oui si ((int) 'a' = int 'à') par exemple :)
non sinon ;)  
le but est de supprimer tous les caractères diacritiques dans une chaine et de les remplacer par le caractère ASCII associé
é -> e
è -> e
à -> a
etc...

Reply

Marsh Posté le 07-01-2004 à 23:25:18    

ha ok ...
bon ben ca non, ca existe pas. enfin je pense pas ...
 

Reply

Marsh Posté le 07-01-2004 à 23:56:06    

c'est bien ce qui me fait peur...
pourtant si Java est capablke de comparer 'à' et 'a' (dans le package java.text) je comprend pas qu'il puisse pas passer du premier au second.
 
surtout que si j'ai bien compris, Java utilise UTF-8 pour encoder Unicode, et du coup, le premier octet représente le caractère non accentué, et le second l'accent...
 
bon j'ai une solution de rechange, mais avouez que passer par PostgreSQL pour délester une chaine Java de ses accents, c'est méga sioux !

Reply

Marsh Posté le 08-01-2004 à 00:01:52    

Predicator a écrit :

surtout que si j'ai bien compris, Java utilise UTF-8 pour encoder Unicode, et du coup, le premier octet représente le caractère non accentué, et le second l'accent...


ben dans ce cas là avec un petit ET binaire tu t'en sors [:spamafote]

Reply

Marsh Posté le 08-01-2004 à 00:37:26    

Predicator a écrit :


surtout que si j'ai bien compris, Java utilise UTF-8 pour encoder Unicode, et du coup, le premier octet représente le caractère non accentué, et le second l'accent...


 
non²
 
-java utilise UTF-32 pour encoder unicode (aka un glyphe tjrs sur 4 octets) ce qui est != d'UTF-8 ou un glyphe est encodé sur un nombre variable d'octets variant de 1 à 6.
 
-et non ça ne se goupille pas comme ça en UTF-8 pour certains glyphes accentués tel que le é


Message édité par schnapsmann le 08-01-2004 à 00:44:12

---------------
From now on, you will speak only when spoken to, and the first and last words out of your filthy sewers will be "Sir!"
Reply

Marsh Posté le 08-01-2004 à 07:41:50    

ratai, c'est UTF-16.
 
edit : pour éviter tout contestation :
http://java.sun.com/docs/books/jls [...] .html#9151


Message édité par nraynaud le 08-01-2004 à 07:57:37

---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 08-01-2004 à 08:04:57    

OK merci pour ces précisions
mais on m'enlèvera pas de l'idée que si Java sait comparer 'à' et 'a', alors il sait passer du premier au second, et ne pas permettre de le faire, c'est chelou :heink:

Reply

Marsh Posté le 08-01-2004 à 08:10:11    

Predicator a écrit :

UTF-8 pour encoder Unicode, et du coup, le premier octet représente le caractère non accentué, et le second l'accent...

oulà, pas du tout, fait gaffe à ne pa partir sur ce genre d'idées.
 
petit extrait de la RFC 2279 :

Citation :


     In UTF-8, characters are encoded using sequences of 1 to 6 octets. The only octet of a "sequence" of one has the higher-order bit set to 0, the remaining 7 bits being used to encode the character value. In a sequence of n octets, n>1, the initial octet has the n higher-order bits set to 1, followed by a bit set to 0. The remaining bit(s) of that octet contain bits from the value of the character to be encoded. The following octet(s) all have the higher-order bit set to 1 and the following bit set to 0, leaving 6 bits in each to contain bits from the character to be encoded.
 
    The table below summarizes the format of these different octet types. The letter x indicates bits available for encoding bits of the UCS-4 character value.
 
   UCS-4 range (hex.)           UTF-8 octet sequence (binary)
   0000 0000-0000 007F   0xxxxxxx
   0000 0080-0000 07FF   110xxxxx 10xxxxxx
   0000 0800-0000 FFFF   1110xxxx 10xxxxxx 10xxxxxx
 
   0001 0000-001F FFFF   11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
   0020 0000-03FF FFFF   111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
   0400 0000-7FFF FFFF   1111110x 10xxxxxx ... 10xxxxxx

En gros ce qu'on en retient c'est que le nombre de 1 en tête du premier octet donne le nombre d'octets qu'il reste à lire pour le caractère courant.
 
Pour UTF-16 ça semble être un bordel monstre et différent, mais je suis pas sûr, j'ai trouvé aucun document clair.


---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 08-01-2004 à 08:10:11   

Reply

Marsh Posté le 08-01-2004 à 08:15:16    

Predicator a écrit :

OK merci pour ces précisions
mais on m'enlèvera pas de l'idée que si Java sait comparer 'à' et 'a', alors il sait passer du premier au second, et ne pas permettre de le faire, c'est chelou :heink:  

ben fais ta table de convertion. Tiens, je vais le faire, ça me fait tripper ce truc.


---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 08-01-2004 à 08:21:51    

Predicator a écrit :

OK merci pour ces précisions
mais on m'enlèvera pas de l'idée que si Java sait comparer 'à' et 'a', alors il sait passer du premier au second, et ne pas permettre de le faire, c'est chelou :heink:  

c'est où dans le package java.text ? je trouve pas le collator kivabien.


---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 08-01-2004 à 08:23:07    

nraynaud a écrit :

oulà, pas du tout, fait gaffe à ne pa partir sur ce genre d'idées.
 
petit extrait de la RFC 2279 :

Citation :


     In UTF-8, characters are encoded using sequences of 1 to 6 octets. The only octet of a "sequence" of one has the higher-order bit set to 0, the remaining 7 bits being used to encode the character value. In a sequence of n octets, n>1, the initial octet has the n higher-order bits set to 1, followed by a bit set to 0. The remaining bit(s) of that octet contain bits from the value of the character to be encoded. The following octet(s) all have the higher-order bit set to 1 and the following bit set to 0, leaving 6 bits in each to contain bits from the character to be encoded.
 
    The table below summarizes the format of these different octet types. The letter x indicates bits available for encoding bits of the UCS-4 character value.
 
   UCS-4 range (hex.)           UTF-8 octet sequence (binary)
   0000 0000-0000 007F   0xxxxxxx
   0000 0080-0000 07FF   110xxxxx 10xxxxxx
   0000 0800-0000 FFFF   1110xxxx 10xxxxxx 10xxxxxx
 
   0001 0000-001F FFFF   11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
   0020 0000-03FF FFFF   111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
   0400 0000-7FFF FFFF   1111110x 10xxxxxx ... 10xxxxxx

En gros ce qu'on en retient c'est que le nombre de 1 en tête du premier octet donne le nombre d'octets qu'il reste à lire pour le caractère courant.
 
Pour UTF-16 ça semble être un bordel monstre et différent, mais je suis pas sûr, j'ai trouvé aucun document clair.


 
alors j'ai du dire une boulette et ça doit être UTF-16 qui peut marcher comme ça :jap:  
j'ai un collègue qui travaille sur ce genre de chose, et il m'a expliqué que pour un même codage (UTF-16 donc, j'ai du me tromper), il y avait aussi les 2 méthodes, à savoir :
 
- codage du caractère et son symbole diacritique
- codage du caractère sur un octet et son symbole diacrtique sur l'octet suivant
 
les deux peuvent être mélangés, et en gros j'ai pas essayé de comprendre exactement comment ça marchait :lol:

Reply

Marsh Posté le 08-01-2004 à 08:26:28    

nraynaud a écrit :

c'est où dans le package java.text ? je trouve pas le collator kivabien.


 
comme ça à brûle pourpoint je sais plus, mais c'est un Collator qui te permet de choisir le niveau de comparaison de 2 chaînes :
 
- primaire : ni accent ni casse ne comptent
- secondaire : insensible à la casse
- tertiaire : sensible aux accents et à la casse

Reply

Marsh Posté le 08-01-2004 à 08:32:12    

Predicator a écrit :


 
comme ça à brûle pourpoint je sais plus, mais c'est un Collator qui te permet de choisir le niveau de comparaison de 2 chaînes :
 
- primaire : ni accent ni casse ne comptent
- secondaire : insensible à la casse
- tertiaire : sensible aux accents et à la casse

Ok, je vois, j'ai pas regardé ces collators, ils avaient un nom qui me plaisait pas.
http://java.sun.com/j2se/1.4.2/doc [...] #SECONDARY
 
je vais voir ça.


---------------
trainoo.com, c'est fini
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed