RFC 9839 und fehlerhaftes Unicode

• RFC 9839 definiert klar, welche problematischen Unicode-Zeichen bei der Softwareentwicklung in Textfeldern enthalten sein können
• Das RFC behandelt Probleme, die aus der mangelnden Konsistenz bei der Verarbeitung dieser Zeichen in verschiedenen Sprachen und Bibliotheken entstehen
• RFC 9839 schlägt drei weniger problematische Teilmengen vor, die optional genutzt werden können
• Im Vergleich zum bestehenden PRECIS-Framework ist die Anwendung einfacher und unkomplizierter
• Zusammen mit RFC 9839 wurde auch eine Go-Sprachbibliothek veröffentlicht, die die praktische Nutzung erleichtert

---

Hintergrund und Überblick über RFC 9839

• Unicode wird als Standard für nahezu jede Verarbeitung von Textdaten verwendet
• Wenn man bei der Gestaltung realer Datenstrukturen oder Protokolle jedoch alle Unicode-Zeichen zulässt, entstehen Probleme
• Paul Hoffman und der Autor reichten bei der IETF einen individuellen Entwurf ein, um klare Kriterien für immer wiederkehrende Unicode-Probleme zu schaffen
• Nach zwei Jahren Diskussion wurde er als offizieller Standard angenommen und als RFC 9839 veröffentlicht
• Das Dokument erläutert detailliert Arten problematischer Zeichen, warum sie problematisch sind (aus technischen und normativen Gründen) und drei Teilmengen, aus denen Nutzer wählen können

Die wichtigsten Inhalte von RFC 9839

• Es ist ein Dokument, das bei der Gestaltung von Textfeldern in Software- und Netzwerkumgebungen unbedingt berücksichtigt werden sollte
• RFC 9839 umfasst 10 Seiten und ist damit unter den IETF-Standarddokumenten eher knapp gehalten
• Es ist vor allem für Softwareentwickler und Netzwerkingenieure leicht verständlich erklärt

Beispiele für problematische Unicode-Zeichen

• Beispielsweise könnte im JSON-Feld username folgende Zeichenkette stehen

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

• Die Probleme der einzelnen Codepoints
  • U+0000 : ein bedeutungsloses NULL-Zeichen, das das Verhalten einiger Programmiersprachen stören kann
  • U+0089 : ein C1-Steuerzeichen (CHARACTER TABULATION WITH JUSTIFICATION), dessen Verhalten komplex und uneinheitlich ist
  • U+DEAD : ein nicht gepaartes Surrogat-Zeichen, ein Problem, das aus den Grenzen von UTF-16 stammt. Dadurch entstehen nicht ideale Daten
  • \uD9BF\uDFFF (tatsächlich U+7FFFF) : ein Noncharacter, dessen Austausch laut Standard verboten ist
• Solche Codepoints führen innerhalb von Datenstrukturen und Protokollen zu inkonsistenter Verarbeitung und unerwarteten Fehlern
• RFC 9839 definiert solche problematischen Zeichen offiziell und legt klar fest, welche Typen ausgeschlossen werden sollen

Design und Grenzen von JSON

• Das ist nicht die Verantwortung des JSON-Erfinders Doug Crockford
• JSON wurde in einer Zeit entworfen, als Unicode noch nicht ausreichend ausgereift war, weshalb der Zeichensatz nicht strikt eingeschränkt werden konnte
• Da sich der Standard heute nicht mehr ändern lässt, wird ein empirischer Ansatz zum Ausschluss problematischer Zeichen benötigt

Unterschiede zum PRECIS-Framework der IETF

• Schon vor RFC 9839 von 2025 bot die IETF verschiedene Standards an, darunter RFC 8264 (PRECIS Framework)
  • Dieses Framework behandelt ausführlich, wie internationalisierte Zeichenketten aufbereitet, angewendet und verglichen werden
  • Mit 43 Seiten ist es umfassend in Hintergrund und Lösungsansätzen
• PRECIS hängt stark von Unicode-Versionen ab und hat den Nachteil, komplex und schwer anzuwenden zu sein
• RFC 9839 ist knapp und praxisorientiert angelegt und lässt sich bei der Definition neuer Protokolle schnell übernehmen

Teilmengen von RFC 9839 und Anwendungsbeispiele

• RFC 9839 stellt drei realistische Teilmengen vor: scalars, XML und assignables
• Jede Teilmenge unterscheidet sich leicht im Bereich der auszuschließenden problematischen Zeichen
• Nachfolgend eine Zusammenfassung der Tabelle dazu, wie wichtige Datenformate und die Teilmengen aus RFC 9839 mit problematischen Zeichen umgehen
  • Einige Formate wie CBOR, TOML, XML, YAML schließen Surrogate oder Steuerzeichen teilweise aus
  • I-JSON schließt Surrogate und Noncharacters aus
  • Normales JSON, Protobufs schließen sie nicht aus
  • XML, YAML schließen aufgrund ihrer Charset-Eigenschaften Noncharacters/Steuercodes nur teilweise aus
    • Hinweis: XML und YAML schließen Noncharacters außerhalb der Basic Multilingual Plane nicht aus

Go-Bibliothek für RFC 9839

• Es wurde eine kleine Go-Bibliothek veröffentlicht, die Zeichenvalidierung für die drei Teilmengen aus RFC 9839 unterstützt
• Sie wurde bereits ausreichend getestet, Optimierungen laufen jedoch noch
• Tests und Feedback aus der Praxis sind willkommen

Bedeutung von RFC 9839 und Entstehungsprozess

• RFC 9839 wurde nach mehreren Feedback-Runden mit den Mitautoren und mehr als 15 Überarbeitungen des Entwurfs offiziell veröffentlicht
• Durch Diskussionen und Beiträge vieler Fachleute aus der Community entwickelte es sich zu einem deutlich ausgereifteren Dokument als die Erstfassung
• Die Mitwirkenden werden im Abschnitt „Acknowledgements“ genannt

Erfahrungen mit einer individuellen RFC-Einreichung

• RFC 9839 wurde als individual submission eingereicht
• Im Vergleich zum traditionellen Weg über eine Working Group ist der Aufwand bei Arbeit und Verfahren größer
• Verglichen mit Erfahrungen in Working Groups ist der traditionelle Weg effizienter und eher zu empfehlen