Informatique
Internationalisation
Web & charset : internationalisation pour le concepteur Web

Cet article détaille les moyens de spécifier le codage (charset, encoding, ...) sur des pages web. Ces connaissances permettront par exemple d'ajouter du néerlandais sur un site qui était prévu pour de l'anglais uniquement, de se passer entités comme des ±, ou de retrouver les caractères attendus plutôt que des carrés, etc etc (...)

Table des matières + X

Pourquoi spécifier le codage ?

Les contenus envoyés à un client par un serveur HTTP peuvent être libellés explicitement pour être lus en utilisant un codage précis. Cependant, on peut penser que ces indications ne seraient pas nécessaires : en effet, le chapitre 3.7.1 de la RFC 2616[1] définit ISO Latin-1 comme codage par défaut pour HTTP :

The "charset" parameter is used with some media types to define the character set (section 3.4) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or its subsets MUST be labeled with an appropriate charset value.

Le Web étant d'origine Européenne, on peut comprendre la présence de cette valeur par défaut ! Cependant les éditeurs de navigateurs ont tous laissés paramétrable le codage à utiliser si aucune information n'est fournie par le serveur... Car beaucoup de pages ont été mises à disposition sans aucune information de codage... Et un utilisateur d'Europe de l'Est voudra sans doute que son navigateur essaie d'ouvrir de telles pages en iso latin-2 par exemple !

Cet argument est tout de même à tempérer par l'implémentation de mécanismes d'autodétection du codage dans certains navigateurs (par exemple, dans MSIE 6, menu affichage / codage / sélection automatique, ou dans Firefox menu View / Character encodings / Auto-Detect). Cependant ces mécanismes sont forcément complexes, au vu du nombre de codages différents existants, et sachant qu'ils ne sont pas tous basés sur us-ascii...

Par ailleurs, les serveurs disposent souvent d'une configuration par défaut qui leur fait renvoyer certaines informations de codage... Qui indiqueront peut être un codage différent de celui réellement utilisé sur votre site !

Par conséquent, il est donc fort utile de renvoyer au client explicitement les bonnes informations de codage !

Prérequis

Méthode pour indiquer au client quel codage est utilisé

Introduction

Par nature, l'information de codage ne peut être contenue dans le fichier : pour être en mesure d'ouvrir ce fichier, il faut connaitre ce codage... Et s'il faut ouvrir le fichier pour connaitre son codage, on tourne en rond ! :D

Où va exactement être lu l'information de codage par le client ? Hé bien, potentiellement à plusieurs endroits :

Quelle est la priorité de lecture ? C'est le chapitre 5.2.2 de la reccommandation HTML 4[2] qui donne la réponse :

To sum up, conforming user agents must observe the following priorities when determining a document's character encoding (from highest priority to lowest):
1. An HTTP "charset" parameter in a "Content-Type" field.
2. A META declaration with "http-equiv" set to "Content-Type" and a value set for "charset".
3. The charset attribute set on an element that designates an external resource.

C'est l'entête HTTP qui est prioritaire... Et c'est celui sur lequel le concepteur peut le moins facilement intervenir !

Pour XHTML, le principe est également le même, on y reviendra plus bas !

Paramétrer le serveur (entête HTTP Content-Type)

Aujourd'hui, quasiment tous les serveurs disposent de cette valeur définie par défaut... Et même si votre serveur actuel ne renvoit aucune information, en cas de transfert vers un autre hébergeur vous pourriez avoir de mauvaises surprises...

La méthode à suivre pour forcer la valeur pour cet entête dépend du logiciel serveur employé. Notez aussi que si votre site est dynamique, il est quasi certain que le langage utilisé vous permette de renvoyer les entêtes de votre choix au client de manière atomique (uniquement pour les pages qui vous intéressent) !

Le document "Le paramètre HTTP Charset"[4] du W3C donne des indications précieuses sur la marche à suivre pour que l'entête soit correctement renseigné - des méthodes pour les serveurs et langages les plus courants y sont listées.

La balise META

D'abord, bien comprendre que toutes les balises http-equiv sont des pis-aller : elles permettent de préciser des informations qui devraient normalement figurer dans les entêtes HTTP !

Par ailleurs, l'information de codage est par nature une meta donnée : pour ouvrir le fichier et lire le meta, on doit connaitre le codage...

On peut par conséquent considérer que spécifier le codage par une balise META est inutile et que l'entête suffit. Cependant, plusieurs voix s'élèvent pour défendre l'usage du META : en effet, une page n'est pas forcément lue depuis un serveur HTTP donné, on peut la lire via un système de fichiers ! Le meta donne alors la possibilité au navigateur, via le système d'autodétection auquel on faisait allusion précédemment de détecter quel est le codage à utiliser pour lire le document.

A tempérer quand même : MSIE Windows par exemple permet d'enregistrer une page avec le codage de son choix, et insère dans le fichier une balise META appropriée au choix de codage effectué par l'utilisateur pour la sauvegarde.

Le cas particulier de XHTML

XHTML étant du XML, l'information de charset est présente dans le prologue XML, en début de fichier :

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

Toutefois, du XHTML 1.0 servit en text/html devra conserver la balise meta pour compatibilité : en effet dans ce cas le XHTML sera lu comme du HTML invalide !
Ce comportement est définit dans le chapitre 9 de l'annexe C de la recommandation XHTML 1.0[3] :

In order to portably present documents with specific character encodings, the best approach is to ensure that the web server provides the correct headers. If this is not possible, a document that wants to set its character encoding explicitly must include both the XML declaration an encoding declaration and a meta http-equiv statement (e.g., <meta http-equiv="Content-type" content="text/html; charset=EUC-JP" />). In XHTML-conforming user agents, the value of the encoding declaration of the XML declaration takes precedence.

Les entités

Les entités sont un mécanisme particulièrement performant permettant d'intégrer à son document, quelques soit son codage, n'importe quel caractère du jeux ISO 10646.
Il existe deux types d'entités :

nommées
Exemple : &ocirc;
L'ensemble des entités nommées sont définies dans la DTD HTML ou XHTML utilisée. Par exemple, la liste des entités nommées en HTML 4
numériques
Exemple : &#212;
Référence au code point Unicode (enfin plutôt au numéro de caractère ISO 10646, mais les 2 sont identiques), exprimé sous forme numérique (#<code point>) ou hexadécimale (#x<code point>).
Le support très réduit pour la forme hexadécimale restraint à ce jour son usage.

Traitement de données issues de la soumission de formulaires

On lancera cette conclusion obtenue après lectures de différents documents et contributions Usenet :

Et on ne peut que conseiller la lecture attentive du meilleur document que l'on ait pu trouver à ce jour sur le sujet : FORM submission and i18n de Alan J Flavell. D'ailleurs, on retourne s'y plonger de ce pas...

Liens

Spécifications

Sites intéressants

Remerciements

Merci à Stéphane Moriaux (ASM sur f.c.i.w.auteurs) pour ses compléments !

Création le 16/07/2005
Dernière mise à jour le 22/08/2014

Un oubli, une erreur, une suggestion ? N'hésitez pas à me contacter sur pgoiffon -at- free.fr