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 (...)
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 !
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 :
charset
de l'entête HTTP Content-Type
http-equiv
charset
dans la balise de lien vers cette page (usage
et support anecdotique, nous ne reviendrons pas sur l'usage de cet attribut)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 !
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.
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.
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 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 :
ô
Ô
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...
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 ? Rendez-vous sur le dépôt GitHub !