Jeux de caractères des documents HTML 

Contenu

  1. Le codage des caractères du Document (Character Set)
  2. Les entités Caractères

Les langues humaines définissent un grand nombre de caractères de texte et les Hommes ont inventé un grande variété de systèmes pour représenter ces caractères dans un ordinateur. A moins de précautions extrêmes, des représentations différentes pour les caractères peuvent ne pas être reconnues par les différents agents dans toutes les parties du monde.

Le codage des caractères du document 

Pour aider à l'interoperabilité, le SGML préconise que chaque application (y compris l'HTML), dans sa définition, définisse son codage des caractères du document. Un code de caractères du document est un ensemble de caractères (comme la lettre cyrillique "I", le caractère chinois signifiant "eau", etc.) ainsi que la séquence de nombres (références) identifiant ces caractères. Le SGML considère un document comme étant une séquence de références numériques codées dans le codage de caractères du document.

Le codage de caractères pour des documents HTML est l'Universal Character Set (UCS) de l'[ISO10646]. Cet ensemble est équivalent caractère-à-caractère à l'Unicode 2.0 ([UNICODE]). Chacun de ces deux standards sont complétés de temps à autres avec de nouveaux caractères et les mises à jour devront être consultées sur les sites Web respectifs.

Dans la présente, les références à l'ISO/IEC-10646 ou à l'Unicode impliquent le même codage de caractères du document. Cependant, le présent document se réfère aussi à la spécification Unicode à d'autres titres tels que l'algorithme de texte bidirectionnel.

Des agents HTML conformes doivent recevoir ou générer un document, ou représenter en interne un document, utilisant n'importe quel jeu de caractères. Un jeu de caractères représente un certain sous-ensemble du code de caractères du document. Des jeux de caractères tels que l'ISO-8859-1 (souvent nommé "Latin-1" car il encode la plupart des langues Occidentales), l'ISO-8859-5 (qui supporte le Cyrillique), SHIFT_JIS (un jeu pour le Japonais), et euc-jp (un autre jeu pour le japonais) permettent de gagner de la bande passante en ne transmettant qu'une partie réduite du code de caractères du document.

Ainsi, les jeux de caractères permettent aux auteurs de travailler avec un sous ensemble convenable du code de caractères du document. Les auteurs ne doivent en rien connaître les détails de l'encodage sous-jacent des caractères dans le document ou par l'outil qu'ils utilisent --- écrire du Japonais avec un éditeur UTF-8 est aussi facile que l'écrire avec un éditeur JIS ou SHIFT_JIS.

Le jeu de caractères signifie aussi que les auteurs n'ont pas à saisir le texte des documents sous la forme des références au code de caractères. Obliger les auteurs à travailler avec un codage aussi exhaustif serait trop lourd et inutile (bien que certains codes tels qu'UTF-8 couvrant tout l'Unicode existe).

Pour permettre cette optimisation, les agents conformes doivent correctement faire correspondre à l'[UNICODE] tous les caractères définis par tout jeu de caractères ("charsets") qu'ils reconnaissent (ou du moins réagir comme si). Une liste des jeux de caractères recommandés pour divers scripts et langages doit être fournie dans un document séparé.

Comment un agent sait-il quel jeu de caractères a été utilisé pour encoder un document donné ?

Dans de nombreuses situations, avant qu'un serveur Web n'envoie un document HTML sur le Web, il essaie d'en déterminer le jeu de caractères (par un certain nombre de techniques comme l'examen des premiers octets du fichier, la vérification de son encodage par rapport à une base de fichiers types dont le jeu est "connu", etc.). Le serveur transmet le document et le nom du jeu de caractères à l'agent récepteur par l'intermédiaire du paramètre charset du champ "Content-Type" du protocole HTTP. Par exemple, l'en-tête HTTP suivante annonce que le jeu de caractères est l'"euc-jp".

Content-Type: text/html; charset=euc-jp

La valeur du paramètre "charset" doit être le nom d'un jeu de caractères défini dans la [RFC2045].

Malheureusement, tous les serveurs n'envoient pas l'information concernant l'encodage de caractères (même lorsque le jeu utilisé est différent du très répandu ISO-8859-1). L'HTML permet pour cette raison aux utilisateurs de prévenir leur agent quel jeu de caractères a été utilisé, par une spécification explicite dans l'en-tête de document avec un élément META. Par exemple, pour spécifier que le jeu de caractères du document courant est "euc-jp", incluez la déclaration META suivante :

<META http-equiv="Content-Type" Content="text/html; charset=euc-jp">

Ce mécanisme a une limite notable : l'agent ne peut pas interpréter l'élément META pour déterminer le jeu de caractères s'il ne connaît déjà pas à l'origine le jeu du document lui-même. La déclaration de l'élément META ne doit être utilisée que lorsque le document est organisé de sorte que les caractères ASCII aient une signification directe (ASCII) au moins jusqu'à ce que la déclaration META puisse être interprétée. Dans un tel cas, les agents conformes doivent nécessairement correctement interpréter l'élément META.

Pour résumer, des agents conformes doivent respecter les priorités suivantes lors de la détermination du jeu de caractères d'un document, (de la plus haute à la plus faible priorité) :

  1. Une action explicite de l'agent utilisateur pour éviter les comportements "étranges".
  2. Un paramètre "charset" dans le champ "Content-Type" du HTTP.
  3. Une déclaration d'un élément META avec un "équivalent http" d'un ensemble "Content-Type" avec une valeur pour le paramètre "charset".
  4. Un attribut "charset" marqué pour les éléments A et LINK.
  5. Les heuristiques et préférences utilisateur de l'agent. Par exemple, lorsque les agents supposent que le jeu de caractères, en l'absence de toute autre indication, est l'ISO-8859-1. Cette supposition peut conduire à une représentation illisible de certains documents.

Dans tous les cases, la valeur de l'attribut ou du paramètre "charset" doit être le nom d'un jeu défini dans la [RFC2045].

Si, pour une application spécifique, il apparaît nécessaire d'utiliser des caractères en dehors de l'[ISO10646], ces caractères devront être contraints à une zone privée pour éviter tout conflit avec les versions présente ou futures du standard. Ceci reste néanmoins fortement déconseillé, pour des raisons de portabilité.

Note: Les serveurs Web actuels peuvent être configurés par une information indiquant quel document utilise quel jeu de caractères. Les Webmasters pourront utiliser cet avantage mais devront prendre la peine de configurer le serveur correctement.

Entités Characters 

Vos configurations matérielles et logicielles ne vous permettront certainement pas de pouvoir faire référence à tous les caractères Unicode par des mécanismes simples, et SGML offre un mécanisme pour coder tout caractère du code de caractères du document, indépendamment du jeu.

Les références numériques de caractères spécifient le numéro d'un caractère Unicode. Une référence numérique de syntaxe &#D; se réfère à un caractère Unicode de code décimal D. Une référence numérique de syntaxe &#xH; se réfère à un caractère Unicode de code hexadécimal H. La représentation hexadécimale est une nouvelle convention SGML et est particulièrement utile dans la mesure ou les standards utilisent une représentation hexadécimale.

En voici quelques exemples :

Pour donner aux auteurs un moyen encore plus intuitif d'utiliser des caractères du code de caractères du document, l'HTML offre un ensemble d'entités nommées de caractères. Les références nommées de caractères remplacent la référence entière par des noms symboliques. L'entité &aring; se réfère au même caractère Unicode que la référence &#229;. Il n'existe pas de nom d'entité caractère pour la lettre cyrillique capitale "I". La liste complète des entités nommées de caractères est incluse dans cette spécification.

Quatres entités nommées de caractère ont un sens spécial dans la mesure où elles sont utilisées comme caractères "d'échappement" du contenu : pour que ces caractères apparaissent dans le contenu texte du document il faudra les "échapper" à leur tour ; ainsi < devra être noté &lt; pour éviter une possible confusion avec le début d'un Tag. Le caractère & devra être noté &amp; pour éviter une confusion avec le début d'une entité caractère.

Vous pourrez aussi "échapper" l' & à l'intérieur des valeurs d'un attribut dans la mesure ou des références d'entités caractères sont permises dans des valeurs d'attributs de cdata. De plus, vous pourrez représenter le caractère > par &gt; pour éviter des problèmes avec d'anciens agents qui interprètent par erreur ce caractère avec la fin d'un Tag lorsqu'il se présente dans une valeur textuelle d'attribut entre guillemets.

Plutôt que se soucier des règles pour les guillements de valeurs d'attributs, il sera souvent plus facile d'encoder toute instance d'un " par &quot; et de n'utiliser les " que pour encadrer les valeurs d'attributs. De nombreux auteurs trouveront plus simple "d'échapper" ces quatre caractères dans le contenu d'un élément ou d'un attribut.

Les noms des entités caractère nommées sont sensibles à la casse. Ainsi, &Aring; se réfère à un caractère différent (A-ring majuscule) que &aring; (a-ring minuscule).

Note: Selon le SGML, il est possible d'éliminer le ";" final dans certains cas après une référence numérique ou nommée (ex., en fin de ligne ou directement avant un Tag). Dans d'autres circonstances, il ne devrait pas être omis (ex., au milieu d'un mot). Nous recommandons fortement l'usage du ";" dans tous les cas pour éviter tout problème avec certains agents qui l'imposent.