Zusammenfassung

  • RFC 5137 gilt dort, wo ein Protokoll ein ASCII-Escape benötigt; kann es natives UTF-8 tragen, ist das im Allgemeinen vorzuziehen.
  • Empfohlen wird der Unicode-Codepunkt statt einer erneuten Darstellung seiner UTF-8-Oktette oder UTF-16-Codeeinheiten.
  • Das Protokoll muss die vollständige Grammatik und die literale Darstellung des Escape-Einleiters festlegen.
  • Explizite Endbegrenzer trennen vier-, fünf- oder sechsstellige Hexadezimalwerte eindeutig vom Folgetext.
  • \u benennt keine universelle Grammatik, weil C, Java, JSON und weitere Umgebungen ähnliche Formen verschieden deuten.
  • Internetprotokolle sollten Surrogatpaare nicht als allgemeines Escape-Modell verwenden.
  • Empfohlen werden unter anderem ein begrenztes Backslash-u-Format und die XML-Hexadezimalreferenz mit abschließendem Semikolon.
  • Ein korrekt gewonnener Codepunkt beweist weder Gültigkeit und Normalisierung der Gesamtzeichenfolge noch deren Eignung als Kennung.
  • Sicherheitsprüfungen können umgangen werden, wenn sie auf der falschen Seite von Unescaping oder Normalisierung liegen.
  • Numerische Identität, sichtbare Ähnlichkeit, Kennungsgleichheit und Kontobindung sind verschiedene Behauptungen.
  • Nachweise sollten Rohbytes, Escape-Schreibweise, Skalarwerte, Profil, Vergleichsschlüssel und Entscheidung getrennt erhalten.
  • Führung muss verhindern, dass die sauberste technische Quittung automatisch Autorität über spätere Bedeutungsschichten erhält.

Eine API-Grenze mit zwei Wahrheiten

Ein Client sendet einen Namen als ASCII-Folge. Das Gateway akzeptiert ihn, die Laufzeit rekonstruiert Unicode, ein Verzeichnis normalisiert, und ein Berechtigungsdienst sucht einen Schlüssel. Jeder Schritt kann korrekt implementiert sein und dennoch kann das Gesamtsystem über die Identität uneins sein.

RFC 5137 bearbeitet die früheste Grenze. Wenn direkte Unicode-Übertragung nicht praktikabel ist, soll das Escape nach Möglichkeit den Codepunkt bezeichnen. Menschen können den Wert direkt in der Unicode-Tabelle nachschlagen, statt zunächst UTF-8-Oktette oder UTF-16-Einheiten zusammenzusetzen. Fehler werden sichtbarer und die Form ist außerhalb von ASCII meist kürzer.

Der Standard beansprucht aber keine allgemeine Hoheit über Unicode-Strings. Er setzt voraus, dass das zu escapende Material bereits gültig und vernünftig ist. Ob es als Benutzername zulässig ist, wie es normalisiert wird, welcher Vergleich gilt und welches Konto gemeint ist, entscheiden andere Spezifikationen und lokale Systeme.

Darum ist „der Parser lieferte den richtigen Codepunkt“ ein begrenzter Befund. Zwischen ihm und „die richtige Person erhielt Zugriff“ liegen Profil, Normalisierung, Kollisionsprüfung, interner Principal und Policy. Ohne diese Quittungen darf syntaktische Präzision keine semantische Entscheidung autorisieren.

Codepunkt und Serialisierung auseinanderhalten

Ein Unicode-Codepunkt ist ein ganzzahliger Wert. UTF-8 serialisiert ihn in ein bis vier Oktette, UTF-16 in eine oder zwei 16-Bit-Einheiten. Wer Einheiten escapet, beschreibt die Verpackung. Wer den Codepunkt escapet, bezeichnet unmittelbar den abstrakten Wert.

Bei UTF-8-Oktetten zerfällt ein Nicht-ASCII-Zeichen in mehrere Zahlen. Der Leser muss das Encoding kennen und eine weitere Dekodierung durchführen. Abbruch, Vertauschung und falsche Zeichensatzannahmen bleiben leichter verborgen. RFC 5137 bevorzugt daher Codepunktreferenzen, sofern nicht wirklich die serialisierte Form Gegenstand des Protokolls ist.

Die Rohbytes bleiben trotzdem beweisrelevant. Der spätere Skalarwert zeigt nicht, ob am Eingang ungültiges oder überlanges UTF-8 stand oder ob eine Bibliothek still ein Ersatzzeichen eingesetzt hat. Eine robuste Kette bewahrt sowohl Bytes und deklariertes Encoding als auch Skalarwerte und Dekodierfehler.

Bei UTF-16 brauchen Zeichen außerhalb der BMP ein Surrogatpaar. Eine Hälfte passt in ein vierstelliges Escape, ist allein aber kein Unicode-Skalarwert. Prüft ein Dienst beide Hälften getrennt und fügt ein anderer sie zusammen, entsteht das wirksame Zeichen erst nach der Kontrolle. Daher sollen Internetprotokolle Surrogatpaare nicht als Escape-Mechanismus wählen.

Der Endbegrenzer ist eine Prüfspur

Codepunkte reichen bis U+10FFFF; direkte Hexadezimalwerte können vier, fünf oder sechs Stellen umfassen. Ohne sichtbares Ende kann ein nachfolgendes Hexadezimalzeichen Teil des Wertes werden. Verschiedene Annahmen über feste oder variable Breite führen zu verschiedenen Ergebnissen.

RFC 5137 empfiehlt unter anderem eine Backslash-u-Form mit Apostrophen um die Ziffern. Die XML-Variante beginnt als numerische Hexadezimalreferenz und endet mit einem Semikolon. Wird das Semikolon in einer HTML-artigen Form weggelassen, verschwindet gerade der Vorteil des Begrenzers. Auch für einen literalen Backslash oder ein literales kaufmännisches Und braucht das Protokoll eine Regel.

Nicht ein einziges Satzzeichen ist für jeden Kontext vorgeschrieben. Entscheidend ist eine abgeschlossene Grammatik: Einleiter, Stellenzahl, Groß- und Kleinschreibung, Ende, zulässiger Wertebereich, Literale und Fehlerverhalten. Die Grammatik gehört zur Felddefinition, nicht zum impliziten Wissen einer Bibliothek.

Konformitätstests müssen Grenzen prüfen: vier bis sechs Stellen, unmittelbar anschließende Hexadezimalzeichen, fehlendes Ende, Surrogatbereich, Werte jenseits von U+10FFFF und abgeschnittene Eingaben. Zwei unabhängige Implementierungen müssen bei Annahme und Ablehnung übereinstimmen.

Warum \u keinen Datentyp bezeichnet

C verwendet Varianten unterschiedlicher Breite. Java versteht vier Stellen als UTF-16-Codeeinheit. JSON besitzt ebenfalls vierstellige Escapes und bildet bestimmte Zeichen aus einem Paar. Andere Sprachen erlauben Klammern oder variable Länge. Die sichtbare Gemeinsamkeit des Präfixes verdeckt unterschiedliche Objekte.

Innerhalb ihrer Kontexte sind diese Formen legitim. Problematisch wird die pauschale API-Beschreibung „Unicode-Escape“. Producer und Consumer können auf der BMP scheinbar übereinstimmen, obwohl der eine Codeeinheiten und der andere Codepunkte erwartet. Erst ergänzende Zeichen decken den Vertragsbruch auf.

Für JSON besitzt RFC 8259 die Grammatik. I-JSON verschärft sie für Interoperabilität, fordert gültige Unicode-Skalarwerte und vermeidet unvorhersehbare ungepaarte Surrogate. Sicherheit entsteht durch benannte Schichten, nicht durch die vertraute Optik des Präfixes.

Migrationen dürfen Bedeutungen nicht still erraten. Alte Oktettformen und neue Codepunktformen brauchen vor dem Dekodieren unterscheidbare Versionen oder Syntax. Telemetrie muss Produzenten zuordnen, sonst wird eine großzügige Übergangsregel zur dauerhaften Angriffsfläche.

Nach dem Unescaping beginnt die Stringpolitik

Verschiedene Codepunktfolgen können kanonisch äquivalent sein. UAX #15 definiert NFC, NFD, NFKC und NFKD. RFC 5198 wählt für Net-Unicode UTF-8 und NFC. Das W3C Character Model verlangt Angaben darüber, welche Formen ein System annimmt, erzeugt und vergleicht.

Ein korrekt begrenztes Escape entscheidet nichts davon. Es kann eine genaue, aber noch nicht normalisierte Folge liefern. Es kann einen gültigen Skalar liefern, den das Feldprofil verbietet. Syntax, Skalarwert, Normalform und Kennungstauglichkeit sind aufeinanderfolgende Kontrollen.

Die Reihenfolge ist sicherheitsrelevant. Eine Sperrliste vor dem Unescaping kann von numerischer Schreibweise umgangen werden. Eindeutigkeitsprüfung vor Normalisierung und Suche nach NFC können zwei registrierte Werte zusammenfallen lassen. Normalisierung nur in der Anzeige erzeugt sichtbare Gleichheit bei getrennten Berechtigungsschlüsseln.

Die Quittung muss Form, Unicode-Version, Bibliothek, Ausführungsstufe, Eingabe und Ausgabe nennen. Auch Längenbegrenzung und Case-Mapping brauchen eine definierte Stufe. Ein unqualifiziertes „normalisiert“ ist ebenso schwach wie ein \u ohne Grammatik.

Kennungen sind kontrollierte Mengen

PRECIS bietet Klassen und Profile für internationalisierte Kennungen und freie Strings. IDNA regelt für DNS-Labels Kategorien, NFC und die Beziehung zwischen A-Label und U-Label. Beide zeigen, wie viel Politik nach dem Parsen der Codepunkte beginnt.

Ein gültiger Unicode-Skalar kann im konkreten Feld verboten sein. Zulässigkeit kann von Nachbarschaft, Schrift und Version abhängen. Ein DNS-Label braucht spezifische Umwandlung und Rückprüfung. Das numerische Escape beweist weder Registrierbarkeit noch Besitz oder Ziel.

Auch visuelle Gleichheit folgt nicht. Unterschiedliche Codepunkte können ähnlich aussehen; Fonts, Shaping und bidirektionaler Kontext verändern die Wahrnehmung. Die numerische Anzeige hilft der Analyse, verhindert aber nicht, dass ein Mensch zwei Labels verwechselt.

Für folgenreiche Kennungen braucht es Repertoire- und Schriftregeln, Confusable-Prüfung, Kollisionsbehandlung und einen Wiederherstellungsweg außerhalb des sichtbaren Namens. Berechtigungen sollten an eine stabile, opake interne ID gebunden sein; der internationale Name bleibt ein überprüfbares Attribut.

Die Transformationskette beweisbar machen

Am Eingang: Bytes, Encoding, Kanal. Im Parser: Rohschreibweise, Grammatik, Fehler. Danach: Skalarwerte. Im Profil: Unicode-Version, Normalform, Kontextregeln, Vergleichsschlüssel. In der Autorisierung: interner Principal, Ressource, Policy, Ergebnis.

Wo Menschen nach Darstellung entscheiden, gehören Font, Locale, Richtung und Shaping hinzu. Ein Screenshot beweist die Erscheinung, aber nicht die gespeicherte Folge. Ein Rohlog beweist Daten, aber nicht zwingend die Wahrnehmung. Die Belege müssen verknüpft bleiben.

Ende-zu-Ende-Tests müssen reale Java-, JSON-, UTF-8-, Datenbank- und Clientgrenzen kreuzen. Ergänzende Zeichen, kombinierende Folgen, Rechts-nach-links-Text, literale Einleiter und ungültige Werte gehören in den Satz. Stiller Ersatz ist eine Identitätsänderung und kein Erfolg.

So lässt sich im Störungsfall genau die Transformation finden, an der zwei Systeme auseinanderliefen. „Unicode“ wird nicht zum pauschalen Schuldigen, und kein Dashboard darf Realitätsschichten vertreten, die es nicht beobachtet.

Eine dünne Norm braucht klare lokale Zuständigkeit

RFC 5137 bleibt absichtlich schmal. Es verbessert die Bezeichnung eines Codepunkts über eine ASCII-Grenze, ohne Registrierung, Identität oder Autorisierung zu übernehmen. Gerade dadurch kann es in unterschiedlichen Protokollen nützlich sein.

Protokollverantwortliche besitzen die Grammatik. Laufzeitteams beweisen Skalarwerte. Internationalisierung besitzt Normalisierung und Profil. Produktteams definieren Gleichheit und Kollision. Sicherheit prüft Reihenfolge und Verwechslung. Autorisierung bindet Entscheidungen an stabile Principals.

Das Risiko zweiter Ordnung entsteht, wenn das Team mit der lesbarsten Quittung über den gesamten Vorgang urteilt. Ein exakter Codepunkt wird zum vermeintlich exakten Konto; ein erwartetes Glyph zum vermeintlich gleichen Speicherwert. Lokale Wahrheit wird ohne Grenzmarke zu globalem Irrtum.

Der Parser darf recht haben. Das System muss trotzdem jede spätere Behauptung neu beweisen.

Quellen

  1. RFC 5137 als HTML
  2. RFC 5137 als Text
  3. RFC-Editor-Eintrag zu RFC 5137
  4. RFC 5137 im IETF Datatracker
  5. Dokumenthistorie von RFC 5137
  6. Errata-Suche zu RFC 5137
  7. RFC 3629: UTF-8
  8. RFC 2781: UTF-16
  9. RFC 5198: Net-Unicode
  10. RFC 6365: Internationalisierungsterminologie
  11. RFC 2277: IETF-Richtlinie für Sprachen und Zeichensätze
  12. RFC 8259: JSON
  13. RFC 7493: I-JSON
  14. RFC 8264: PRECIS-Framework
  15. RFC 5890: IDNA-Definitionen
  16. RFC 5891: IDNA-Protokoll
  17. Unicode Standard Annex 15
  18. W3C Character Model
  19. Minimale Anfangsspezifikation, lokale Zukunftsentscheidung und freiwillige Übernahme
  20. Über Realitätsschichten, symbolische Macht und feindlich wirkende Klarheit
  21. Running-Code Primary