Discussion :

[grunt2000]

Pour écrire une application accessible à toute la planète, je souhaite que toutes les langues soient potentiellement prises en compte. Cela signifie que sur mes sites web, applications clientes, serveur et base de données, UTF-8 doit être pris en charge.

Mes premiers essais n'ont pas été très concluants, et je ne peux pas m'empêcher de mettre cette parodie en illustration:



Comment "bien préparer" un site web, un serveur EJB, une base de données, etc. à bien prendre en compte UTF-8? Quelles sont vos recommandations.
UTF-16 existe aussi. Pourquoi? Devrais-je en passer par lui aussi? Mais est-il vraiment soutenu?

Je vous remercie d'avance pour vos avis.

[tchize_]

alors, de mémoire, la différence entre utf-8 et utf-16, c'est que l'utf-16 utilise d'office 2 byte par "bloc" du caractère unicode, l'avantage est que, pour certains caractère situés relativement haut dans les tables unicode, travailler en 16 bits (utf-16) permet de coder la pluspart des lettres courantes sur 1 bloc de 16bits, alors que, pour ces meme langues, en utf-8, il faudrait 3 blocs de 8bits. Si ma mémoir est bonne, le chinois et le japonais seraient concernés. C'est donc surtout un problème de taille

L'ennui, c'est que pour la pluspart des autres langues occidentales, l'utf-16 signifie plus d'occupation mémoire que l'utf-8, nombre de caractères latins tenant dans le premier groupe de caractères. Pour d'autres langues, c'est kifkif, deux bloc 8bits ou un bloc 16bits Tout dépend de la chance que la langue a eu au tirage sur le tables unicode :p

Comment bien préparer? Alors pour la db, s'assurer qu'elle gère tout le jeu de caractères unicode. Ca peut etre de l'utf-8 en interne ou autre chose, tant que çà gère le même jeu, laisse la db se dépétrer avec les conversion, tant que t'as la garantie que les conversions sont possible . De toutes facons, en java, les strings son stockées en mémoire dans un format propre qui gère tout le jeu unicode. Et comme c'est au connecteur sql de te filer les string java.... laisse lui faire son boulot :p t'as plus à t'occuper de çà

Pour les EJB -> mémoire interne -> rien à faire

Pour les pages web -> je dirais utf-8 en content encoding, utf-8 en accept-charset sur les forms, et forcer l'utf-8 pour le décodage des url dans ton serveur.

Si Martine a encore des questions...