Résumé

  • RFC 9839 nomme trois répertoires de plus en plus restrictifs : Unicode Scalars, XML Characters et Unicode Assignables.
  • La réussite du parseur JSON atteste l’enveloppe, pas l’admissibilité du contenu décodé : des contrôles, un surrogate isolé ou un non-caractère peuvent passer par des échappements.
  • La preuve d’exploitation exige une règle par champ, un choix explicite entre rejet et remplacement, puis les mêmes vecteurs d’essai sur toute la chaîne.

Le piège ne ressemble pas à une panne. La requête obtient 200, l’objet JSON existe et le tableau de bord reste vert. Ce n’est qu’au moment de réécrire la valeur en UTF-8, de la signer ou de l’envoyer dans un autre runtime que la chaîne se fracture.

RFC 9839, publié sur la voie Standards Track en août 2025, fournit précisément le vocabulaire qui manquait. Sa fiche officielle, sa version texte et sa source XML décrivent trois sous-ensembles réutilisables. Elles ne certifient ni les bibliothèques déployées ni les données déjà stockées.

Trois frontières, pas un bouton « Unicode »

Unicode Scalars exclut les 2 048 points de code surrogate, mais conserve les contrôles hérités et les non-caractères. XML Characters retire aussi l’essentiel des contrôles C0 et deux non-caractères du plan multilingue de base, sans tout exclure. Unicode Assignables enlève surrogates, contrôles hérités et tous les non-caractères, tout en laissant entrer les points déjà attribués ou susceptibles de l’être plus tard.

Ces ensembles répondent à des besoins différents. Le standard Unicode définit l’espace et l’UAX 44 ses propriétés. RFC 3629 définit UTF-8 et RFC 2277 sa place dans les protocoles Internet. Mais choisir un encodage ne choisit pas les valeurs autorisées dans un numéro de dossier, un nom affiché ou une assertion signée.

L’intérêt de l’ABNF est institutionnel autant que technique : un contrat peut citer une frontière stable au lieu d’abandonner « Unicode valide » à neuf interprétations. La grammaire XML 1.0 constitue l’un de ces profils historiques, pas une garantie universelle de sécurité.

JSON n’a jamais reçu ce mandat

RFC 8259 et sa fiche de statut définissent le format JSON. Un échappement peut représenter un point de code problématique sans casser la grammaire du document. RFC 9839 montre une valeur contenant NUL, un contrôle C1, un surrogate non apparié et un non-caractère. Le document est conforme ; la valeur ne peut pourtant pas devenir du UTF-8 bien formé.

L’échappement ne blanchit rien. La restriction porte sur la donnée après décodage. Le contrôle doit donc se produire entre le parseur généraliste et l’écriture dans l’état faisant autorité. Le parseur sait reconnaître accolades et séquences d’échappement ; il ignore si le champ sert à l’affichage, à l’identité, à une signature ou à une règle d’accès.

I-JSON, Net-Unicode et PRECIS montrent que plusieurs couches de profilage sont légitimes. Un identifiant destiné à l’humain réclame souvent plus qu’Unicode Assignables : normalisation, contexte, scripts et comparaison ne disparaissent pas.

Rejeter, remplacer, mais ne pas effacer en silence

RFC 9839 admet deux réponses raisonnables : refuser la valeur ou remplacer la partie problématique, idéalement par U+FFFD. Le remplacement garde parfois un flux d’affichage disponible et rend la blessure visible. Il détruit néanmoins l’identité exacte. Il est incompatible avec une signature, un hash, une clé de déduplication ou une pièce probatoire si l’original doit être préservé.

Le rejet protège l’exactitude, mais peut devenir un levier de déni de service si le diagnostic est coûteux. Limitation de débit, message borné et quarantaine sont donc des décisions d’exploitation. RFC 9413 rappelle qu’un protocole robuste traite explicitement l’entrée invalide ; il ne la rend pas acceptable par habitude.

L’effacement silencieux est le pire compromis. Deux chaînes distinctes peuvent devenir identiques, un séparateur invisible disparaître, et le journal ne plus correspondre à la valeur reçue. Le système paraît plus tolérant précisément au moment où sa preuve devient moins fiable.

La matrice d’exécution est la vraie attestation

Il faut faire circuler les mêmes vecteurs par la passerelle, le parseur, le validateur, le broker, le pilote de base, le stockage, le journal, l’export et le consommateur. On distingue échec de syntaxe, violation du sous-ensemble, remplacement volontaire et échec ultérieur de sérialisation. On compare la suite de scalaires, la décision, la classe d’erreur et la valeur persistée.

CBOR utilise par défaut les valeurs scalaires Unicode pour ses chaînes de texte. Cela ferme la porte aux surrogates, pas aux autres points problématiques. Changer de format ne dispense donc pas de choisir le contrat du champ.

Les risques humains restent plus larges. TR36 traite la sécurité Unicode, TR55 le code source, et le W3C distingue caractères, points de code, unités et octets. RFC 9839 ne prétend pas résoudre les confusables, le bidi ou l’équivalence canonique. Cette limite rend son obligation contrôlable.

La conclusion ne dépasse pas les preuves. Aucune bibliothèque, base ou plateforme n’a été testée ici ; aucun taux d’adoption n’est établi. Le standard prouve qu’une frontière peut être nommée. L’opérateur doit encore démontrer que le code en exécution l’applique sans divergence.

Sources