Sommaire
Dans ce chapitre, nous nous intéressons à la façon dont les documents HTML sont représentés sur un ordinateur et sur internet.
La section sur l'ensemble de caractères du document détermine quels sont les caractères uniques qui peuvent faire partis d'un document HTM. Les caractères comprennent la lettre latine "A", la lettre cyrillique "I", le caractère chinois "eau", etc.
La section sur le codage des caractères détermine la façon dont ces caractères doivent être interprêtés dans un fichier ou quand ils sont transferrés par internet. Comme certains codages de caractères ne peuvent directement représentés certains caractères que l'auteur voudra inclure dans un document, HTML offre d'autres mécanismes, appelés référence de caractères , pour référencer tous caractères.
Comme il existe un grand nombre de caractères à travers les langages humains, et une grande variétéde représentation de ces caractères, une attention particulière doit être faite pour que les agents utilisateurs dans le monde comprennent les docments.
Pour promouvoir l'interopérabilité, SGML requiert que chaque application (y compris HTML) spécifie son ensemble de caractères du document. Un ensemble consiste en :
Chaque document SGML (y compris les documents HTML) est une séquence de caractères d'un répertoire. Les systèmes informatiques identifie chaque caractère par son code de position ; par exemple, dans l'ensemble des caractères ASCII, les codes de position 65, 66 et 67 représentent respectivement les caractères 'A', 'B', et 'C'.
L'ensemble des caractères ASCII n'est pas suffisant pour un système d'information globale comme le Web, HTML utilise donc un ensemble beaucoup plus complet appelé l'ensemble des cractères universels ou Universal Character Set (UCS), défini par [ISO10646]. Ce standard définit un répertoire de milliers de caractères utilisés par les communautés à travers le monde.
L'ensemble des caractères définis par [ISO10646] est équivalent caractère par caractère à Unicode 2.0 ([UNICODE]). Ces deux standards sont mis à jour régulièrement avec de nouveaux caractères, et les ajouts devraient être consultés sur les sites Web respectifs. Dans la spécification suivante, les références à ISO/IEC-10646 ou Unicode implique le même document d'ensemble de caractères. La spécification HTML se réfère également à la spécification Unicode pour d'autres sections comme l'algorithme de texte bidirectionnel.
L'ensemble de caractère du document ne suffit pas aux agents utilisateurs pour interprêter correctement les documents HTML lorsqu'ils sont échangés -- soit encodés comme une séquence d'octets dans un fichier ou lors d'une transmission réseau. Les agents utilisateurs doit également connaître le codage spécifique des caractères qui est utilisé pour transformer le flot de données caractères en flot de données octales.
Ce qui est appelé codage de caractères dans cette spécification est connu par d'autres noms dans d'autres spécifications (ce qui peut entraîner quelques confusions). Le concept est tout de même largement répandu à travers l'internet. Les protocoles d'entêtes, les attributs et les paramètres se réferrant aux codages des caractères partage le même nom -- "charset" -- et utilisent les mêmes valeurs du registre de l'[IANA] (voir [CHARSETS] pour une liste complète).
Le paramètre "charset" identifie un codage de caractère, ce qui est une méthode pour convertir une séquence d'octets en séquence de caractères. Cette conversion convient naturellement au schéma de l'activité Web : Des serveurs envoient des documents HTML aux agents utilisateurs comme un flot de données octales ; les agents utilisateurs les interprêtent comme une séquence de caractères. La méthode de conversion peut recouvrir les méthodes de simple correspondance un à un jusqu'à des algorithmes ou des schémas complexes d'échanges.
Une technique de codage simple faisant correspondre un octet à un caractère n'est pas suffisante pour les chaînes de texte sur un répertoire de caractère aussi important que [ISO10646]. Il exite différents codage des parties de [ISO10646] afin de coder l'ensemble complet des caractères (tel que UCS-4).
Les outils d'édition (c.à.d., les éditeurs de texte) peuvent coder les documents HTML dans le codage de caractères de leur choix, et le choix dépend largement des coventions utilisées par le logiciel système. Ces outils peuvent utiliser tout codage utile qui couvre la plupart des caractères contenus dans le document, étant entendu que le codage est correctement étiqueté. Des caractères occasionnels qui tombent en dehors de ce codage peuvent toujours être représentés par des références de caractères. Ceci se réferre toujours à l'ensemble des caractères du document et non au codage des caractères.
Les serveurs et les proxies peuvent changer le codage d'un caractère ( soit le transcoding) au vol pour respecter les besoins des agents utilisateurs (voir la section 14.2 de la [RFC2068], le "Accept-Charset" HTTP request header). Les serveurs et les proxies n'ont pas l'obligation de fournir un document qui couvre l'ensemble de caractères de documents au complet.
Les codages de caractères généralement utilisés sur le Web comprennent ISO-8859-1 (également connu comme "Latin-1" ; utilisable pour la plupart des langues de l'Europe de l'ouest), ISO-8859-5 (pour le cyrillique), SHIFT_JIS (un codage japonais), EUC-JP (un autre codage japonais), et UTF-8 (un codage de ISO 10646 utilisant un nombre d'octets différents pour des caractères différents). Les noms pour les codages de caractères sont insensibles à la casse, par exemple "SHIFT_JIS", "Shift_JIS", et "shift_jis" sont équivalents.
Cette spécification n'impose pas le codage de caractères que doivent utiliser les agents utilisateurs.
Les agents utilisateurs conformes doivent correctement interprêter tous les caractères Unicode dans tous les codages de caractères qu'ils reconnaissent (ou they must behave as if they did).
Quand le texte HTML est transmis en UTF-16 (charset=UTF-16), les données texte devraient être transmises en ordre octale réseau ("big-endian", l'octet d'ordre élevé en premier) en accord avec [ISO10646], Section 6.3 et [UNICODE], clause C3, page 3-1.
Afin de maximiser les chances d'une bonne interprétation, il est recommandé que les documents soit transmis comme UTF-16 en commenŸant toujours avec un caract∂re ESPACE DE LARGEUR NULLE NON-SECABLE (ZERO-WIDTH NON-BREAKING SPACE) (hexa-décimal FEFF, également appelé Byte Order Mark (BOM)) ce qui, lorsqu'il est renversé (byte-reversed), devient l'hexa-décimal FFFE, un caract∂re qui ne sera jamais attribué. Donc, un client recevant un hexa-décimal FFFE pour les premiers octets d'un texte devrait savoir que les octets doivent être renversés pour le reste du texte.
Le format de transformation UTF-1 [ISO10646] (enregistré par l'IANA en tant que ISO-10646-UTF-1), ne devrait pas être utilisé. Pour avoir des informations √ propos de ISO 8859-8 et des algorithmes bidirectionnel, consultez la section sur l'encodage et la bidirectionnalité des caract∂res.
Comment un serveur peut-il déterminer l'encodage avec lequel il doit fournir le document ? Certains serveurs examinent les premiers octets du document, ou vérifie par rapport √ une base de données de fichiers et d'encodages connus. Un grand nombre de serveurs actuels donnent la possibilité aux wemasters plus de contrôle sur la configuration de la table de caract∂re que les anciens. Les webmasters devraient utiliser ces fonctionnalités pour envoyer le param∂tre de la table de caract∂re lorsque c'est possible mais doit faire attention de ne pas identifier le document avec un param∂tre de table erroné.
Comment le client sait quel encodage a été utilisé ? Le serveur doit fournir cette information. La faŸon la plus directe pour un serveur d'informer le client √ propos de l'encodage des caract∂res d'un document est d'utiliser le param∂tre de table de caract∂res ("charset") du champ de l'entête "Content-Type" du protocole HTTP ([RFC2068], sections 3.4 et 14.18) Par exemple, l'entête HTTP suivant annonce que l'encodage de caract∂re est EUC-JP:
Content-Type: text/html; charset=EUC-JP
Consultez la section sur la conformité pour la définition de text/html.
Le protocole HTTP ([RFC2068], section 3.7.1) définit ISO-8859-1 comme encode par défaut lorsque le param∂tre "charset" est absent du champs d'entête "Content-Type". En pratique, cette recommandation est inutile car la plupart des serveurs ne permettent l'envoi du paramêtre "charset", et les autres ne peuvent pas être configurés pour envoyer le param∂tre. Donc les clients ne doivent pas avoir de valeur par défaut du param∂tre "charset".
Afin de contourner les limitations des serveurs ou de leurs configurations, les documents HTML peuvent contenir explicitement l'information √ propos de l'encodage des caract∂res ; l'élément META peut être utilisé pour fournir aux clients cette information.
Par exemple, pour spécifier que l'encodage du document actuel est "EUC-JP", un document devrait inclure la déclaration METAsuivante :
<META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
La déclaration META doit être uniquement utilisée si l'encodage des caract∂res est organisé sous la forme de caract∂res ASCII définis par eux-même (√ moins que l'élément META soit analysé). Les déclarations META doivent appara‰tre aussi tôt que possible dans l'élément HEAD.
Dans les cas où le protocole HTTP ou l'élément META fournissent l'information √ propos de l'encodage du document, HTML fournit également l'attribut charset de plusieurs éléments. En combinant ces mécanismes, u nauteur peut améliorer de faŸon importante les chances, lorsque l'utilisateur demande une ressource, que le client reconnaisse l'encodage des caract∂res.
Pour résumer, les clients conformes doit respecter les priorités suivantes quand il détermine l'encodage des caract∂res (de la plus grande priorité vers la plus faible) :
En plus de cette liste de priorités, le client doit utiliser des paramétres heuristique et utilisateur. Par exemple, beaucoup de clients utilisent un heuristique pour distinguer les encodages variés utilisés pour les textes japonais. Egalement, les clients ont, souvent, un encodage paramétrable localement par l'utilisateur qui s'applique en l'absence de tous autres indicateurs.
Les clients peuvent fournir un mécanisme qui permet aux utilisateurs d'outrepasser une information "charset" incorrecte. De toutes faŸons, si un agent utilisateur offre un tel mécanisme, cela devrait l'être uniquement pour la navigation et non pour l'édition, afin d'éviter la création de pages web avec un param∂tre "charset" incorrecte.
Note. Si, pour une application spécifique, il devient nécessaire de se référer √ des caract∂res autres que les caract∂res [ISO10646], des characters devraient être attribués dans une zone protégé pour éviter les conflits avec les versions standards ou futures. Ceci est fortement déconseillé, de toute mani∂re pour des raisons de portabilité.
Un encodage de caract∂re donné ne peut pas représenté tous les caract∂res d'un ensemble de caract∂re d'un document. Pour certains encodages, ou lorsque certaines configurations matérielles ou logicielles ne permettent pas aux utilisateurs d'entrer les caract∂res du document directement, les auteurs peuvent utiliser les caract∂res références. SGML. Les caract∂res références sont un mécanisme d'encodage des caract∂res indépendants pour entrer tout caract∂re √ partir d'un ensemble de caract∂re d'un document.
Les caract∂res références en HTML peuvent appara‰tre selon 2 formes :
les caract∂res référence √ l'intérieur de commentaires n'ont pas de signification spéciales ; ils ne sont que des données commentaires.
Note. HTML fournit d'autres moyens pour présenter les données caract∂res, en particulier les images inclues.
Note. En SGML, il est possible d'éliminer le ";" final apr∂s un caract∂re référence dans certains cas (e.g., √ un saut de ligne ou immédiatement apr∂s une balise). Dans d'autres circonstances, il ne peut pas être éliminé (e.g., au milieu d'un mot). Nous suggérons fortement d'utiliser ";" dans tous les cas afin d'éviter les probl∂mes avec les clients qui demandent que ce caract∂re soit présent.
Les caract∂res références numériques spécifie le code position d'un caract∂re dans le document de l'ensemble des caract∂res. Les caract∂res références numériques peuvent prendre 2 formes :
Voici quelques exemples de caract∂res références numériques :
Note. Bien que la représentation hexadécimale ne soit pas définie dans [ISO8879], il est attendu que ce soit modifié, comme décrit dans [WEBSGML]. Cette convention est particuli∂rement utile depuis que les caract∂res standards utilisent les représentations hexadécimales.
En r∂gle générale pourdonner aux auteurs une mani∂re plus intuitive de se référer √ des caract∂res dans un document, HTML offre un ensemble de caract∂res références entités. Les caract∂res références entités utilisent des noms symboliques pour que les auteurs n'est pas besoin de se souvenir du code de position. Par exemple, le caract∂re référence entité å se réferre √ la lettre minuscule "a" surmonté d'un cercle ; "å" est plus facile √ se souvenir que å.
HTML 4.0 ne définit pas un caract∂re référence entité pour tous les carcat∂res d'un document. Par exemple, il n'y a pas de caract∂re référence entité pour la lettre capitale cyrillique "I". Consultez la liste compl∂te des caract∂res références définie en HTML 4.0.
Les caract∂res références entités sont sensibles √ la casse. Donc, Å se réferre √ un caract∂re différent (A majuscule, cercle) que å (a minuscule, cercle).
Quatre caract∂res références entités méritent une attention particuli∂re car ils sont fréquemment utilisés pour simuler des caract∂res spéciaux. :
Certains auteurs désirent placer le caract∂re "<" dans le texte devrait utiliser "<" (ASCII décimal 60) afin d'éviter toute confusion avec le début d'une balise (délimiteur d'ouverture de départ de balise). De la même faŸon, les auteurs devraient utiliser ">" (ASCII décimal 62) dans le texte √ place de ">" afin d'éviter les probl∂mes avec les anciens clients qui percoivent celui-ci comme la fin d'une balise (délimiteur de fermeture de balise) lorsqu'il apparait dans des valeurs d'attributs entre guillemets.
Les auteurs devraient utiliser "&" (ASCII décimal 38) √ la place de "&" afin d'éviter la confusion avec le début d'un caract∂re réference (délimiteur d'ouverture de référence entité). Les auteurs devraient utiliser "&" en valeurs attribut depuis que les carcat∂res références sont permis dans les valeurs attribut CDATA.
Quelques auteurs utilisent le caract∂re référence entité """ pour coder les occurences de double guillemets (") car ce caract∂re peut-être utilisé pour délimiter les valeurs attribut.
Un client peut ne pas être capable de rendre tous les caract∂res dans un document significatif, par exemple, parce que le client a un défaut de polices adéquate, un caract∂re a une valeur qui ne peut être exprimé par l'encodage interne du client, etc.
Parce-qu'il y a tant de choses différentes qui peuvent être faites dans ces cas, ce document ne dtéaille pas tous les comportements spécifiques. Dépendant de l'éxécution, les caract∂res non affichables peuvent également être pris en compte par le syst∂me d'affichage et non par l'application elle-même. En l'absence de comportement plus sophistiqué, par exemple adapté par les besoins d'un script particulier ou d'une langue, nous recommandons, le comportement suivant des clients :