Changer de jeu de caractères pour UTF-8

  • Profil : Expert
  • Technologie : (X)HTML
  • Thème : Études de cas, Pages dynamiques
  • Auteur : Nicolas Hoffmann
  • Mise à jour : 22/01/2009

En bref

Préparer l’internationalisation d’un site n’est pas une opération triviale, car dans la plupart des cas, elle nécessite de passer d’un jeu de caractères à un autre. Or, un site Web résulte d’un assemblage de plusieurs logiciels, où les questions de jeux de caractères apparaissent à chaque niveau. Cet article résume les différents points de la configuration d’un site « classique » dans le cadre de l’utilisation d’UTF-8.

Utiliser UTF-8… pourquoi ?

L’essor d’Internet et les tendances à la globalisation s’accompagnent des phénomènes suivants :

L’internationalisation d’un site est souvent une étape cruciale, et souvent assez douloureuse si elle n’est pas préparée. Voici quelques exemples :

Ajoutez à cela que même avec beaucoup de bonne volonté et en parlant la même langue, il est parfois difficile de se comprendre d’un continent à un autre… alors imaginez des machines à la place, et vous aurez une bonne idée de la complexité de la tâche !

Toutefois, plusieurs efforts de standardisation ont été menés, notamment Unicode, et UTF-8 (UCS transformation format 8 bits) découle de cette standardisation :

Comme tous les standards qui permettent d’uniformiser l’accès à l’information et de faciliter la compatibilité entre machines, UTF-8 présente un intérêt majeur sur Internet. Et en effet, dans tous les cas précédents, l’adoption d’UTF-8, jeu de caractères universel par excellence permet d’améliorer la compatibilité des sites au niveau international.

Éléments à prendre en considération

Pour comprendre la relative complexité (au début, on imagine que ce n’est qu’une ligne « meta » à changer), il faut avoir à l’esprit une chose que je vais essayer de vulgariser au mieux : le codage des données est en quelque sorte la « langue » dans laquelle les différents « intervenants électroniques » (base de données, serveur, etc.) vont traduire les 0 et les 1 qu’ils s’échangent, pour vous les afficher de manière intelligible.

Pour plus d’informations à ce sujet, je vous renvoie lire l’article d’introduction aux jeux de caractères.

Pour l’utilisateur, c’est assez simple : le navigateur et le site à afficher doivent se comprendre. Le site envoie du code correctement dans un jeu de caractères donné, et le navigateur l’affiche.

Pour le développeur du site, c’est un petit peu plus complexe. Prenons un cas concret assez classique : un site en XHTML/CSS/Javascript, écrit avec PHP/MySQL et hébergé sur un serveur Apache.

Partons de l’idée somme toute naturelle que tout le monde va devoir parler la même langue, l’UTF-8 donc. C’est là que le tout se complique, il y a plusieurs acteurs « électroniques » dans cette « discussion » pour faire tourner un site :

L’idée est de faire discuter chacun dans la même langue afin qu’ils se comprennent dès qu’ils échangent des données entre eux… et dès qu’ils en fournissent !

Si l’on part de zéro, bien évidemment, c’est plus facile : on choisit des outils (logiciels, bibliothèques, etc.) qui savent gérer l’UTF-8, on prend directement un SGBD (Système de Gestion de Base de Données) qui a cette capacité, etc. Bref, le cahier des charges sera prévu en fonction de cette contrainte. Toutefois, nous nous plaçons dans le pire des cas, où il faut « migrer » un site qui n’a pas été conçu dans cette optique.

Bien sûr, la première chose à faire sera de tout sauvegarder ! Bases de données, fichiers, il faut y aller franchement, cela ne coûte presque rien et peut éviter quelques couacs durant la transition.

Comme un court exemple est bien plus efficace qu’un long discours, voyons les modifications à apporter à notre site exemple !

Serveur

Première chose à changer, dire à notre serveur Apache de nous « donner » de l’UTF-8 car cela n’est pas le cas par défaut. Si vous avez accès à la configuration d’Apache, il faudra remplacer

AddDefaultCharset    ISO-8859-1

par

AddDefaultCharset	UTF-8

Si vous n’avez pas accès à la configuration d’Apache, cette étape se résume alors à modifier l’entête HTTP (header) envoyé par défaut par le serveur, cela peut se faire soit via PHP, soit via un fichier .htaccess.

Via PHP :

<?php
header("Content-Type: text/html; charset=UTF-8"); 
?>

si vous servez votre site comme text/html.

Via un fichier .htaccess, par exemple :

AddDefaultCharset UTF-8
AddCharset UTF-8 .html

Attention, un fichier .htaccess affectera non seulement tous les fichiers du répertoire dans lequel il se trouve, mais également tous les sous-répertoires !

Base de données

Il faut savoir que MySQL peut gérer le codage des données (la langue dans laquelle elles sont « adaptées »), et l’interclassement (la collation en anglais) : comment se comporter avec ces données (comment « comparer » un « é » et un « e », comment gérer la casse, etc.).

En quelque sorte, les règles de la « langue » choisie, pour reprendre l’analogie.

Là, c’est simple, il suffit de changer le codage et l’interclassement pour toute la base.

Exemple plus « visuel » : en supposant qu’on ait phpMyAdmin, il suffit d’aller dans « operations » (pour la base et pour chaque table), et changer l’interclassement. Ensuite, il faut également faire de même pour chaque champ le nécessitant (exemple, des champs de type texte).

Pour ma part, j’ai pris utf8-general-ci pour notre exemple : notre site n’a pas besoin d’être sensible à la casse dans MySQL (un « E » sera égal à un « e » dans une comparaison MySQL), d’où le ci (case insensitive en anglais). Pour information, utf8-general-cs veut donc dire case sensitive, et utf8-general-bin signifie un classement binaire, donc pas d’ordre linguistique à proprement parler.

Attention, cela ne veut pas dire que notre site ne gérera pas les majuscules ou les minuscules (rien à voir), cela « explique » à MySQL (et à MySQL uniquement) comment « appréhender » ces données !

À noter, si vous voulez forcer MySQL à utiliser l’UTF-8, il suffit de lancer cette requête avant toute autre à chaque fois :

SET NAMES 'utf8';

Sans rentrer dans les détails, cette requête « magique » aura le bonheur au passage de dire à MySQL de tout convertir, interpréter et envoyer en UTF-8, donc n’ayez vraiment pas peur de vous en servir. Attention, l’utilisation de cette requête indiquera qu’on se connectera, qu’on enverra et qu’on recevra des données en UTF-8 de la part de MySQL. Cela peut créer des petits soucis avec PHP, comme expliqué ci-dessous.

Le langage dynamique : PHP

Pour PHP… c’est un peu plus compliqué : PHP travaille nativement en ISO, ce n’est qu’à partir de la version 6 qu’il basculera entièrement en UTF-8. Deux modules permettent de gérer différents types de codages, mbstring et iconv.

Le module mbstring s’occupe de la manipulation de chaînes tandis qu’iconv permet de convertir différents types de codage. Les conversions entre ISO et UTF-8 peuvent se réaliser à l’aide des fonctions utf8_encode() et utf8_decode(), qui vont bien souvent vous sauver la mise.

Un exemple simple : supposons qu’un sous-domaine (indépendant de notre projet) prenne néanmoins des données dans cette base récemment convertie en UTF-8. Pour des contraintes de temps, d’argent, etc., il n’est pas possible de passer entièrement ce sous-domaine en UTF-8. Il nécessite pourtant des données en ISO-8859-1. Or elles arrivent en UTF-8 depuis la base : l’affichage des données sur ce sous-domaine va poser des problèmes.

Pour reprendre l’analogie linguistique : c’est comme si une entreprise choisit l’anglais comme langue officielle interne, et qu’un département de cette société est uniquement francophone. Le temps d’apprendre l’anglais pour ce département, il faut en quelque sorte des traducteurs le temps de l’apprentissage !

L’utilisation de utf8_decode() nous permettra d’afficher ces données de manière lisible à moindre effort, sans « Ã© » à la place de certains caractères accentués.

Attention aux bibliothèques de code et aux fonctions de traitement de caractères qui ne travaillent qu’en ISO, il faut les traiter avec le plus grand soin, si vous ne voulez pas avoir de grosses surprises !

XHTML

Le bout du tunnel se rapproche… pour XHTML, c’est assez simple dans notre cas :

<?xml version="1.0" encoding="UTF-8" ?>

pour le prologue XML ainsi que

<meta http-equiv="Content-Type" content="application/xhtml+xml;" />

pour indiquer au navigateur un type MIME application/xhtml+xml ou

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

pour le servir en classique text/html.

Fichiers du site

Il reste enfin à s’occuper des fichiers du site. Eux aussi doivent être codés en UTF-8, notamment pour que le texte écrit « en dur » dans les pages soit bien retranscrit, étant donné que tout le site va parler dans « la langue » UTF-8. Les fichiers doivent donc également s’y plier.

Là, il vous suffit de trouver un éditeur de code qui gère cela, beaucoup le permettent. Notepad++ (sous Windows) le fait par exemple très bien, et peut même convertir vos fichiers d’un codage à l’autre. Des outils plus automatiques permettent de coder des fichiers à la volée.

Attention, certains éditeurs spécifient en début de fichier un marqueur d’ordre des octets (BOM, Byte-Order Mask en anglais). C’est inutile pour l’UTF-8, et même dangereux : le fait d’insérer ce caractère au début d’un fichier php (donc avant la balise d’ouverture de php) pourra provoquer une erreur du type « headers already sent »… à fuir de toute urgence !

Du côté des fichiers externes (Javascript et CSS), il est logique de coder également les fichiers en UTF-8 afin de continuer dans notre optique « tout UTF-8 ». Cette pratique n’est pas totalement entrée dans les mœurs pour une raison simple : les éléments XHTML sont en anglais et donc sont dépourvus d’accents dans la CSS. De la même manière, on code en anglais en Javascript.

Comme ASCII et UTF-8 ont un « tronc commun », les problèmes de codage des données ne sautent pas aux yeux !

Qui peut le plus peut le moins : autant s’assurer la tranquillité d’esprit que les commentaires (par exemple) soient bien retranscrits.

Pour déclarer le jeu de caractères de ces fichiers, on peut reprendre l’idée du fichier .htaccess, par exemple :

AddCharset UTF-8 .js
AddCharset UTF-8 .css

Pour les CSS, on peut aussi utiliser la « at-rule » @charset, il suffit de l’indiquer au tout début de votre CSS (avant tout caractère) :

@charset "UTF-8";

Attention, cela n’a de sens que pour une CSS externe, et ne doit pas être utilisé pour des styles inclus directement dans les documents.

La plupart des éditeurs récents gèrent bien ce jeu de caractères, donc pas trop de souci à vous faire ce côté-là. L’idéal étant que tous les éditeurs utilisés pour le développement ou les mises à jour reconnaissent et traitent correctement les fichiers en UTF-8… ainsi on évitera de fâcheux problèmes de codage qui peuvent entraîner… de fâcheux problèmes d’affichage !

Conclusion

On peut constater que le passage à l’UTF-8 s’il n’a pas été prévu dés le départ n’est pas complètement anodin. Il faut donc autant que possible prévoir cette option en amont des projets… Un site peut se retrouver rapidement confronté à cette contrainte d’internationalisation, et il ne serait pas sérieux de se retrouver complètement bloqué à cause de ce genre de problème !

D’ailleurs, la plupart des projets collaboratifs (forums, CMS, etc.) s’y sont mis… ce n’est pas pour rien !

Références

Une question, une remarque ? Écrivez à l'auteur.

Page valide XHTML 1 Strict, CSS2 et accessible AA.
Ce site s'affiche mieux dans un navigateur conforme aux standards, voici pourquoi.
Site hébergé par l'APINC et propulsé par SPIP.