RFC 9839 et les caractères Unicode problématiques

• RFC 9839 définit clairement les caractères Unicode problématiques pouvant apparaître dans des champs texte lors du développement logiciel
• Cette RFC traite des problèmes liés au manque de cohérence dans le traitement de ces caractères selon les langages et bibliothèques
• La 9839 propose trois sous-ensembles moins problématiques, utilisables de manière optionnelle
• Elle est plus simple et plus facile à appliquer que le framework PRECIS existant
• Une bibliothèque Go pour RFC 9839 a également été publiée afin d’en faciliter l’usage concret

---

Contexte et aperçu de la RFC 9839

• Unicode est utilisé comme standard dans presque tous les traitements de données textuelles
• Mais dans la conception réelle de structures de données ou de protocoles, autoriser tous les caractères Unicode peut poser problème
• Paul Hoffman et l’auteur ont soumis à l’IETF un draft individuel afin de proposer des critères clairs face à des problèmes Unicode récurrents
• Après deux ans de discussions, le texte a été adopté comme standard officiel et publié sous la forme de la RFC 9839
• Ce document décrit en détail les types de caractères problématiques, les raisons pour lesquelles ils posent problème (techniques et normatives), ainsi que trois sous-ensembles parmi lesquels les utilisateurs peuvent choisir

Principaux points de la RFC 9839

• Il s’agit d’un document de référence essentiel pour la conception de champs texte dans les environnements logiciels et réseau
• La RFC 9839 fait 10 pages, ce qui en fait un document plutôt concis parmi les standards de l’IETF
• Elle est principalement expliquée de manière accessible pour les développeurs logiciels et les ingénieurs réseau

Exemples de caractères Unicode problématiques

• Par exemple, le champ username d’un JSON peut contenir une chaîne comme celle-ci

  {  
      "username": "\u0000\u0089\uDEAD\uD9BF\uDFFF"  
  }  
  

• Problèmes associés à chaque point de code
  • U+0000 : caractère NULL sans signification, qui perturbe le fonctionnement de certains langages de programmation
  • U+0089 : code de contrôle C1 (CHARACTER TABULATION WITH JUSTIFICATION), dont le comportement est complexe et peu cohérent
  • U+DEAD : surrogate non apparié, problème issu des limites de l’UTF-16, produisant des données indésirables
  • \uD9BF\uDFFF (en réalité U+7FFFF) : noncharacter, dont l’échange est interdit par la norme
• De tels points de code rendent un traitement cohérent impossible dans les structures de données et protocoles, et provoquent des erreurs inattendues
• La RFC 9839 définit officiellement ces caractères problématiques et indique clairement les catégories à exclure

Conception et limites de JSON

• Ce n’est pas la responsabilité de Doug Crockford, le créateur de JSON
• JSON a été conçu à une époque où Unicode n’était pas encore suffisamment mature, ce qui a empêché de restreindre strictement le jeu de caractères
• Comme il n’est plus possible de modifier le standard aujourd’hui, il faut exclure empiriquement les caractères problématiques

Différences avec le framework PRECIS de l’IETF

• Avant la RFC 9839 de 2025, l’IETF proposait déjà plusieurs standards, dont la RFC 8264 (PRECIS Framework)
  • Ce framework traite en détail des méthodes de préparation, d’application et de comparaison des chaînes internationalisées
  • Avec ses 43 pages, il est très complet à la fois dans ses explications de fond et dans ses solutions
• PRECIS dépend fortement de la version d’Unicode, et présente l’inconvénient d’être complexe et difficile à mettre en œuvre
• RFC 9839 est concise, centrée sur l’aspect pratique, et facile à adopter rapidement lors de la définition de nouveaux protocoles

Sous-ensembles de la RFC 9839 et exemples d’usage

• La 9839 propose trois sous-ensembles réalistes (scalars, XML, assignables)
• Chaque sous-ensemble diffère légèrement dans l’étendue des caractères problématiques à exclure
• Voici un résumé du tableau expliquant comment les principaux formats de données et les sous-ensembles de la RFC 9839 traitent les caractères problématiques
  • Certains formats comme CBOR, TOML, XML, YAML excluent partiellement les surrogates ou les caractères de contrôle
  • I-JSON exclut les surrogates et les noncharacters
  • JSON standard et Protobufs ne les excluent pas
  • XML et YAML, en raison des caractéristiques de leur charset, n’excluent que partiellement les noncharacters et codes de contrôle
    • Remarque : XML et YAML n’excluent pas les noncharacters en dehors du Basic Multilingual Pane

Bibliothèque RFC 9839 pour Go

• Une petite bibliothèque Go prenant en charge la validation des caractères pour les trois sous-ensembles de la RFC 9839 a été publiée
• Elle a été suffisamment testée, même si les optimisations sont encore en cours
• Les tests en conditions réelles et les retours d’expérience sont bienvenus

Importance de la RFC 9839 et processus de travail

• La RFC 9839 a été publiée officiellement après plusieurs cycles de retours avec les co-auteurs et plus de 15 révisions de drafts
• Grâce aux discussions et contributions de nombreux experts de la communauté, elle est devenue un document bien plus abouti que sa première version
• Les contributeurs sont mentionnés dans la section “Acknowledgements”

Expérience d’une soumission RFC individuelle

• La RFC 9839 a été menée sous forme de soumission individuelle (individual submission)
• Par rapport à la méthode traditionnelle via un Working Group, la charge en efforts et en procédures est plus lourde
• À la lumière de l’expérience acquise dans les Working Groups, la méthode traditionnelle est plus efficace et davantage recommandée