Discussion :

[SamusStrife]

Bonjour,

J'aimerai à partir d'un caractère donné, retourner ses équivalents avec accents. Donc pour pouvoir faire ça j'ai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
public static String[] convert(String str){
 
		if(Character.isUpperCase(str.indexOf(0))){
			if(str.equals("A")){
				return new String[]{new Character((char) 192).toString(), new Character((char) 193).toString(), new Character((char) 194).toString(),
						new Character((char) 195).toString(), new Character((char) 196).toString(), new Character((char) 197).toString()};
			}else if(str.equals("E")){
				return new String[]{new Character((char) 200).toString(), new Character((char) 201).toString(), new Character((char) 202).toString(),
						new Character((char) 203).toString()};
			}else if(str.equals("I")){
				return new String[]{new Character((char) 204).toString(), new Character((char) 205).toString(), new Character((char) 206).toString(),
						new Character((char) 207).toString()};
			}else if(str.equals("O")){
				return new String[]{new Character((char) 210).toString(), new Character((char) 211).toString(), new Character((char) 212).toString(),
						new Character((char) 213).toString()};
			}else if(str.equals("U")){
				return new String[]{new Character((char) 217).toString(), new Character((char) 218).toString(), new Character((char) 219).toString(),
						new Character((char) 220).toString()};
			}else if(str.equals("Y")){
				return new String[]{new Character((char) 159).toString(), new Character((char) 221).toString()};
			}
		}
		return null;
	}

Pour expliquer vite fait mes choix de variables : je prends en paramètre une String qui contient le ou les caractères (dans les cas particulier du ae, oe qui donnerai æ, œ etc) et je retourne un tableau de String pour pouvoir l'afficher dans une JTable et faciliter le remplacement des "anciens" caractères par ceux proposé dans les tableaux.

Je pense que je pourrai passer par des double casts mais je trouve ca plus "propre" perso de passer par l'objet Character. Petite précision, chaque entier correspond à la valeur décimale du caractère dans la table ASCII.

Donc la question est : Est-ce la bonne méthode? il n'y a pas plus simple? J'ai l'impression d'y aller comme un barbare...

Merci d'avance pour votre aide

[joel.drigo]

Salut,

Pour les caractères accentués, il serait plus simple de créer une String avec des caractères, tout simplement, en unicode : "\u00e0" par exemple pour le caractère à. Le nombre derrière le \u c'est le même que tu as utilisé mais en héxadécimal. Ensuite, tu mets ces chaines dans une Map, avec en clef, le caractère sans accent.

Tu peux même générer la map automatiquement en fait, en utilisant un Normalizer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
public class AccentuedCharUtils {
 
	public static void main(String[] args) {
		System.out.println(ACCENTUED_CHARACTERS);
 
		System.out.println(ACCENTUED_CHARACTERS.get("e"));
	}
 
 
	public static final Map<String, String> ACCENTUED_CHARACTERS = createMap();
 
	private static final String CHARS = "eauioyc"; // les caractères dont on veut les équivalents accentués (ou du type cédille pour le c)
        private static final char FIRSTCHAR = 'A';
        private static final char LASTCHAR = '\u017E';
 
	private static Map<String, String> createMap() {
 
 
		StringBuilder sb = new StringBuilder(LASTCHAR-FIRSTCHAR+1);
		for(char c=FIRSTCHAR; c<=LASTCHAR; c++) {
			if ( Character.isLetter(c) ) {
				sb.append(c);
			}
		}
		String all = sb.toString();
 
		String normalized = Normalizer.normalize(all, Normalizer.Form.NFD).replaceAll("\\p{InCombiningDiacriticalMarks}+", "");;
 
		Map<String, String> map = new HashMap<>();
 
		for(int i=0; i<CHARS.length(); i++) {
			char c = CHARS.charAt(i);
 
			StringBuilder accentued = new StringBuilder();
			for( int index = normalized.indexOf(c); index!=-1; index = normalized.indexOf(c, index+1) ) {
				char ac = all.charAt(index);
				if ( ac!=c ) // tu peux supprimer ce test si tu veux que ta chaine contienne aussi le caractère lui-même
				accentued.append(ac);
			}
 
			map.put(String.valueOf(c), accentued.toString());
 
		}
 
		return Collections.unmodifiableMap(map);
 
	}
 
}

Pour les ligatures (e dans l'a, e dans l'o), tu ne peux pas utiliser un Normalizer, mais il n'y a qu'une association caractère avec string, donc tu peux faire aussi une Map spécifique Map, en utilisant la notation unicode ( "\u00C6" pour "Æ" par exemple).

PS. Attention, tous les caractères ne s'affichent pas avec une police standard (il faut une police unicode). Tu peux également réduire l'espace de caractères en remplaçant par .\u017E par \u00FD (mais tu n'auras pas le y avec accent, ce qui n'est pas important pour le français).

[SamusStrife]

Tout simplement parfait merci joel.drigo

Pour les polices, je vais surement devoir modifier mon encodage (j'ai imposé l'UTF-8) car si je dis pas de bêtises l'UTF-8 ne correspond a l'ASCII que du 32 au 126 (en décimal).

Bref merci en tout cas problème résolu

[thelvin]

Euh... UTF-8 correspond à ASCII de 0 à 127, c'est-à-dire à ASCII tout entier puisqu'il ne va ni au-delà, ni avant. C'est un peu le but d'UTF-8, d'être 100% compatible avec ASCII.

De toute façon le problème de l'encodage et le problème d'associer une lettre à ses versions accentuées, sont deux problèmes différents. En Java un char c'est un char, peu importe l'encodage qu'on utilisera un jour pour le représenter.

[SamusStrife]

Heu oui pour l'UTF-8 je me suis gouré... méa culpa

Pour l'encodage, je parlais des polices d'écritures et non du char en lui même, qui peut avoir certains problème avec les langages fortement "ligaturé" dont la forme graphique du caractère dépend du contexte textuel. En gros si tu préfères, le rendu graphique ne peut être gérer qu'avec l'UTF-8 (et donc la table ASCII). C'est pour ça que je parlais de modifier mon encodage, voir de rajouter plusieurs encodages (si c'est possible) selon la langue pratiqué (comme l'arabe par exemple). Après peut être que l'UTF-16 ou 32 suffit amplement mais je ne me suis pas encore réellement penché sur le problème pour dire ce qui est bon ou non

Après petite précision :

En Java un char c'est un char, peu importe l'encodage qu'on utilisera un jour pour le représenter.

Je suis plus ou moins d'accord... Java code ses caractères en UTF-16 donc on ne peut pas lire les caractères codé en UTF-32 (enfin une partie) sauf depuis java 5 avec les code points (qui, si je ne dis pas de bêtises, est une librairies a téléchargé : JSR... A moins qu'elle ai été intégré a Java même depuis les dernières versions)

[thelvin]

En gros si tu préfères, le rendu graphique ne peut être gérer qu'avec l'UTF-8 (et donc la table ASCII).

Ceci, comme le reste du paragraphe, n'a absolument aucun sens. Donc non, je ne préfère pas.
Je n'ai aucune idée de ce que tu cherches à exprimer, à part "il y a des trucs à savoirs, sur comment on allie un caractère à sa ou ses représentations graphiques dans une police." Oui, mais ça n'a rien à voir avec UTF-8 ou ASCII. Il vaudrait mieux dire les choses exactement comme elles sont.

Après petite précision : Je suis plus ou moins d'accord...

Tu as donc plus ou moins raison. Les choses sont ce qu'elles sont, il n'y a pas à être d'accord avec elles, ça ne les changera pas.

Java code ses caractères en UTF-16 donc on ne peut pas lire les caractères codé en UTF-32 (enfin une partie)

Et pourquoi ne pourrait-on pas ? En quoi les principes internes de Java empêcheraient-ils de lire d'autres encodages ?

Par ailleurs, dire que Java encode en UTF-16 est une simplification. Pour commencer, il y a deux UTF-16 : petit-boutiste ou grand-boutiste. C'est lequel ? Aucun des deux, car Java n'a pas de notion de boutisme. Les encodages, UTF-16 et les autres, consistent à convertir une séquence d'octets en séquence de caractères, et vice-versa.
En Java les caractères sont représentés par, des char, pas des octets. Un char contient 16 bits, pas 8. La manière de représenter des caractères avec des chars, est la même que UTF-16 représente des caractères avec des paires de deux octets. D'où la simplification usuelle. Attention quand même à ne pas confondre.

sauf depuis java 5 avec les code points

Bien que Java 5 ait introduit des méthodes directement pour gérer les code points correspondants à une séquence de chars, ce qui est pratique quand on en a besoin, on en a rarement besoin. Les caractères marchent parfaitement sans qu'on aille les regarder.
De plus il était parfaitement possible de les calculer soi-même avant que Java 1.5 ne le propose.

(qui, si je ne dis pas de bêtises, est une librairies a téléchargé : JSR... A moins qu'elle ai été intégré a Java même depuis les dernières versions)

Les code points n'ont pas besoin d'être téléchargés, ce sont les nombres de 0 à 1114111.
Différentes versions de Java fournissent différents niveaux d'information sur les propriétés de ces code points (sont-ce des lettres, des symboles, de quel bloc font-ils partie, quelle est leur normalisation, etc,) et il est possible que des bibliothèques additionnelles fournissent une gestion plus fine de la base de données Unicode que ce que fournit Java tel que. Mais, à quoi cela te servira-t-il ?

[SamusStrife]

....

Ceci, comme le reste du paragraphe, n'a absolument aucun sens. Donc non, je ne préfère pas.
Je n'ai aucune idée de ce que tu cherches à exprimer, à part "il y a des trucs à savoirs, sur comment on allie un caractère à sa ou ses représentations graphiques dans une police." Oui, mais ça n'a rien à voir avec UTF-8 ou ASCII. Il vaudrait mieux dire les choses exactement comme elles sont.

Tu as exactement compris ce que je voulais exprimer, mais tu l'as mal interprété : ce que je voulais dire c'est que je n'ai absolument aucun problème avec char ou Character (comme t'avais l'air de le penser dans ton premier post) juste avec les polices et leurs possible encodage qui ne respecte pas les polices unicode.

Tu as donc plus ou moins raison. Les choses sont ce qu'elles sont, il n'y a pas à être d'accord avec elles, ça ne les changera pas.

Je ne cherche pas à les changer, Dieu merci je n'ai pas cette prétention

Par ailleurs, dire que Java encode en UTF-16 est une simplification. Pour commencer, il y a deux UTF-16 : petit-boutiste ou grand-boutiste. C'est lequel ? Aucun des deux, car Java n'a pas de notion de boutisme. Les encodages, UTF-16 et les autres, consistent à convertir une séquence d'octets en séquence de caractères, et vice-versa.
En Java les caractères sont représentés par, des char, pas des octets. Un char contient 16 bits, pas 8. La manière de représenter des caractères avec des chars, est la même que UTF-16 représente des caractères avec des paires de deux octets. D'où la simplification usuelle. Attention quand même à ne pas confondre.

Ok merci pour l'info

Bien que Java 5 ait introduit des méthodes directement pour gérer les code points correspondants à une séquence de chars, ce qui est pratique quand on en a besoin, on en a rarement besoin. Les caractères marchent parfaitement sans qu'on aille les regarder.
De plus il était parfaitement possible de les calculer soi-même avant que Java 1.5 ne le propose.

Justement je risque d'en avoir besoin

Les code points n'ont pas besoin d'être téléchargés, ce sont les nombres de 0 à 1114111.
Différentes versions de Java fournissent différents niveaux d'information sur les propriétés de ces code points (sont-ce des lettres, des symboles, de quel bloc font-ils partie, quelle est leur normalisation, etc,) et il est possible que des bibliothèques additionnelles fournissent une gestion plus fine de la base de données Unicode que ce que fournit Java tel que. Mais, à quoi cela te servira-t-il ?

Alors la c'est un autre problème, je parlais de JSR 204 (pour être plus précis) juste pour dire qu'elle existait, mais normalement je n'en aurai pas besoin tant que je suis capable de déterminer si ce sont des lettres, symboles etc... Après tout dépends jusqu'où va ces informations. Mais en l'état actuel je n'ai pas besoin de bibliothèques additionnelles

Enfin bon merci en tout cas pour toute ces précisions @+