Zusammenfassung

  • Net-Unicode nach RFC 5198 verbindet UTF-8 mit NFC, dem versionsabhängigen Zuweisungsstatus, CRLF und Regeln für Steuerzeichen. Ein erfolgreicher Decoder belegt nur den ersten Schritt.
  • Betriebssystem- und Sprachbibliotheken können ihre Unicode-Tabellen ohne Anwendungsänderung austauschen. Reproduzierbarkeit verlangt deshalb die tatsächlichen Laufzeitdaten und die konkreten Ein- und Ausgangsbelege.

Der fehlende Eintrag im Änderungsnachweis

Ein Artefakt-Hash ist präzise, aber nicht allwissend. RFC 5198 beschreibt, dass Anwendungen Unicode-Konvertierung und Normalisierung meist an Betriebssystem- oder Sprachfunktionen delegieren. Diese Funktionen können sich ändern, ohne dass sich der Anwendungscode ändert. Die Anwendung kennt womöglich weder die Unicode-Version noch die Version des Normalisierungsverfahrens und kann ihre Konsistenz nicht garantieren.

Die Aussage ist enger als allgemeine Instabilität. Eine bereits NFC-normalisierte Zeichenfolge ohne unzugewiesene Punkte bleibt nach der zugrunde gelegten Stabilitätsgarantie auch in späteren Versionen NFC. Beweglich ist der Rand des Repertoires. Ein unzugewiesener Punkt normalisiert zunächst auf sich selbst; nach späterer Zuweisung kann er an einer Abbildung teilnehmen. Ein konformer Sender darf ihn nicht übertragen, solange er in seiner abhängigen Unicode-Version unzugewiesen ist.

Damit kann eine neue Systembibliothek die Zulassungsmenge verändern, obwohl der Produkt-Build identisch ist. gleicher Commit ist kein Beleg für gleiche Textentscheidung.

Mehr als gültiges UTF-8

RFC 3629 definiert die Kodierung. RFC 5198 ergänzt ein Netzwerktextprofil. Zeilen enden, sofern das Protokoll Zeilen kennt, ausschließlich mit CRLF. CR NUL ist nur ein missliebiger Altfall; NUL kann Programmiersprachen als Stringende dienen. C1-Steuerzeichen sind verboten. IND, NEL, U+2028 und U+2029 ersetzen CRLF nicht. Ein BOM am Anfang ist unzulässig.

Vor dem Senden sollen Folgen NFC-normalisiert werden. Unzugewiesene Punkte sind verboten, und Unicode- sowie NFC-Version müssen zusammenpassen. Dekodierung, Repertoireprüfung, Normalisierung, Zeilenregel und Anwendungsentscheidung benötigen getrennte Ergebnisse.

Auch die Errata haben Zustände. Der technische Hinweis 7531 ist nur Reported und korrigiert die falsche Einordnung von U+0080–U+009F als ASCII-Bereich; das ausdrückliche C1-Verbot bleibt bestehen. Das verifizierte Erratum 1402 korrigiert lediglich einen Verweis. Ein Implementierer darf diese Autoritätsstufen nicht stillschweigend vermischen.

Zwei Kontrollpunkte, zwei Textzustände

RFC 5198 warnt davor, Eingangsdaten als bereits normalisiert anzunehmen. Nicht normalisierte Formen können naive Textsuche in Firewalls umgehen. Nutzt das Gateway andere Tabellen als die Anwendung, ist ein Allow-Ereignis kein Beleg dafür, dass beide dieselbe Folge verglichen haben.

Die Reihenfolge gehört zum Beleg: Normalisierung vor Signaturprüfung ist nicht die Prüfung der empfangenen Oktette mit anschließender Normalisierung. Zeilenumbruch-Konvertierung verändert Offsets; BOM-Entfernung ist eine Transformation. Für Protokolle mit eigener präziser UTF-8-Regel gilt deren Profil. Der Nachweis muss benennen, welches tatsächlich angewandt wurde.

Ein ausführbarer Beleg

Neben Anwendungsfassung und Hash gehören Basisimage, Sprachlaufzeit, Unicode Character Database, NFC-Implementierung und Datensatzversion in den Datensatz. Nicht exponierte Versionen werden als unbekannt markiert.

Pro Nachricht verbindet der Beleg den Oktett-Hash mit UTF-8-Ergebnis, Codepunkten und Zuweisungsurteil. BOM, Private Use, C0, C1, CR, LF, CR NUL, U+2028 und U+2029 bleiben eigene Felder. Hashes vor und nach NFC zeigen, ob geprüft oder transformiert wurde.

Vergleich, Filterung, Signatur oder Speicherung werden schließlich von Autorität und beobachteter Wirkung getrennt. Net-Unicode beweist weder Identität noch Berechtigung. Es kann aber beweisen, welcher Textvertrag unter einem scheinbar unveränderten Release lief.

Quellen

  1. RFC 5198 HTML
  2. RFC 5198 Text
  3. RFC-5198-Informationsseite
  4. IETF Datatracker: RFC 5198
  5. RFC-5198-Historie
  6. RFC-5198-Referenzen
  7. RFC-5198-Errata
  8. RFC 3629 — UTF-8
  9. RFC 2277 — Zeichensätze und Sprachen
  10. RFC 4690 — internationalisierte Namen
  11. RFC 3454 — Stringprep
  12. RFC 8264 — PRECIS
  13. RFC 6365 — Internationalisierungsterminologie
  14. RFC 854 — Telnet
  15. RFC 698 — Extended ASCII
  16. Unicode Standard Annex #15
  17. Unicode-Stabilitätsrichtlinie
  18. Heng Lu — Realitätsebenen und symbolische Macht
  19. Heng Lu — minimale Anfangsspezifikation
  20. Heng Lu — Vorrang von Running Code