Résumé

  • Le RFC 2070 distinguait l’encodage externe d’une ressource et le jeu de caractères abstrait du document HTML, fixé à l’UCS ; le charset indiquait la conversion des octets vers les caractères.
  • Une référence numérique se résolvait dans ce jeu fixe et gardait donc la même identité de caractère, quel que soit l’encodage externe qui transportait le balisage.
  • Le décodage ne garantissait ni l’analyse SGML, ni une police disponible, ni le bon traitement bidirectionnel, ni ce que le lecteur voyait et comprenait.

Le nombre 1048 n’est pas un octet. Dans И, il désigne la lettre cyrillique И dans l’espace de caractères retenu par le document. Le fichier qui contient cette référence peut pourtant être sérialisé en US-ASCII, en UCS-2 ou selon un autre encodage compatible avec le transport. Les suites d’octets divergent ; la référence ne doit pas changer de cible.

Cette stabilité paraît aujourd’hui naturelle. Elle exigeait pourtant une séparation rigoureuse à une époque où « jeu de caractères » servait souvent à nommer à la fois un répertoire, des numéros et une représentation sur le fil.

Le document abstrait précédait son analyse

HTML était alors une application de SGML. Avant de reconnaître un titre, une balise ou des données, SGML devait savoir quels caractères constituaient le document et quels nombres les désignaient. Ce jeu de caractères du document n’était pas le format physique d’un fichier.

Le RFC 1866, qui définissait HTML 2.0, couvrait surtout Latin-1 tout en alignant ses positions sur ISO 10646 et en annonçant une extension future. Le RFC 2070 adopta l’Universal Character Set d’ISO 10646:1993, amendé, comme jeu de caractères du document HTML. À la date de publication, il le décrivait comme identique code par code à Unicode 1.1.

L’effet fut concret : des caractères hors ISO-8859-1 devenaient admissibles comme données SGML, et la plage des références numériques s’élargissait. Tout nombre n’était pas pour autant licite. Les positions 128 à 159 restaient inutilisées dans la déclaration SGML, de sorte qu’une référence comme ’ n’acquérait pas magiquement le sens typographique que certains logiciels lui prêtaient.

Le charset choisissait le décodeur, non l’univers du document

Le RFC 2070 laissait l’encodage externe aux mécanismes de transfert. En HTTP, le paramètre charset du Content-Type de la réponse l’indiquait. Dans le courrier, le paramètre MIME jouait ce rôle, avec ses règles de défaut. Pour FTP et les systèmes de fichiers distribués, le texte constatait alors l’absence de mécanisme normalisé.

Dans le vocabulaire MIME, charset désignait une méthode de conversion de séquences d’octets en séquences de caractères. Le RFC 2045 exigeait que cette conversion soit entièrement définie, sans exiger que tout caractère puisse être reconverti dans l’autre sens. L’étiquette n’était donc pas la liste des caractères d’HTML : elle sélectionnait une route vers eux.

Le modèle de référence rendait cette route visible : ressource, décodeur, gestionnaire d’entités, analyseur SGML, application, affichage. Le décodeur changeait la représentation externe en caractères du document. Les trois étapes suivantes raisonnaient sur ces caractères. L’affichage pouvait ensuite les convertir encore pour une machine ou un écran.

Le RFC précisait qu’une implémentation réelle pouvait être organisée autrement. Le dessin fixait un comportement observable, pas la forme obligatoire du code d’un navigateur.

Une référence numérique ne réparait pas un mauvais décodage

La référence numérique devenait indépendante de l’encodage parce qu’elle était interprétée après la conversion correcte des octets. Si le récepteur ne reconnaissait même pas correctement &, #, les chiffres et ;, l’analyseur ne pouvait découvrir la référence. Le mécanisme stabilisait l’identité d’un caractère ; il ne devinait pas l’encodage perdu.

Le chemin inverse confirmait la distinction. Pour un formulaire, le RFC 2070 avertissait qu’une valeur par défaut inchangée pouvait revenir au serveur avec d’autres octets valides que ceux de la page source. Des suites composées ou précomposées pouvaient aussi varier. L’identité textuelle et l’identité binaire n’étaient pas la même preuve.

Le signal d’encodage avait lui-même une hiérarchie

Le RFC décrivait un Web où les serveurs omettaient souvent le bon paramètre et où certains navigateurs supportaient mal sa présence. C’est une observation de 1997, pas une statistique actuelle.

La source de la réponse était jugée la plus autorisée. Venait ensuite un META HTTP-EQUIV placé tôt dans HEAD, puis l’indication CHARSET du lien suivi. Mais META avait un paradoxe : il fallait déjà décoder assez correctement le début du fichier pour atteindre la déclaration censée expliquer son décodage. Le document la qualifiait donc de solution imparfaite.

L’ordre distinguait autorité et commodité. Une indication disponible dans la page ne dépassait pas le paramètre de la réponse. Même ce dernier restait toutefois une assertion : sa présence ne prouvait ni la conformité des octets ni la correction du programme.

Reconnaître un caractère ne fabriquait pas son glyphe

L’UCS agrandissait le vocabulaire abstrait d’HTML, pas les ressources de l’écran. Le RFC 2070 prévoyait des caractères sans police disponible et ne prescrivait aucun comportement unique. Montrer un symbole de remplacement ou un numéro hexadécimal relevait de l’affichage.

La langue pouvait modifier le choix du glyphe, les guillemets, la césure, l’espacement ou la synthèse vocale. La direction exigeait encore l’algorithme bidirectionnel et les informations DIR ou BDO. Ces étapes utilisaient les caractères décodés ; elles ne redéfinissaient pas les octets reçus.

Il faut donc quatre diagnostics au minimum : le signal d’encodage, la sortie du décodeur, la structure issue de l’analyse, puis la présentation. Une capture d’écran ne permet pas de reconstruire les trois premières. Une empreinte du fichier ne prouve pas la dernière.

Une règle qui a survécu au déplacement du centre normatif

Le RFC 2854 a ensuite rendu obsolètes les RFC IETF consacrés à HTML et renvoyé sa définition aux recommandations du W3C. Il a néanmoins conservé le paramètre charset comme description de l’encodage qui représente le document en octets. HTML 4.01 répéta qu’un jeu de caractères du document ne suffisait pas à interpréter le flux échangé.

La lecture rétrospective proposée par Lu Heng aide à ne pas gonfler la portée du texte. Le jeu fixe formait un invariant commun minimal. Chaque implémentation gardait ses décisions locales de décodeur, d’erreur, de police et de présentation. Une spécification publiée n’exécutait aucune de ces décisions et ne devenait pas leur reçu.

Le RFC 2070 n’a donc pas supprimé les différences. Il les a placées. Les octets pouvaient varier avant le décodeur ; le caractère restait stable pour l’analyse ; le rendu pouvait varier ensuite. La clarté venait du fait qu’aucune étape ne pouvait emprunter la preuve de l’autre.

Sources