La chaîne d’encodage UTF-8… de la requête client à la réponse serveur.

Lors de la mise en production d’une application web, j’ai du faire face comme tout programmeur un jour ou l’autre à un problème, assez pénible, de charset:

Les accents (é, à et les ç) qui passaient pourtant sans broncher sur le serveur de dévelopement s’affichaient « cassés » sous forme Ä�… Bref de l’iso 8859 est venu mettre son nez dans notre circuit en UTF-8!

Les basiques à vérifier:

1. entêtes des header lors de la requête, et lors de la réponse http:

Pour vérifier les headers HTTp, je vous conseille l’excellent Live HTTP headers, plugin pour firefox…

Ils doivent spécifier un mime-type correct, suivi d’un point virgule et « charset=UTF-8 »

Cela se paramètre soit au niveau de votre serveur applicatif (header() en PHP, setContentType() avec J2EE / Java EE) soit au niveau d’Apache (directive addDefautCharset).

2 Encodage du document:

Le document HTML doit préciser la ligne meta suivante:

<meta content= »text/html;charset=utf-8«  http-equiv= »Content-Type« />

A partir de ces deux étapes tout document chez le client est donc en utf-8. Mais le problème persistait dans mon cas!

3 Le système d’exploitation

Taper locale charmap sous linux pour connaitre le charset utilisé par le système, en général UTF-8 par défaut sur les sytèmes récents, sinon un dpkg-reconfigure locales sera nécessaire (Debian).

4 Le serveur applicatif

Pour php, je ne peux plus rien pour vous, il ne gère pas l’utf8 en natif (bouuuuh, la honte !!!), il faudra vous renseigner ailleurs sur ce sujet…Pour ce qui est des objets javascript, l’utf ne sera pas cassé car javascript gère parfaitement bien l’UTF-8 en natif par défaut. Java est par défaut en utf-8. A tout hasard, on peut forcer son usage en passant le paramètre Dfile.encoding=UTF-8 à la JVM. Si vous lancez un serveur tomcat sous linux, il suffit pour cela de spécifier dans le script de démmarage du service: « CATALINA_OPTS= »-Dfile.encoding=UTF-8″« . Si vous utilisez un frontend, le passage de paramètres via l’url peut également casser l’utf-8 … Configurez votre connecteur correctement avec l’attribut URIEncoding dans le server.xml. Voici un exemple:

<Connector port= »8080″ maxThreads= »150″ minSpareThreads= »25″ maxSpareThreads= »75″ enableLookups= »false » redirectPort= »8443″ acceptCount= »100″ debug= »0″ connectionTimeout= »20000″ disableUploadTimeout= »true » URIEncoding= »UTF-8« />

5 Le code source

Concernant mon problème, ce n’était toujours pas reglé… J’étais désespéré, et je noyais mon chagrin en relisant la javadoc, quand soudain je tombai sur le deus ex machina du cycle de dévelopement d’une WebApp:

request.setCharacterEncoding(« UTF-8 »);
response.setCharacterEncoding(« UTF-8 »);

6. Encore plus loin

Ouf! Pour moi l’aventure de la chasse à l’ISO 8859 était terminée, l’utf-8 regnait en maître, les derniers morceaux encodés en ISO se cachaient dans les recoins les plus sombres de la mémoire vive avant de mourir lors d’un sanglant reboot. Mais pour toi, lecteur qui cherche à résoudre ton problème d’encodage de caractères accentués, il faudra encore t’assurer que le reste de ta chaine de développement ne corrompt pas l’UTF 8. Par exempe, MySQL, crée tout ses tables en charset ISO latin par défaut :

ALTER TABLE `table_name` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin fera probablement l’affaire pour modifier a postériori une mauvaise création de table…

référence : http://dev.mysql.com/doc/refman/5.0/fr/charset-general.html

Et puis… votre éditeur de texte doit lui aussi être configuré avec le bon charset… un erreur qui fait toujours sourire mais c’est parfois son propre outil qui ne sauve pas les fichiers avec le bon charset !

En espérant que cette petite checklist vous aura dépannés !