Cet aperçu explique un modèle de traitement de référence pour HTML, et en particulier le concept SGML de jeu de caractère de document. Une quelconque mise en oeuvre peut être très différente du modèle, mais devrait se comporter de la même façon pour un observateur externe.
Étant donné l'existence d'une grande variété de codages de texte, SGML ne s'intéresse
pas directement à la façon dont les séquences de caractères constituant un document
SGML au sens abstrait sont codés en séquences d'octets (ou parfois de groupes de bits
de longueur différente de 8), lors d'une réalisation concrète du document comme un
fichier. Ce codage est appelé le codage externe de caractères du document SGML concret,
et doit être soigneusement distingué du du jeu de caractères de document du document
SGML abstrait. SGML considère un unique ensemble de caractères (appelé un répertoire
de caractères
), et un jeu de codes
qui associe à chaque caractère du répertoire
un nombre entier (appelé le numéro du caractère
). La déclaration du jeu de
caractères de document définit ce que chaque numéro de caractères représente
[GOLD90, p. 451]. Dans la plupart des cas,
une DTD SGML et tous les documents qui s'y réfèrent ont un seul jeu de caractères de
document, et tout le balisage et les caractères de texte en font partie.
HTML, en tant qu'application SGML, ne s'inquiète pas du codage externe de caractères. Ce problème est délégué à des mécanismes externes, tels que MIME dans le cas du protocole HTTP ou du courrier électronique.
Le protocole HTTP [RFC2068] utilise le
paramètre charset
du champ Content-Type
de l'en-tête de la réponse pour
indiquer le codage externe de caractères. Par exemple, pour indiquer qu'un document
japonais est codé en JUNET
[RFC1468],
l'en-tête contiendra la ligne suivante :
Content-Type: text/html; charset=ISO-2022-JPL'expression MIME
charsetest utilisée pour désigner un codage de caractères, et non pas seulement un jeu de caractères codés tel que l'expression semble l'indiquer. Un codage de caractères est une relation (possiblement de plusieurs à un) entre une suite d'octets et une suite de caractères tirés d'un ou de plusieurs répertoires.
Le protocole HTTP définit aussi un mécanisme pour que le client puisse indiquer les codages qu'il accepte. Les serveurs et clients sont fortement encouragés à utiliser ces mécanismes pour assurer la transmission et l'interprétation correctes de tout document. Des mesures compensatoires, à utiliser quand les mécanismes corrects sont ignorés, sont décrits à la section 6.
De même, lorsqu'un document HTML est transmis par courrier électronique, le codage
externe de caractères est précisé par le paramètre charset
de la ligne
d'en-tête MIME Content-Type
[RFC2045],
avec US-ASCII comme valeur implicite.
Il n'existe présentement aucun mécanisme normalisé pour indiquer le codage externe de caractères de documents HTML transmis par FTP ou obtenus de systèmes de fichiers distribués.
Au cas où tout autre moyen de transmettre ou de stocker des documents HTML soit défini ou devienne populaire, il est conseillé d'avoir de semblables moyens d'identification du codage, ou encore d'utiliser ou d'avoir par défaut un codage capable de représenter un grand nombre de caractères en contexte international.
Quelque soit le codage de caractères externe, le modèle de traitement de référence le traduit au jeu de caractères de document spécifié à la section 2.2 avant tout traitement propre à SGML/HTML. Le modèle de traitement de référence peut être illustré comme suit :
[ressource]->[décodeur]->[ gestion ]->[analyse]->[application]->[affichage]
[d'entités] [ SGML ]
^ |
| |
+----------+
Le décodeur est responsable du décodage de la représentation externe vers le jeu de
caractères de document. Le gestionnaire d'entités, l'analyseur et l'application ne
voient que des caractères du jeu de caractères de document. Le mécanisme d'affichage,
ou encore la partie affichagede l'application, peut encore recoder les caractères en une représentation plus appropriée à sa fonction. Dans tous les cas, et en tout ce qui concerne la sémantique des caractères, le gestionnaire d'entités, l'analyseur et l'application utilisent exclusivement le jeu de caractères de document.
Une quelconque mise en oeuvre peut choisir, ou non, de traduire le document en une représentation du jeu de caractères de document tel que décrit ci-dessus ; le comportement de ce modèle de traitement de référence peut être obtenu autrement. Ce sujet est toutefois hors du domaine de cette spécification, et le lecteur est invité à consulter la norme SGML [ISO-8879] ou un manuel SGML [BRYAN88] [GOLD90] [VANH90] [SQ91] pour plus ample informé.
La conséquence la plus importante de ce modèle de référence est que les références
numériques de caractères sont toujours relatives au jeu de caractères de document,
sans égard au codage externe du document. Voir la section 2.2 pour un exemple.
2.2. Le jeu de caractères de document
Le jeu de caractères de document, au sens SGML, est le jeu universel de caractères (JUC) de l'ISO 10646:1993 [ISO-10646], tel qu'amendé. À l'heure actuelle, ce jeu est identique à celui du standard Unicode, version 1.1 [UNICODE].
NOTE — les implémenteurs devraient savoir que l'ISO 10646 est amendée de temps en temps ; 4 amendements ont été adoptés depuis la parution initiale de 1993, sans que cette spécification n'en soit affectée significativement. Un cinquième amendement, présentement à l'étude, amènera des changements incompatible à la norme : 6556 syllabes coréennes Hangul ayant des valeurs de code entre 3400 et 4DFF (hexadécimal) seront déplacées à de nouvelles valeurs (avec ajout de 4516 nouvelles syllabes), rendant ainsi les références aux anciennes valeurs invalides. Puisque le consortium Unicode a déjà adopté un amendement à cet effet pour Unicode 2.0 (à paraître bientôt), l'adoption du DAM 5 est probable et les implémenteurs devraient probablement déjà considérer les anciennes valeurs comme obsolètes. Malgré ce changement unique, les organismes de normalisation pertinents semblent demeurer opposés à tout changement de valeurs de code dans l'avenir. Pour coder le coréen sans égard à ce changement, on peut utiliser les Jamo Hangul combinatoires situés de 1110 à 11F9.L'adoption de ce jeu de caractères de document impose un changement à la déclaration SGML de HTML 2.0 (section 9.5 de [RFC1866]). Il s'agit de remplacer la première déclaration BASESET et le DESCSET correspondant par ce qui suit :
BASESET "ISO Registration Number 177//CHARSET
ISO/IEC 10646-1:1993 UCS-4 with implementation level 3
//ESC 2/5 2/15 4/6"
DESCSET 0 9 UNUSED
9 2 9
11 2 UNUSED
13 1 13
14 18 UNUSED
32 95 32
127 1 UNUSED
128 32 UNUSED
160 2147483486 160
L'adoption du JUC comme jeu de caractère de document conserve la conformité de toute
expression, toute construction ou tout document conforme à HTML 2.0. Elle rend
toutefois conforme certaines contructions non-conforme à HTML 2.0. En particulier,
les caractères hors du répertoire de l'ISO 8859-1 mais dans le répertoire de l'UCS-4
deviennent valides, et la borne supérieure des références numériques de caractères
est portée de 255 à 2147483645 ; ainsi, И est une référence valide à
la LETTRE MAJUSCULE CYRILLIQUE I(И). [ERCS] est une bonne source de renseignements sur Unicode et SGML, bien que son domaine et son contenu technique soient très différents de ceux de ce document.
NOTE — la déclaration SGML ci-dessus, comme celle d'HTML 2.0, donne les caractères de 128 à 159 (80 to 9F hex) comme inutilisés (UNUSED). Ceci signifie que les références numériques de caractères correspondantes (par ex. ’) sont illégales en HTML. Ni ISO 8859-1 ni ISO 10646 ne contiennent de caractères dans ce domaine, qui est réservé à des caractères de contrôle.Une autre différence avec la déclaration SGML de HTML 2.0 est due à l'opinion que cette dernière n'exprime pas vraiment l'intention de ses auteurs. La déclaration du jeu de caractères de syntaxe passe de ISO 646.IRV:1983 au plus récent ISO 646.IRV:1991, ce dernier étant identique à US-ASCII, contrairement au premier. En principe, ceci introduit une incompatibilité avec HTML 2.0, mais en pratique l'interopérabilité devrait être améliorée par i) une déclaration SGML conforme à ce que tout le monde pense, et ii) un jeu de caractères de syntaxe sous-ensemble propre du jeu de caractères de document. Les caractères qui diffèrent entre les deux versions de l'ISO 646.IRV ne sont pas utilisés pour exprimer la syntaxe d'HTML.
L'ISO 10646-1:1993 est le plus grand jeu de caractères qui soit, et aucun autre
jeu de caractères ne pourrait le remplacer comme jeu de caractères de document
pour HTML. Toutefois, si pour une certaine application il s'avérait nécessaire
d'utiliser d'autres caractères, ce devrait être fait de manière compatible avec
les versions présente et futures d'ISO 10646, i.e. en plaçant ces caractères en
zone privée de l'espace de codage UCS-4
[ISO-10646, section 11].
On doit aussi se rendre compte qu'un tel usage serait très peu portable ;
il vaudra généralement mieux utiliser de petites images en ligne.
2.3. Caractères non-affichables
Avec l'ISO 10646 au complet comme jeu de caractères de document, on ne peut éviter le problème de caractères qui ne peuvent être affichés faute de ressources appropriées (fontes). Comme il y a nombre de solutions possibles, y compris de laisser le mécanisme d'affichage sous-jacent se débrouiller, ce document ne prescrit pas de comportement particulier. Les conseils suivants pourront toutefois être utiles :