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 :