Résumé

  • RFC 5137 vise les protocoles qui ont réellement besoin d’exprimer Unicode par une forme ASCII ; l’UTF-8 natif reste préférable lorsqu’il est possible.
  • La recommandation consiste à référencer le point de code, plutôt que les octets UTF-8 ou les unités UTF-16 qui le sérialisent.
  • Chaque protocole doit fixer la grammaire exacte de l’échappement et la manière d’écrire littéralement son caractère introducteur.
  • Des délimiteurs explicites indiquent où s’arrête une valeur hexadécimale de quatre, cinq ou six chiffres.
  • Le préfixe \u ne suffit pas à identifier une convention : C, Java, JSON et d’autres environnements lui donnent des sens différents.
  • Les protocoles Internet ne devraient pas employer de paires de substituts comme modèle d’échappement.
  • RFC 5137 recommande notamment une forme backslash-u délimitée et la référence hexadécimale XML avec son point-virgule final.
  • Un point de code correctement retrouvé ne prouve pas qu’une chaîne est normalisée, autorisée dans le champ ou égale à une autre.
  • Les contrôles de sécurité échouent s’ils sont exécutés du mauvais côté du décodage ou de la normalisation.
  • La ressemblance visuelle, l’identité d’un libellé et le principal autorisé sont trois objets distincts.
  • Les journaux doivent conserver séparément l’entrée brute, les valeurs décodées, la transformation appliquée et la décision finale.
  • La direction doit attribuer un propriétaire à chaque frontière au lieu de laisser la preuve syntaxique gouverner les couches suivantes.

Le caractère qui change de propriétaire à chaque service

Une passerelle reçoit un identifiant sous forme ASCII, un service le décode, un autre le normalise, une base le compare et une interface l’affiche. À chaque étape, le même dossier peut employer le mot « caractère » pour désigner un objet différent. Le problème ne vient pas forcément d’un décodeur défectueux. Il vient de la disparition des frontières entre représentations.

RFC 5137 isole la première de ces frontières. Lorsqu’un protocole ne peut pas transporter directement Unicode, une forme ASCII peut indiquer un point de code. Le choix du point de code évite de demander au lecteur de reconstruire d’abord une suite d’octets UTF-8 ou deux unités UTF-16. La notation devient plus courte, plus proche des tables Unicode et plus utile au diagnostic.

Cette précision est volontairement limitée. Le document suppose que la chaîne à échapper est déjà valide et raisonnable. Il ne décide pas quelles chaînes constituent des noms de compte, quels caractères sont autorisés dans un domaine, quelle normalisation doit être appliquée, ni quelle comparaison crée l’égalité. Une preuve de décodage ne peut donc pas devenir, sans étapes supplémentaires, une preuve d’identité.

Dans un incident, il faut résister à une conclusion séduisante : « le point de code est exact, donc le système a traité le bon utilisateur ». La première proposition peut être démontrée par RFC 5137. La seconde exige la règle de normalisation, le profil d’identifiant, la clé interne et la décision d’autorisation. Un fait vrai ne devient pas plus complet parce qu’il est écrit en hexadécimal.

Ne pas confondre valeur Unicode et emballage

Le point de code est un nombre dans l’espace Unicode. UTF-8 le transforme en un à quatre octets ; UTF-16 le représente par une ou deux unités de seize bits. L’échappement de ces unités décrit l’emballage, tandis que l’échappement du point de code décrit directement la valeur recherchée. Les deux peuvent être utiles, mais ils ne répondent pas à la même question.

Une trace réseau a besoin des octets d’origine. Un rapport d’analyse a besoin du point de code obtenu. Une chaîne robuste conserve les deux avec la conversion qui les relie. Si elle ne garde que les fragments d’octets, l’analyste doit deviner l’encodage. Si elle ne garde que le point de code, elle ne peut plus prouver que l’entrée UTF-8 était minimale, complète et valide.

Les caractères hors du plan multilingue de base exposent le risque. En UTF-16, ils deviennent une paire de substituts. Un service peut tronquer la paire, traiter chaque moitié séparément ou transmettre une moitié à une API qui attend une valeur scalaire. RFC 5137 recommande aux nouveaux protocoles Internet de ne pas adopter cette construction comme échappement. Le but est de montrer l’objet entier à la frontière.

Cette préférence n’annule pas les grammaires existantes. Java travaille naturellement avec ses unités UTF-16 ; JSON définit sa propre forme à quatre chiffres et les paires nécessaires. La discipline consiste à nommer la grammaire du champ, pas à supposer qu’un aspect familier suffit. Deux séquences qui commencent par \u peuvent désigner des objets de types différents.

La fin visible de la valeur

Une référence hexadécimale peut contenir quatre, cinq ou six chiffres. Sans fin explicite, le caractère suivant peut être avalé par la valeur, ou deux implémentations peuvent choisir des largeurs différentes. RFC 5137 préfère donc les formes délimitées. Le délimiteur n’est pas un embellissement typographique ; il matérialise la limite de lecture.

La première variante recommandée place quatre à six chiffres entre des apostrophes après un backslash-u minuscule. La seconde reprend la référence numérique XML et conserve le point-virgule terminal. Une forme HTML sans point-virgule perd précisément l’avantage recherché. Le protocole doit aussi expliquer comment écrire un backslash ou une esperluette sans déclencher l’interpréteur.

Une spécification complète fixe l’introducteur, la casse admise, le nombre de chiffres, la terminaison, la plage scalaire, les erreurs et le comportement devant une valeur interdite. Les tests doivent couvrir les frontières de largeur, les caractères hexadécimaux adjacents, les délimiteurs absents, les substituts, les valeurs supérieures à U+10FFFF et l’entrée interrompue.

La tolérance automatique est dangereuse. Accepter tour à tour une valeur de code point, des octets UTF-8 et des unités UTF-16 sous la même syntaxe semble faciliter une migration. En pratique, le producteur et le consommateur peuvent choisir chacun l’interprétation qui les arrange. Une version ou une grammaire distincte vaut mieux qu’un détecteur permissif qui déplace silencieusement la frontière.

Le piège d’un \u familier

Les équipes voient souvent \u et pensent « Unicode ». Ce raccourci efface le contrat. En C, les variantes minuscules et majuscules ont des largeurs différentes. En Java, quatre chiffres représentent une unité UTF-16. JSON utilise également quatre chiffres et compose certains caractères par deux échappements. D’autres langages ajoutent des accolades ou une longueur variable.

Dans leur contexte, ces conventions sont légitimes. Le danger apparaît lorsqu’un système copie la forme sans copier sa définition. Une passerelle peut valider quatre chiffres comme une valeur scalaire alors que le producteur transmet une moitié de paire. Un journal peut afficher les deux moitiés comme deux événements. Un service suivant peut les recomposer et faire apparaître un caractère qui n’a jamais été contrôlé comme unité.

Le profil I-JSON illustre une réponse ciblée : il exige des valeurs scalaires valides et signale le comportement imprévisible des substituts non appariés. Ce n’est pas RFC 5137 qui produit ce contrôle ; c’est un contrat supplémentaire adapté à JSON. La bonne architecture empile des contrats nommés au lieu de chercher une notation magique qui résoudrait tous les contextes.

Lors d’une migration, l’observabilité doit montrer quelle grammaire a été choisie. Compter les succès de décodage sans distinguer les variantes cache le trafic ancien et empêche de supprimer une compatibilité risquée. Le retrait d’un mode doit se fonder sur des producteurs identifiés, pas sur l’absence apparente d’erreurs.

La normalisation n’est pas contenue dans le nombre

Unicode autorise plusieurs suites de points de code canoniquement équivalentes. NFC et NFD organisent cette relation ; NFKC et NFKD ajoutent des transformations de compatibilité. RFC 5198 choisit UTF-8 et NFC pour Net-Unicode. Le modèle de caractères du W3C demande de définir les formes acceptées, produites et comparées. Un échappement parfaitement délimité ne choisit aucune de ces politiques.

L’ordre des opérations devient donc une propriété de sécurité. Un filtre peut examiner la forme ASCII avant décodage, puis laisser apparaître un caractère interdit. Un autre peut vérifier la chaîne décodée avant normalisation, tandis que l’autorisation compare après NFC. Deux entrées distinctes au filtre convergent alors vers une même clé. À l’inverse, un affichage peut normaliser ce que le stockage considère différent.

La section sécurité de RFC 5137 avertit précisément que les contrôles de forme minimale, de normalisation et de sécurité peuvent être appliqués au mauvais moment. La solution consiste à publier le pipeline : valider la grammaire, produire des valeurs scalaires, rejeter les valeurs mal formées, appliquer la normalisation et le profil, calculer la clé de comparaison, puis seulement décider.

Il faut également versionner les tables Unicode et les bibliothèques. Une mise à niveau peut modifier des propriétés ou permettre de nouveaux caractères. La donnée historique ne doit pas être réinterprétée sans trace. Le reçu de normalisation indique la forme, la version, l’étape, la valeur avant transformation et la valeur après transformation.

Un identifiant est une politique, pas une chaîne quelconque

PRECIS fournit des classes et des profils pour les identifiants internationalisés et les chaînes libres. IDNA définit des catégories, la forme NFC et les relations entre A-labels et U-labels pour le DNS. Ces dispositifs commencent là où l’échappement s’arrête : ils déterminent quelles séquences sont admissibles et comment elles se comparent.

Un point de code peut être valide dans Unicode et interdit dans un nom de domaine ou un identifiant de compte. Son acceptabilité peut dépendre du voisinage, du script et de la version. Une étiquette peut être syntaxiquement valide mais entrer en collision avec une valeur existante selon la comparaison locale. RFC 5137 ne fournit aucun reçu de disponibilité ou d’enregistrement.

Le rendu ajoute une incertitude différente. Deux points de code distincts peuvent produire des glyphes proches. Une même séquence peut changer selon la police, le moteur de composition et le contexte bidirectionnel. Afficher le numéro aide l’enquêteur à voir la différence ; cela n’empêche pas l’utilisateur de confondre les formes rendues.

Les identifiants à fort impact exigent une politique de répertoire, des règles de scripts, une détection des collisions, un examen des confusables et une récupération indépendante du libellé visuel. L’autorisation devrait utiliser un identifiant interne stable. Le nom internationalisé reste un attribut visible, révisable et auditable, non la source unique de l’autorité.

Construire des reçus autour de chaque transformation

À l’entrée, conserver les octets, l’encodage déclaré et le canal. Au décodage, conserver la forme ASCII brute, la grammaire sélectionnée et les erreurs. Après l’échappement, enregistrer les valeurs scalaires. Après le profil, enregistrer la version Unicode, la normalisation, les règles contextuelles et la clé de comparaison.

Si un humain intervient, le reçu visuel comporte la police, la direction, la locale, le moteur et le texte environnant. Si une décision d’accès intervient, le reçu d’autorisation comporte le principal interne, la politique, la ressource et le résultat. Aucun écran ni aucune ligne de log ne doit prétendre remplacer cette chaîne complète.

Les essais de boucle doivent traverser les vraies frontières : producteurs Java, parseurs JSON, services UTF-8, bases et clients. Utiliser des caractères hors BMP, des séquences combinées, du texte bidirectionnel, les caractères introducteurs et des valeurs interdites. Vérifier les rejets autant que les réussites. Le remplacement silencieux par un caractère générique est une perte d’information à signaler.

Cette comptabilité peut paraître lourde par rapport à un simple échappement. Elle devient légère lorsqu’elle évite de reconstruire après incident une succession invisible de conversions. RFC 5137 réduit une ambiguïté. Une bonne exploitation empêche qu’elle soit remplacée par cinq ambiguïtés non documentées.

Une norme mince, des responsabilités épaisses

RFC 5137 réussit parce qu’il ne se proclame pas système d’identité. Il offre une valeur par défaut commune lorsque l’ASCII doit porter une référence Unicode. Il rapproche la notation du point de code et rend la limite de la valeur explicite. Il laisse aux protocoles spécialisés le soin de définir le contenu.

La direction doit reproduire cette modestie dans l’organisation. L’équipe protocole possède la grammaire. L’équipe d’exécution prouve le décodage scalaire. L’internationalisation possède la normalisation et le profil. Le produit possède l’égalité et les collisions. La sécurité examine les confusables et l’ordre des contrôles. L’autorisation relie une politique à un principal stable.

Le risque de second ordre apparaît quand l’équipe qui produit la preuve la plus lisible gagne une autorité qu’elle n’a pas. Le parseur montre le bon nombre, donc le compte serait le bon. L’interface montre le bon glyphe, donc les données seraient égales. Le registre accepte la chaîne, donc l’utilisateur serait autorisé. Chaque conclusion franchit une frontière sans reçu.

La bonne réponse n’est pas de diminuer RFC 5137. C’est d’utiliser exactement sa preuve, puis de poursuivre le travail.

Sources

  1. RFC 5137, version HTML
  2. RFC 5137, texte brut
  3. Notice RFC Editor de RFC 5137
  4. Dossier IETF Datatracker de RFC 5137
  5. Historique documentaire de RFC 5137
  6. Recherche d’errata de RFC 5137
  7. RFC 3629, UTF-8
  8. RFC 2781, UTF-16
  9. RFC 5198, Net-Unicode
  10. RFC 6365, terminologie de l’internationalisation
  11. RFC 2277, politique IETF pour les langues et jeux de caractères
  12. RFC 8259, JSON
  13. RFC 7493, I-JSON
  14. RFC 8264, cadre PRECIS
  15. RFC 5890, définitions IDNA
  16. RFC 5891, protocole IDNA
  17. Annexe no 15 de la norme Unicode
  18. Modèle de caractères du W3C
  19. Spécification initiale minimale, décision future localisée et adoption volontaire
  20. Sur les couches de réalité, le pouvoir symbolique et l’hostilité de la clarté
  21. Running-Code Primary