Discussion :

[benwit]

Quel est votre position par rapport au codage des caractères ?
Et particulièrement à UTF-8 ? C'est l'objet de mon sondage.

Si vous ne connaissez pas Unicode ou si vous utilisez encore ISO-Latin1,
je vous conseille de lire Unicode en pratique, il risque bien de vous faire changer d'avis !

Avez vous lu ce livre ? Qu'en avez vous pensez ?
Pensez vous le lire à l'avenir ?

[deltree]

Pour avoir travaillé sur des applications internationales (+ de 5 langues) Je suis à fond pour l'UTF-8. Mais j'ai quand même répondu "3 et 4" à cause d'une demande du client pour le chinois.
Les chinois tiennent à leur encodage, et je crois qu'il y a quelques limitations sur des caractères chinois, sans que j'en sache beaucoup plus :
http://www.chinesecomputing.com/internet/web.html

Dans tout les autres cas, et même pour du français pur, rester en full UTF-8 nous évite bien des problèmes (notamment l'encoding des Formulaires Web)


Après il y a quand même des petites bizarreries pour nous mettre des batons dans les roues:
.Eclipse qui n'est pas en UTF-8 par défaut
.Ce satané UnsupportedEncodingException dès qu'on veut spécifier explicitement l'encoding.
.Les properties qui Interdisent l'UTF-8 et resteront en ISO, pour des raisons de spécifications et de compat ascendante. Pratique pour les bundle de traduction.

Edit: petite digression dans le sujet :
http://www.apprendre-en-ligne.net/bl...ecrit-en-utf-8

edit2: si c'était pas clair, c'est le point de vue d'un codeur Java .

[Franck SORIANO]

Je viens de répondre "Je connais pas".

Bon évidemment ce n'est pas vrai. Mais c'est ce qui résume le mieux la réalité de mes développements :
Je travaille sous BDS 2006, qui n'est pas Unicode. Il faut attendre Delphi 2009 pour avoir l'unicode.

Donc sur nos dev, on travaille en ansi et on doit parfois jongler entre les caractères Windows et les caractères DOS...
Mais comme on travaille exclusivement sur des applications purement française, les seuls problèmes d'accents qu'on rencontre sont ceux liés au passage Windows<->DOS.

Il m'arrive parfois de travailler en Unicode. Et dans ce cas, je préfère l'UTF-16 pour la simple et bonne raison que c'est l'encodage natif de Windows.
C'est aussi l'encodage de travail de la plupart des outils (et des langages).

J'écris également les fichiers unicode en UTF-16 le plus souvent pour éviter toute confusion avec les fichiers Ansi. Le problème avec l'UTF-8 est le même qu'avec toutes les normes de codage : Il faut connaitre la norme utilisée pour l'encodage du fichier. Or on peut facilement confondre de l'UTF-8 avec de l'ansi...

Je n'utilise l'UTF-8 que si je veux limiter la taille du fichier et que j'ai besoin d'avoir un fichier unicode.

[benwit]

Merci pour vos deux points de vues.

@deltree,
De dev Java à dev Java, c'est clair que le defaut CP1252 par défaut sous Eclipse/windows est pénible.
Pour les properties, j'avais fait une conversion mais c'est mieux gérer il me semble avec les ressources bundle.

@franck soriano
parfois, il faut être pragmatique !
Quand tu parles du défaut UTF-16 de windows, c'est de seven qu'il s'agit ?

[Franck SORIANO]

Quand tu parles du défaut UTF-16 de windows, c'est de seven qu'il s'agit ?

Non, c'est comme ça depuis Windows NT.

Windows NT travaille en UTF-16 en natif. Il est beaucoup plus simple de manipuler une chaîne lorsque tu peux dire : 1 caractère = 2 octets (ce qui en réalité n'est pas vrai en UTF-16) que lorsque tu travailles avec des caractères de taille variable...
Windows NT (et tous les OS qui en ont découlé) fonctionne en UTF-16 pour tout ce qui n'est pas Ansi. Lorsque tu fais un appel à une fonction de l'API, il faut lui fournir soit des chaînes UTF-16 (version unicode), soit des chaînes Ansi en CP1252.
Et parfois certaines API n'existent qu'en Unicode (donc UTF-16). A partir de là, si tu ne veux pas passer ton temps à faire des conversions UTF-8 <->UTF-16 tu as tout intérêt à tout faire en UTF-16, et a ne passer à l'UTF-8 (ou autre) qu'au moment du stockage dans un fichier.

[benwit]

Merci de ces précisions.
Je posais la question car je me demandai pourquoi Eclipse sous Windows nous propose le CP1252 par défaut alors que l'OS serait nativement en UTF-16.
Il en va probablement soit d'un choix des concepteurs, et/ou soit de l'utilisation d'une API utilisant CP1252.

Pour en revenir au choix du codage, je comprend parfaitement que par pragmatisme ou par obligation, on n'utilise pas Unicode.
En revanche, si on n'a pas de contraintes particulières, je pense que Unicode est le meilleur choix. UTF-8 a juste l'avantage de ne pas occuper un surcout d'espace trop important par rapport aux anciens codages.
De toute façon, d'après l'auteur, l'important, c'est Unicode, peu importe la variante d'implémentation (UTF-8, UTF-16 ou UTF-32).

[deltree]

Pour les properties, dans notre équipe, on les utilise avec la balise "fmt:" de I18n et apparemment, il faut systématiquement échapper les caractères UTF-8. Les properties sont ISO par spécification:
http://download.oracle.com/javase/6/...roperties.html
"input/output stream is encoded in ISO 8859-1 character encoding."

Ce qui me gêne pas en soit, mais java aurait du fournir un implem properties2 basé sur de l'utf-8.

Je trouve que ça donne vraiment un image brouillon de l'informatique de voir encore des Ã@ à la place des é sur les sites web à cause de ce mélange d'encodage entre tous les outils même en utilisant un seul langage..

[Chatanga]

Merci de ces précisions.
Je posais la question car je me demandai pourquoi Eclipse sous Windows nous propose le CP1252 par défaut alors que l'OS serait nativement en UTF-16.

Windows n'est pas en CP-1252 par défaut partout. Il l'est dans un encodage adapté à chaque région du monde.

C++ et Java (ou plutôt leurs compilateurs respectifs) ne fonctionnent pas de la même manière concernant l'Unicode. En effet, javac lit un fichier dans un encodage donné (configurable par une option au demeurant) et traduit en UTF-16* les chaînes de caractères dans le fichier .class résultant. De fait, le résultat de la compilation de deux fichiers "visuellement identiques" mais encodés différemment donne le même résultat d'un point de vue binaire.

Utiliser gcc sur ces mêmes fichiers ne donnera pas le même résultat binaire. Là où Java stocke en UTF-16, le C++ ne stocke que sur 16 bits. Le fait qu'Eclipse ne soit pas configuré par défaut en UTF-8 n'est donc pas si gênant que ça, le résultat sera le même. Le seul inconvénient survient lorsqu'on récupère dans un même projet des sources à droite et à gauche avec des encodages différents, voire inconnus. Pour simplement écrire du contenu dans sa langue (commentaires ou chaînes de caractères), l'encodage par défaut de Windows est en principe adapté.

* Plus ou moins selon les versions.

[_skip]

J'utilise toujours UTF-8 dans mes développements. Il a pour moi presque tous les principaux avantages, standardisé, compact en taille et illimité en représentation.

Il y a cependant 2 choses à être prudent:
Comme mentionné : la taille variable rend les opérations style maChaine[x] moins performante. Perso je compte avec les doigts d'une main le nombre d'applications que j'ai écrites où ceci était nécessaire.

Et enfin la pire chose : sa compatibilité avec ISO-8859-1 sur les 127 premiers caractères. Un des produits de ma société nécessite que les clients nous fournissent des données en XML. Vous imaginez pas le nombre d'entre eux qui, malgré nos mises en garde, balance du ISO alors que leur fichier est déclaré UTF-8 :

<?xml encoding="UTF-8"

Je suis vraiment tombé à la renverse en voyant le nombre d'informaticiens qui ignorent ces problèmes d'encodage, et pour certains qui ignorent carrément comment former correctement un fichier XML.

[benwit]

D'une certaine manière, je pense comprendre ce que tu veux dire par le "problème de sa compatibilité avec les premiers caractères du latin1".
C'est vrai que du coup, ils sont malheureusement nombreux à ne pas faire attention.

D'un autre côté, cela a aussi son avantage lorsque tu dois les convertir "à la main". En anglais, la plupart passe facilement. Et en français, il y a souvent juste les accents à corriger.

[gangsoleil]

Bonjour,

Je vais avoir la meme reponse que Franck Soriano (ie "Je ne connais pas"), mais pas tout a fait pour les memes raisons :
Je n'utilise que tres rarement les accents (mapping clavier sans accent par exemple, et taper le code ASCII de chacun est un peu rebarbatif, il faut l'avouer), et surtout, je ne les utilise pas pour programmer !!!

Bon, il faut avouer que j'ecris plus des demons en C que des GUI, mais tout de meme : a part pour les GUI dans certaines langues, il vaut mieux essayer d'eviter les caracteres non standards, car justement, on ne sait pas quel est l'encodage qui va etre utilise derriere.


Par ailleurs, quand on voit les URL de wikipedia, on se dit que les problemes d'encodage ont encore de beaux jours devant eux...

[deltree]

...
Par ailleurs, quand on voit les URL de wikipedia, on se dit que les problemes d'encodage ont encore de beaux jours devant eux...

ça fonctionne bien les accents sous wikipedia:
http://fr.wikipedia.org/wiki/Codage_de_caractères

les url générées contiennent des %C3%A8 par compatibilité descendante, les vieux browsers ne supportaient pas l'utf-8 dans l'url (IE6 voire avant).

Du reste tous les problèmes d'encoding sont lié à cette compatibilité ASCII, ou plutôt aux fork ASCII (entre cp-1252, ISO9660 et DOS CP-437).
La plupart des produits se contentent de la compatibilité ASCII alors que l'UTF-8 irait dans la quasi-totalité des cas. C'est incroyable qu'au 21ème siècle on me demande encore d'écrire des &eacute; et qu'on soit incapable de normaliser le "é" alors que la norme existe.

[gangsoleil]

C'est incroyable qu'au 21ème siècle on me demande encore d'écrire des &eacute; et qu'on soit incapable de normaliser le "é" alors que la norme existe.

S'il suffisait qu'une norme existe pour être implémentée, ça se saurait. De même, ce n'est pas parce qu'une norme existe qu'elle est bonne, et ce n'est pas parce qu'elle est implémentée qu'elle est meilleure que sa voisine.

[benwit]

ce n'est pas parce qu'une norme existe qu'elle est bonne, et ce n'est pas parce qu'elle est implémentée qu'elle est meilleure que sa voisine.

Je suis d'accord avec cette phrase (en général).

Dans le cas qui nous intéresse, hormis les raisons évoquées au début, je pense cependant qu'Unicode est une bonne solution et qu'elle doit être privilégiée lorsque c'est possible.

Je pense également qu'on trimballe pas mal de problèmes par méconnaissance tout simplement. Beaucoup utilisent encore de vieux codages non par nécessité mais par défaut, par laxisme, ...

[deltree]

Oui, j'entends des tas d'idées reçues sur l'UTF-8 la plus belle étant "c'est limité à 8 bits"

Bien évidemment ce n'est pas le cas. De plus l'utf-8 est compatible avec tous les systèmes modernes, tous les browser modernes, et a très peu de limitation de codage contrairement aux ISO96xx et cp1252. Franchement pour trouver un inconvénient à l'utf-8...

Quand à sortir des généralités, "si cétait mieux ça se saurait", j'ai rien contre toi gangsoleil, mais c'est vraiment pas un argument

"si [remplacer par ce que vous voulez] ça se saurait."

[gangsoleil]

Bonjour,

Quand à sortir des généralités, "si cétait mieux ça se saurait", j'ai rien contre toi gangsoleil, mais c'est vraiment pas un argument

Sauf que ce n'est absolument pas ce que j'ai ecrit. J'ai simplement ecrit que ce n'est pas parce qu'une norme existe qu'elle est bonne. Je parlais en general, et je ne cite absolument pas UTF8 dans ce post.

D'ailleurs, je n'ai rien ni pour ni contre utf-8 (enfin si, je suis massivement pour, mais ce n'est pas le point ici), puisque tous mes codes pourraient etre encodes sur de l'ASCII standard (non-etendu).

[deltree]

Justement tu ne parles pas d'UTF-8 mais tu me cites pour sous-entendre que ce n'est pas implémenté.

S'il suffisait qu'une norme existe pour être implémentée, ça se saurait[etc...]

UTF-8 est quand-même largement implémenté, et ce depuis au moins 10 ans.

Si c'est juste pour dire en général "il y a des normes pas implémentées", oui d'accord, mais dans le cas de l'utf-8 le problème ne se pose pas. Ni-même pour aucune des normes évoquées ici, l'iSO9660, ou le cp1252.

Enfin bon d'accord, je veut pas me lancer dans un gros débat, ça reste un détail de formulation.

Edit:J'ai bien compris que tu débattait sur le fait que la norme soit "bonne" pas qu'elle soit implémentée, mais j'aurais souhaité que le débat fut plus centré et moins généraliste, par exemple "UTF-8" n'est pas forcément meilleure que ISO9660, à partir de là on peut argumenter plus précisément.

[tulipebleu]

Bonjour,

C'est vrai que UTF8 est mieux que l'Ansi, mais je pense qu'il faut mieux utiliser UTF-16.
Pourquoi ?
Tous simplement parce que Windows 2000, XP, Vista, Seven, NT, 2003, 2008 le gère en natif, que Java le gère en mémoire, et que c'est bien géré au niveau des fichiers.

Par exemple, en C, on peut créer une chaine en Ansi ou en UTF-16, et pas en UTF-8. Il existe pleins de fonctions en C ou en C++ pour gérer l'ansi ou utf-16, mais pas en UTF-8. En C, il y a char pour l'ansi et wchar pour l'UTF-16. En C++, il y a string en Ansi, et wstring pour UTF-16. Donc il vaut mieux ne pas utiliser l'UTF-8, mais plutot l'UTF-16.
De plus, les fichier en UTF-16 ont pleins de caractères nuls ce qui permet très vite de le distinguer d'un fichier ansi ou UTF-8. Enfin, les fichier en UTF-16 ont deux caractères au début qui indique si le fichier est en big endian ou en little endian. Donc on peut copier la mémoire dans le fichier sans se préoccuper si le processeur et en big endian ou en little endian.

En Java, toutes les chaines de caractères sont en UTF-16 en mémoire. Toutes convertions vers UTF-8 ralentira le programme.

Enfin, les parseurs XML gèrent nativement UTF-16, les navigateurs web aussi.

Donc pour moi, UTF-16 est mieux qu'UTF-8.

[benwit]

Tulipebleu, tu as raison dans ce que tu dis.
Le seul truc que tu oublies, c'est que utf-8 prend moins de place que utf-16 et dans certains cas, c'est utile.

Après, c'est sûr que c'est toujours un choix espace/temps : ce que je gagne en temps, je le perd en espace et vice versa.

De toute façon, ce qui importe, c'est unicode. Après, l'implémentation ne concerne que les dev.

[TropMDR]

Je me permets rapidement de rappeler que l'UTF-16 (le vrai), n'est pas franchement "plus rapide" que l'UTF-8, puisqu'il n'y a pas non plus d'accès direct au n-ième caractère d'une chaîne. Unicode nécessite 32 bits. Donc si on a un encodage sur brique de base de 16 bits, il faut nécessairement un nombre variable de briques de base.

En revanche, l'UTF-16 a le gros désavantage de ne pas être compatible avec l'ASCII 7 bits, ni avec les "null terminated strings" de C.

Et pour Java, ce n'est pas de l'UTF16 qu'ils ont en natif, mais un stockage sur 16 bits des caractères, qui ne couvre dont *pas* tous l'unicode.

Affirmer que l'UTF-16 est donc "mieux" me parait un peu étrange