La version française de cette traduction est :
http://www.la-grange.net/w3c/html4.01/
Traducteur : Alix Marchandise-Franquet - <alix@panhard.com> dans le cadre de l'effort de la liste de discussion w3c-translators.fr@w3.org
La version française peut contenir des erreurs. La version anglaise de cette note est l'unique version
normative. Version originale : http://www.w3.org/TR/1999/REC-html401-19991224
Sommaire
Dans ce chapitre, nous traitons de la manière dont les documents HTML sont représentés sur un ordinateur et sur Internet.
La section sur le jeu de caractères du document aborde la question selon laquelle quels caractères abstraits peuvent faire partie d'un document HTML. Par caractère, on entend la lettre « A » latine, la lettre « I » cyrillique, le caractère chinois signifiant « eau », etc.
La section sur les encodages de caractères entreprend d'expliquer comment ces caractères peuvent être représentés dans un fichier ou lors d'un transfert par Internet. Étant donné que certains encodages ne peuvent pas représenter directement tous les caractères que l'auteur peut souhaiter inclure dans un document, HTML offre d'autres mécanismes, nommés références de caractères, pour appeler n'importe quel caractère.
Comme il existe un grand nombre de caractères dans l'ensemble des langues humaines et une grande diversité de représentation pour ceux-ci, on doit prendre les dispositions adéquates de sorte que les documents puissent être interprétés par les agents utilisateurs du monde entier.
Afin de promouvoir l'intéropérabilité, SGML exige de chaque application (y compris HTML) qu'elle spécifie son jeu de caractères du document. Un jeu de caractères du document consiste en :
Chaque document SGML (dont chaque document HTML) est une séquence de caractères issus du répertoire. Les systèmes informatiques identifient chaque caractère par sa position de code ; par exemple, dans le jeu de caractères ASCII, les positions de code 65, 66 et 67 se rapportent respectivement aux caractères « A », « B » et « C ».
Le jeu de caractères ASCII n'est pas suffisant pour un système d'information global tel que le Web, c'est pourquoi HTML utilise le jeu de caractères bien plus important, appelé jeu de caractères universel UCS, défini par la norme [ISO10646]. Cette norme définit un répertoire composé des milliers de caractères utilisés par les communautés du monde entier.
Ce jeu de caractères, défini dans [ISO10646], équivaut caractère par caractère à la norme Unicode ([UNICODE]). De nouveaux caractères sont de temps en temps rajoutés à ces deux normes et on devrait en consulter les amendements sur leurs sites Web respectifs. Dans la présente spécification, on emploie le terme « [ISO10646] » quand on se réfère au jeu de caractères du document, tandis qu'on réserve le terme « [UNICODE] » pour désigner l'algorithme de texte bi-directionnel Unicode.
Cependant, le jeu de caractères du document n'est pas suffisant pour que les agents utilisateurs puissent interpréter les documents HTML correctement de la façon dont ceux-ci sont habituellement échangés -- codés sous la forme d'une séquence d'octets dans un fichier ou lors d'une transmission sur le réseau. Les agents utilisateurs doivent également connaître l'encodage de caractères particulier qui a été utilisé pour transformer le flux de caractères du document en flux d'octets.
Ce que cette spécification appelle un encodage de caractères est connu sous différentes appellations dans d'autres spécifications (ce qui peut amener une certaine confusion). Cependant, le concept reste largement le même sur Internet. Également, les en-têtes des protocoles, les attributs et les paramètres, qui appellent des encodages de caractères, portent le même nom « charset » et utilisent les mêmes valeurs issues du registre [IANA] (voir [CHARSETS] pour une liste complète).
Le paramètre « charset » identifie un encodage de caractères, qui représente une méthode pour convertir une séquence d'octets en une séquence de caractères. Cette conversion s'intègre naturellement au système de l'activité du Web : les serveurs envoient des documents HTML aux agents utilisateurs sous la forme d'un flux d'octets, les agents utilisateurs les interprètent comme séquence de caractères. Les méthodes de conversion se rangent dans un éventail allant de la simple correspondance un-à-un jusqu'à des systèmes de commutation ou des algorithmes complexes.
Une simple technique de codage un-octet-par-caractère n'est pas suffisante pour des chaînes textuelles sur un répertoire de caractères aussi grand que [ISO10646]. Il existe plusieurs encodages différents, concernant des parties de [ISO10646], en plus des encodages du jeu de caractères entier (tel que UCS-4).
Les outils d'édition (par exemple, un éditeur de texte) peuvent coder des documents HTML avec l'encodage de caractères de leur choix, ce choix dépendant essentiellement des conventions utilisées par le logiciel système. Ces outils peuvent utiliser tout encodage commode lequel couvre la plupart des caractères contenus dans le document, pourvu que l'encodage soit correctement étiqueté. Les caractères occasionnels, qui ne sont pas contenus dans cet encodage, peuvent tout de même être représentés par des références de caractères. Celles-ci se rapportent toujours au jeu de caractères du document, et non à l'encodage de caractères.
Les serveurs et serveurs mandataires [ndt. proxies] peuvent changer un encodage (ce qu'on appelle un transcodage) à la volée afin de satisfaire les requêtes des agents utilisateurs (voir la section 14.2 du document [RFC2616], l'en-tête de requête HTTP « Accept-Charset »). Les serveurs et serveurs mandataires ne sont pas tenus de renvoyer un document dans un encodage de caractères qui couvre le jeu de caractères du document en entier.
Les encodages de caractères couramment utilisés sur le Web comprennent ISO-8859-1 (appelé aussi « Latin-1 », utilisable pour la plupart des langues d'Europe de l'Ouest), ISO-8859-5 (qui gère le cyrillique), SHIFT_JIS (un encodage du japonais), EUC-JP (un autre encodage du japonais) et UTF-8 (un encodage de ISO 10646 qui utilise un nombre différent d'octets pour différents caractères). Les noms des jeux de caractères sont insensibles à la casse, de sorte que, par exemple, "SHIFT_JIS", "Shift_JIS", et "shift_jis" sont équivalents.
Cette spécification n'indique pas quels encodages de caractères l'agent utilisateur doit reconnaître.
Les agents utilisateurs conformes doivent correctement établir la correspondance avec ISO 10646 de tous les caractères, dans tous les encodages de caractères qu'ils reconnaissent (ou ils doivent se comporter comme s'ils l'avaient fait).
Quand un texte HTML est transmis dans l'encodage UTF-16 (charset=UTF-16), les données textuelles doivent être transmises dans l'ordre des octets du réseau (« grand boutien » [ndt. big-endian], l'octet de poids fort en premier), selon les spécifications [ISO10646], Section 6.3 et [UNICODE], clause C3, page 3-1.
En outre, afin de maximiser les chances d'une interprétation correcte, il est recommandé que les documents transmis en UTF-16 commencent toujours par un caractère « ESPACE INSÉCABLE SANS CHASSE » (code FEFF en hexadécimal, également appelé marque d'ordre des octets (BOM)), qui, lorsque les octets sont inversés, devient FFFE en hexadécimal, un caractère assuré de n'être jamais assigné. Ainsi, l'agent utilisateur, qui reçoit un code FFFE hexadécimal comme premiers octets d'un texte, saurait que les octets doivent être inversés pour le restant du texte.
Le format de transformation UTF-1 de [ISO10646] (enregistré par l'IANA sous la désignation ISO-10646-UTF-1) ne devrait pas être employé. Pour plus d'informations sur ISO 8859-8 et l'algorithme bi-directionnel, veuillez consulter la section sur la bi-directionnalité et l'encodage de caractères.
Comment un serveur détermine-t-il l'encodage de caractères qu'il va appliquer au document servi ? Certains serveurs examinent les premiers octets d'un document ou vérifient dans une base de données de fichiers et encodages connus. Nombre de serveurs modernes donnents beaucoup plus de contrôle aux webmestre, pour la configuration du jeu de caractères, que les serveurs anciens. Les webmestres devraient utiliser ces mécanismes pour l'émission du paramètre « charset » dès que possible, mais ils devraient également faire attention de ne pas identifier un document avec une mauvaise valeur pour ce paramètre.
Comment un agent utilisateur connaît-il l'encodage de caractères qui a été utilisé ? Le serveur devrait fournir cette information. Le moyen le plus simple, dont dispose le serveur pour informer l'agent utilisateur de l'encodage de caractères du document, c'est d'utiliser le paramètre « charset » dans le champs de l'en-tête « Content-Type » du protocole HTTP ([RFC2616], sections 3.4 et 14.17). Par exemple, l'en-tête HTTP suivant annonce qu'il s'agit de l'encodage "EUC-JP" :
Content-Type: text/html; charset=EUC-JP
Veuillez consulter la section sur la conformité pour la définition du type de contenu "text/html".
Le protocole HTTP ([RFC2616], section 3.7.1) mentionne ISO-8859-1 comme encodage par défaut lorsque le paramètre « charset » est absent du champs « Content-Type » de l'en-tête. En pratique, cette recommandation s'est révélée inutile parce que certains serveurs ne permettent pas d'envoyer un paramètre « charset » et d'autres peuvent ne pas être configurés pour l'envoyer. C'est pourquoi, les agents utilisateurs ne doivent pas supposer une valeur par défaut pour le paramètre « charset ».
Afin de pallier aux limitations du serveur ou de sa configuration, les documents HTML peuvent emporter des informations explicites sur l'encodage de caractères du document ; l'élément META peut être utilisé pour apporter cette information à l'agent utilisateur.
Par exemple, pour spécifier que l'encodage de caractères du document en question est "EUC-JP", le document devrait inclure la déclaration META suivante :
<META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
La déclaration META doit seulement être utilisée lorsque l'encodage est organisé de telle sorte que les octets en valeurs ASCII représentent des caractères ASCII (au moins jusqu'à ce que l'élément META soit analysé). Les déclarations META devraient apparaître le plus tôt possible dans l'élément HEAD.
Dans les cas où ni le protocole HTTP, ni l'élément META ne donnent les informations sur l'encodage de caractères du document, HTML fournit également un attribut charset pour plusieurs éléments. En combinant ces mécanismes, un auteur peut augmenter considérablement les probabilités selon lesquelles l'agent utilisateur va reconnaître l'encodage de caractères de la ressource que l'utilisateur aura ramené.
En résumé, les agents utilisateurs conformes doivent observer les priorités suivantes pour la détermination de l'encodage de caractères d'un document (de la plus importante à la moins importante) :
En plus de cette liste de priorités, l'agent utilisateur peut faire appel à des moyens heuristiques et aux préférences de l'utilisateur. Par exemple, nombre d'agents utilisateurs emploient des méthodes heuristiques pour effectuer une distinction entre les divers encodages utilisés pour les textes en japonais. Également, les agents utilisateurs disposent d'un encodage de caractères par défaut local, défini par l'utilisateur, qui s'applique en l'absence d'autres indicateurs.
Les agents utilisateurs peuvent fournir un mécanisme qui permette aux utilisateurs d'annuler les informations « charset » fausses. Cependant, si l'agent utilisateur propose un tel mécanisme, il ne devrait le faire que pour la navigation et non pour l'édition, afin d'éviter la création de pages Web qui contiendraient un paramètre « charset » incorrect.
Remarque : Si, pour une application particulière, il devient nécessaire de se référer à des caractères en dehors de [ISO10646], ces caractères devraient être assignés à une espace privé, afin d'éviter des conflits avec les versions actuelles ou futures de la norme. On le déconseille fortement pour des raisons de portabilité.
Un encodage de caractères donné peut ne pas pouvoir exprimer tous les caractères du jeu de caractères du document. Avec de tels encodages, ou lorsque les configurations matérielles ou logicielles ne permettent pas aux utilisateurs d'entrer directement certains caractères, les auteurs peuvent avoir recours aux références de caractères SGML. Les références de caractères sont un mécanisme, indépendant de l'encodage, utilisé pour ajouter n'importe quel caractère issu du jeu de caractères du document.
Les références de caractères en HTML peuvent se présenter sous deux formes :
Les références de caractères dans les commentaires n'ont pas de signification particulière ; ce sont simplement des données de commentaires.
Remarque : HTML offre d'autres moyens pour présenter des données textuelles, en particulier les images en-ligne.
Remarque : Dans SGML, dans certains cas, il est possible d'éliminer le caractère « ; » final après une référence de caractère (par exemple, à un saut de ligne ou immédiatement avant une balise). Dans d'autres cas, il n'est pas possible de l'éliminer (par exemple, au milieu d'un mot). Nous encourageons fortement l'utilisation du caractère « ; » dans tous les cas, afin d'éviter les problèmes avec les agents utilisateurs qui en requièrent la présence.
Les références de caractères numériques spécifient la position du code d'un caractère dans le jeu de caractères du document. Les références de caractères numériques peuvent prendre deux formes :
Voici quelques exemples de références de caractères numériques :
Remarque : Bien que la représentation en système hexadécimal ne soit pas définie dans la norme [ISO8879], elle devrait apparaître dans une révision, comme décrit dans [WEBSGML]. Cette convention est particulièrement utile étant donné que les normes de caractères utilisent généralement des représentations hexadécimales.
Afin de fournir aux auteurs un moyen plus intuitif pour appeler les caractères du jeu de caractères du document, HTML propose un ensemble de références d'entités de caractères. Les références d'entités de caractères utilisent des noms symboliques de sorte que les auteurs n'aient pas à se remémorer les positions des codes. Par exemple, la référence d'entité de caractère « å » se rapporte à la lettre « a minuscule surmontée d'un anneau å » ; il est plus facile de se remémorer « å » que « å ».
HTML 4 ne définit pas une référence d'entité de caractère pour chacun des caractères du jeu de caractères du document. Par exemple, il n'existe pas de référence d'entité de caractère pour la lettre « I cyrillique majuscule ». Veuillez consulter la liste complète des références de caractères qui sont définis en HTML 4.
Les références d'entités de caractères sont sensibles à la casse. Ainsi, « Å » (A majuscule, anneau) ne se rapporte pas au même caractère que « å » (a minuscule, anneau).
Quatre références d'entités de caractères méritent une attention particulière car elles sont fréquemment utilisées pour masquer certains caractères spéciaux.
Les auteurs qui souhaitent employer le caractère « < » dans leur texte devraient utiliser « < » (code décimal ASCII 60), afin d'éviter toute confusion avec le début d'une balise (caractère de début de balise). De même, les auteurs devraient utiliser « > » (code décimal ASCII 62) dans leur texte au lieu de « > », pour éviter des problèmes avec les agents utilisateurs anciens qui le perçoivent, de manière erronée, comme la fin d'une balise (caractère de fin de balise) lorsqu'il apparaît dans les valeurs d'attributs entre guillemets.
Les auteurs devraient utiliser « & » (code décimal ASCII 38) au lieu de « & », pour éviter toute confusion avec le début d'une référence de caractère (délimiteur ouvrant de référence d'entité), Les auteurs devraient également utiliser « & » dans les valeurs d'attributs, étant donné que les références de caractères sont admises dans les valeurs d'attribut de type « CDATA ».
Certains auteurs utilisent la référence d'entité de caractère « " » pour coder les instances de guillemets doubles « " », car on peut utiliser ce caractère pour délimiter les valeurs des attributs.
Un agent utilisateur n'est pas toujours en mesure de restituer de manière significative tous les caractères d'un document, par exemple, si l'agent utilisateur ne dispose pas d'une police appropriée, la valeur d'un caractère peut ne pas s'exprimer au travers de l'encodage de caractères interne de l'agent utilisateur, etc.
Étant donné l'éventail des réponses possibles dans de pareils cas, ce document ne suggère aucun comportement spécifique. Selon l'implémentation, les caractères non affichables peuvent également être gérés par le système d'affichage sous-jacent et non pas l'application elle-même. En l'absence d'un comportement plus précis, qui soit, par exemple, adapté aux besoins d'une écriture ou d'une langue particulière, nous recommendons que les agents utilisateurs empruntent les comportements suivants :