Charset iso-8859-1, iso-8859-15, utf-8, le problème du Charset
Si il y a bien un problème qui peut virer au casse-tête chinois, c’est bien celui de l’encodage de caractère dans un fichier, une page web ou tout document que vous diffusez et qui se révèle truffé d’erreurs d’encodage.
Arrête ton Charset en dur…
Comment diagnostiquer le problème ? Un symptôme simple, vous voyez apparaître des signes cabalistiques dans vos pages html par exemple. Je vous livre in extenso le diagnostic de http://electron-libre.fassnet.net/utf8.php qui détaille brièvement les moyens de déterminer le bourbier numérique dans lequel vous venez de sauter à touches jointes !
Il donne les symptômes et les soins simples de première urgence.
Reconnaissance rapide des problèmes d’affichage UTF-8 ISO
Cas N°1
Si la page affiche des caractères de ce type : “é”, “î”, “Ô, …
=> Les données ont été enregistrées au format UTF-8, et le navigateur les affiche en pensant avoir affaire à de l’ISO.Cas N°2
Si la page affiche des caractères de ce type : “�”
=> Les données ont été enregistrées au format ISO, et le navigateur les affiche en pensant avoir affaire à de l’UTF-8.Si les données sont codées en dur dans la page, voir l’encodage de l’éditeur de texte, le header apache et la balise meta “charset”.
Si les données proviennent de la base, vérifier le format de stockage et les méthodes de lecture et d’insertion (SET NAMES et charset).
Si les données proviennent de l’extérieur (web services, rss, …), penser à convertir les chaînes de caractère (utf8_encode-decode et fonctions du module iconv).
Le mal est déjà fait… Que puis-je faire ?
Il arrive notamment dans le cas d’une BDD que la corruption ait eu lieu. Vous vous retrouvez par exemple avec une BDD codé à l’origine en utf-8 mais dont l’unique sauvegarde que vous possédez est un “dump” (un fichier .sql) fait et ouvert sur une machine en iso-8859-1, un windows par exemple.
Le cas de la BDD corrompue
Si vous popularisez à nouveau ce “dump” (.sql) dans votre BDD et que vos pages continuent de se charger en UTF-8, vous êtes alors dans le Cas N°2 décrit plus haut.
Si vous décidez de cautériser le problème directement dans le client MySQL via le client SSH, dans putty par exemple, n’oubliez de changer les spécifications de “translation” en sélectionnant UTF-8 afin de taper vos requêtes SQl en utf-8. Vous pourrez alors passé allègrement des requêtes, voir même des copier-coller, depuis votre poste ISO sur le serveur en UTF-8.
Changer les propriétés de traduction dans Putty
Pour télécharger Putty, vous pouvez vous rendre à cette adresse
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.
Le cas de XML pour flash
Un cas qui est rarement évoqué, c’est le xml chargé dans flash, bien qu’il s’agisse rigoureusement de problèmes similaires.
Pour éviter parfois des problèmes à répétition, vous pouvez vous rabattre sur l’encodage hexadécimal des caractères accentués… ainsi donc de créer des xml pour vos applications flash sans erreur…
ç s'écrit ç è s'écrit è é s'écrit é ê s'écrit ê |
Le plus sur quelque soit le “charset” que vous définissez c’est de remplacer les caractères accentués par leurs équivalents hexadécimaux.
<?xml version="1.0" encoding="UTF-8"?> <commitments> <mantra id="one">Cette été je pars pour apprendre le français à Paris</mantra> <mantra id="two">Les accents ont été mon pire cauchemar</mantra> </commitments> |
<?xml version="1.0" encoding="UTF-8"?> <commitments> <mantra id="one">Cette été je pars pour apprendre le français å Paris</mantra> <mantra id="two">Les accents ont été mon pire cauchemar</mantra> </commitments> |
Il existe des outils de traduction en ligne qui vous donneront les équivalents.
http://rishida.net/scripts/uniview/conversion.php
Enfin, vous pouvez toujours vous référer à la sainte bible du charset.
http://www.w3.org/International/O-charset.fr.php
Le doctype
Disons que pour résumer, le dilemme se pose dans le choix du doctype entre “transitional” et “strict”. Il est certain que si vous choisissez de publier avec un doctype strict, l’obtention de la validation par le validator W3C va se montre plus délicat.
Néanmoins, cela n’est pas impossible que vous puissiez valider ainsi vous pourrez affubler vos pages du logo qui atteste de la validité de vos pages.
La déclaration d’un doctype n’est requise que pour la validation.
Le doctype Transitional
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
Le doctype strict
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> |
Les icônes W3C
Si vous souhaitez faire de l’évangélisation, vous pouvez aussi toujours ajouter ce petit logo…
Le “W3C Markup Validation Service”
http://validator.w3.org/
L’en-tête à l’emploi
C’est la balise meta qui va indiquer au navigateur comment interprèter un document web.
L’en-tête UTF-8
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
L’en-tête iso-8859-1
<http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> |
Le tableau des équivalences
Le tableau de toutes les équivalences pour le chartset ISO 8859-1 Character Set ( Latin – 1) – Western / West European
http://www.tableascii.com/iso88591.htm
Pour aller plus loin
Les règles simples pour passer son site de iso à utf-8
Un récapitulatif bien fait sur la déclaration et les en-têtes
