Encodage et programmation
Les caractères qui s’affichent sur les écrans d’ordinateur, comme toute donnée informatique, ne sont qu’une sucession de 0 et de 1 du point de vue de la machine. C’est le nombre et l’ordonnance de ces bits qui définissent la norme d’un encodage. Plus le nombre de bit sera élevé, plus l’encodage supportera de caractères.
Les problèmes que l’on peut rencontrer lors du passage à l’UTF-8 viennent de cette différence de norme avec l’encodage européen ISO. Entre ces deux normes les problèmes vont se situer au niveau des caractères « spéciaux » comme les caractères accentués.
A côté des problèmes que cela peut impliquer, l’UTF-8 permet de gérer un plus grand nombre de caractères, donc de gérer des langues aux glyphes exotiques, ce que ne permet pas l’iso avec ses 256 possibilités.
Mais si l’UTF-8 permet de telles choses c’est qu’il est codé sur plus de bits que l’ISO, et si cela influe sur l’affichage, cela influe forcément sur le traitement des chaînes au niveau de la programmation et du stockage en base de données.
Imaginons que l’on veuille connaître la longueur de cette chaîne : ‘éé’. Basiquement un langage comptera le nombre de bits que contient cette chaîne.
Une fonction dédié à cette tâche trouvera 16 bits, soit deux octets, soit deux caractères en ce qui concerne l’ISO. En revanche cette même fonction trouvera 32 bits sur un encodage UTF-8, donc renverra une valeur de 4 caractères si elle croit avoir affaire à de l’ISO…tel est le problème.
Ce tutoriel couvrira donc la mise en place d’un environnement conforme, son utilisation ainsi qu’une reconnaissance rapide des problèmes d’affichage entre l’UTF-8 et l’ISO.
Plus d’infos sur l’encodage -> les bases
Plus d’infos sur l’encodage -> UTF-8
Préparation de l’environnement
Pour être sûr que tout fonctionne correctement il est impératif que l’ensemble de l’environnement soit aux normes afin de ne pas tout mélanger, oublier d’enregistrer ses sources au bon format et toutes les configurations du serveur deviennent aussi efficaces que le néant.
Editeurs et BOM
Les fichiers doivent être encodés en utf-8. A priori simple, cela dépendra du bon vouloir de l’éditeur de texte.
Certains éditeurs spécifient en début de fichier un marqueur d’ordre des octets (bom en anglais), qui plus est inutile pour l’utf-8.
Le fait d’insérer ce caractère au début d’un fichier php (donc avant la balise d’ouverture <?php) pourra provoquer une erreur du type « headers already
sent ».
Il faut donc veiller à ne pas laisser l’éditeur insérer un tel caractère (notepad ou encore scite si l’on ne spécifie pas « UTF-8 Cookie »).
Code HTML
Pour le code HTML il suffit de spécifier l’encodage à l’aide de cette balise :
<meta http-equiv="Content-type" content="text/html; charset=UTF-8"/>
Apache
Historiquement apache travail en ISO-8859-1, c’est donc dans cette norme qu’il risque d’envoyer ses entêtes.
L’instruction à modifier dans le httpd.conf ou dans un .htaccess :
AddDefaultCharset UTF-8
Sinon via php :
header('Content-type: text/html; charset=UTF-8');
Pour connaître l’entête utilisé par un serveur apache il suffit de regarder l’encodage lors de la réception d’une page à l’aide de son navigateur (à peu de choses près en fonction de la famille : affichage -> encodage).
Sinon ici.
! L’entête http fait autorité face à la balise meta !
MySQL
Mysql supporte pleinement l’UTF-8 depuis la version 4.1. Les instructions données ici fonctionneront à partir cette architecture et un développement sérieux en UTF-8 se fera à l’aide d’un milésimme égale ou postèrieur à celle-ci.
Donc oui il est possible de stocker des données unicode dans une base 3.23, mais il faut s’attendre à ce qu’une chaîne de 25 caractères cyrilliques soit tronqué dans un champs varchar de 40 (sans parler des problèmes liés aux fonctions SQL).
Dans le cas présent l’ensemble des instructions se fera à l’aide de commandes sql et non pas à partir de directives de compilation ou d’instructions du my.cnf.
Exemple de la création d’une base :