![ucs-encoding[1]](http://lh6.ggpht.com/_jqKGlYfNZVA/StCHKklTQfI/AAAAAAAAE1o/05MtviZs9lE/s1600-h/ucs-encoding%5B1%5D%5B8%5D.png "ucs-encoding[1]")
Je viens de perdre une nouvelle journée de boulot sur des %!@$ problèmes d’encodage. Encore un N-ième fichier XML dont l’entête déclare fièrement un encoding=UTF-8, et qui se retrouve charcuté à la sauce CP-1252 (variante MS de l’ISO-8859-1).
Dire que depuis toutes ces années à inventer des formats interopérables et tout et tout on en est encore là ça fait pitié. J’en suis à me demander s’il n’existerait pas un petit plugin Eclipse bien malin pour convertir à la volée tous nos accents en entités xml ou en échappement Unicode – il y a par exemple le plugin propertiesEditor qui fait ça très bien … pour les fichiers properties.
C’est peut être l’occasion de devenir totalement bilingue et de tout rédiger en anglais, histoire de ne plus sortir du bon vieux ASCII 7 bits qui est finalement le seul moyen de ne pas se prendre la tête.
Le build Maven est un peu (!) plus stable grâce à l’option project.build.sourceEncoding mais ce n’est pas encore la panacée : il semble que le générateur de code de CXF (wsdl2java) produise du code source dans l’encodage “local”… pas gagné cette affaire.
6 commentaires:
Salut,
je compatis. J'ai pris le parti de ne plus mettre d'accent (j'encode les properties à la main) et pour le reste (commentaire de code ou autre) je ne mets plus d'accent. J'écris en Anglais la majorité, si on me demande d'écrire en Français, je ne mets pas d'accents sauf si cela m'échappe...
Je me suis encore fait avoir mercredi avec une release maven qui plantait sur la création du changelog.xml, j'avais glissé un accent dans un commentaire de commit...
C'est à peu près les même circonstances : J'ai pris l'habitude de non-accentuer mon code, mais il a suffit d'une fois au mauvais endroit (dans mon POM) et le build Hudson plante sur un beau stacktrace incompréhensible. Reste à retrouver d'où peut bien venir le problème parmi les 25 modules du projet ... :(
Ah, les accents mal encodés. Dans la même famille, je mettrais au palmarès des problèmes les plus récurrents :
- les apostrophes et tirets convertis par Word (CP1252 only) joyeusement copiés-collés des specs dans le code
- les BOMs dans le fichiers XML et Java (plante la compil sur certaines plateformes)
Avec une mention spéciale pour ces éditeurs qui détectent mal les encodings, créant ainsi des fichiers multi-encodings...
> histoire de ne plus sortir du bon vieux ASCII 7 bits
Mouai. Pour moi la solution serait plutôt de faire disparaître tout autre encodage qu'UTF-8. Mais ne rêvons pas trop. :-)
Il me semble plutôt qu'on n'a pas trop le choix et qu'il nous faut vivre avec les encodings. Parce qu'effectivement, on peut contourner le problème en évitant les accents dans notre code/commentaire/pom.
Mais pour les fichiers properties, par exemple, on n'échappe pas à une bonne maitrise du fonctionnement d'un encodage, de comment transcoder d'un encodage à un autre (et de ce qu'est la translitération, donc), et l'écriture du caractère sous forme de point de code unicode pour supporter tous les caractères de la planète...
Je doute que nos clients apprécient qu'on leur dise : ben vous voyez, là ça va pas être possible de mettre des accents ou d'afficher le signe €, en fait :-)
Personnellement, j'ai plutôt tendance à utiliser sans restriction les accents et tous les caractères légaux du moment qu'ils sont bien dans le bon encoding.
Le problème, c'est que peu de développeurs ont bien compris ce qu'étaient encodage et jeu de caractères. Lorsqu'ils se retrouvent face à un simple problème simple d'affichage de "?". Ils ne savent pas du tout quoi faire et maudissent "l'encoding" alors qu'ils ont parfois fait n'importe quoi avec les données.
Cas récent : on stocke un fichier XML sur le disque (qui spécifie un encoding, donc), puis plus tard, on le charge dans une String sans indiquer quoi que ce soit en encoding (i.e. avec l'encoding de la plateforme), bref, de la merde chargée, manipulée puis restockée ailleurs sans jamais prendre en compte l'encoding source et cible ! Et ensuite, on passe du temps à savoir à quel endroit on a commencé à coder n'importe comment...
Ça, ça explose dès que le fichier XML n'a pas le même encoding que la plateforme... :-/.
Pour moi, le problème est donc davantage un problème de communication/formation. Si tous les développeurs maitrisaient mieux ce domaine, on serait moins souvent dans la mââârde :-). Parce que même si yen a un qui maitrise bien et fait attention à éditer le fichier avec un éditeur qui gère l'encodage, yen aura toujours un autre qui va le faire, ajouter des accents et avec un éditeur qui stocke uniquement du cp1252 (au hasard).
L'article le plus connu à ce sujet : http://www.joelonsoftware.com/articles/Unicode.html
Ou le même traduit :http://french.joelonsoftware.com/Articles/Unicode.html
Et aussi : http://genezys.net/blog/post/99-comprendre-les-jeux-de-caracteres
@++
Ca vient qu'en même sacrément de l'OS primitif sur lequel on développe la plupart du temps.
Désolé mais sous Linux ça fait longtemps que tout se fait en UTF-8 et le moindre éditeur de texte un peu évolué sait préciser l'encoding d'entrée et de sortie (kate par exemple le fait très bien).
Même vim est en UTF-8. Le jour où M$ fera l'effort d'utiliser l'UTF-8 dans le coeur on sera enfin sorti de cet enfer...
Comme de nombreux Linuxiens tu me semble bien "définitif" sur tes prises de positions ;)
Notepad++ ou Eclipse sait tout aussi bien gérer les divers encodages, et MS pourrait tout aussi bien dire que c'est à Nunux de passer en ISO-8859-1, et nos amis asiatiques pourraient te dire que ton chouchou devrait être en Big5 par défaut plutôt qu'UTF-8 !
Plus sérieusement, le problème n'ai pas de savoir qui a raison, mais de constater que le syndrome de la tour de Babel est encore bien vivant.
Le problème d'encoding est mal compris, mal géré. Je suis tombé sur un bug dans le compilo JAXB (xjc) qui génère le code source selon l'encodage natif, alors que je précise celui utilisé par javac dans mon build...
Le problème de mon point de vue c'est que l'API Java ne devrait PAS proposer d'utiliser un encodage par défaut non déterministe. Comment sans cela parler de portabilité ?
Enregistrer un commentaire