Zusammenfassung

  • RFC 2070 trennte die externe Bytecodierung einer konkreten HTML-Ressource vom festen abstrakten UCS-Dokumentzeichensatz; der HTTP- oder MIME-Parameter charset benannte die Decodierabbildung.
  • Numerische Zeichenreferenzen wurden im festen Dokumentzeichensatz aufgelöst und bewahrten deshalb ihre Zeichenidentität über verschiedene externe Codierungen hinweg.
  • Erfolgreiches Decodieren war nur ein Beleg für eine Stufe. SGML-Parsing, Sprach- und Bidirektionalitätsregeln, Schriftabdeckung, Glyphenausgabe und Leserinterpretation blieben getrennte Zustände.

Nehmen wir den kyrillischen Großbuchstaben И. Eine Ressource kann ihn in einer unterstützten Codierung wörtlich tragen, eine andere als И notieren. Eine dritte kann diese Referenz selbst in einer mehrbyteigen UCS-Darstellung speichern. Die Oktettfolgen unterscheiden sich deutlich. Mit dem richtigen Decoder und gültigem Markup führen alle Wege zur selben Zeichennummer im HTML-Dokument.

Genau dort lag die entscheidende Grenze. Die Bytes waren Eigenschaften der konkreten Ressource; die Nummer gehörte zum abstrakten Dokument. Würden beide Ebenen vermischt, könnte ein Server durch den bloßen Wechsel der Transportcodierung die Bedeutung einer Referenz ändern. RFC 2070 stabilisierte das Ziel und ließ die Variabilität am Decodereingang.

SGML brauchte vor dem Parsing eine Zeichenwelt

HTML war noch als SGML-Anwendung spezifiziert. Ein SGML-Dokumentzeichensatz war keine Liste von Bytes, die eine Datei enthalten durfte, sondern ein Repertoire samt Nummern, mit denen Dokumenttyp und Instanzen Zeichen identifizierten. DTD, Markup und Daten wurden in diesem gemeinsamen nummerierten Raum verstanden.

Die HTML-2.0-Basis in RFC 1866 enthielt Latin-1, richtete dessen Positionen an ISO 10646 aus und verwies auf ein größeres künftiges Repertoire. RFC 2070 vollzog diesen Schritt für sein Internationalisierungsprofil von HTML 2.x und wählte den Universal Character Set nach ISO 10646:1993 samt Änderungen. Zum Veröffentlichungszeitpunkt beschrieb der RFC ihn als codepunktgleich mit Unicode 1.1.

Das größere Repertoire machte nicht jede Zahl legal. Die SGML-Deklaration ließ die Positionen 128 bis 159 unbenutzt; ’ blieb daher in diesem Modell ungültig, auch wenn spätere Programme ihm häufig ein typografisches Aussehen gaben. „Unicode-Seite“ konnte zwei verschiedene Aussagen verdecken: welche abstrakten Zeichen HTML benennen konnte und wie eine einzelne Ressource sie extern serialisierte. RFC 2070 fixierte Ersteres, ohne für Letzteres eine einzige Bytecodierung zu verlangen.

charset wählte den Weg hinein, nicht das Ziel

Die externe Codierung kam aus dem Übertragungs- oder Speicherkontext. Bei HTTP identifizierte charset im Antwortfeld Content-Type die Codierung; bei E-Mail erfüllte der MIME-Parameter dieselbe Aufgabe mit eigenen Standardregeln. Für FTP und verteilte Dateisysteme gab es laut RFC damals kein standardisiertes Signal.

Die MIME-Bezeichnung konnte irreführen. charset meinte nicht nur ein Repertoire, sondern ein Verfahren zur Abbildung von Oktettfolgen auf Zeichenfolgen; mehrere Oktettfolgen konnten zum selben Zeichen führen. RFC 2045 verlangte für einen benannten MIME-Charset eine vollständige Definition dieser Abbildung, aber nicht, dass sich jedes abstrakte Zeichen in Gegenrichtung codieren ließ.

Das Referenzmodell lautete: Ressource → Decoder → Entity Manager → SGML-Parser → Anwendung → Anzeige. Der Decoder überführte die externe Darstellung in den Dokumentzeichensatz. Die folgenden Stufen arbeiteten mit Dokumentzeichen; die Anzeige konnte diese nochmals in eine Geräteform übersetzen. Eine Implementierung musste keine Bauteile mit genau diesen Namen besitzen. Ihr von außen sichtbares Verhalten musste die Grenze erhalten. Das Diagramm war ein Vertrag, keine Bestandsaufnahme damaliger Browser.

Die Referenz blieb gleich, weil sie nach dem Decodieren kam

RFC 2070 nannte die Unveränderlichkeit numerischer Zeichenreferenzen die wichtigste Folge des Modells. Da sie im festen Dokumentzeichensatz aufgelöst wurden, bezeichneten sie unabhängig von der externen Codierung dieselben Zeichen.

Die Reihenfolge ist entscheidend. Zuerst müssen die Bytes korrekt in die Markupzeichen &, #, Ziffern und ; überführt werden. Erst danach erkennt SGML die Referenz und wertet ihre Zahl aus. Eine Referenz repariert keinen falsch decodierten Strom; sie wird nach dem korrekten Grenzübertritt stabil.

Auch in Gegenrichtung entsteht keine Bytegarantie. Der RFC warnte, dass selbst ein unveränderter Standardwert eines Formulars in anderen, ebenfalls gültigen Oktetten zurückgesandt werden konnte. Zusammengesetzte Sequenzen und vorkomponierte Zeichen konnten äquivalenten Text verschieden darstellen. Kopieren, Speichern und Absenden waren neue Codierungsereignisse, keine bitgetreue Rückgabe der Ausgangsdatei.

Auch das Codierungssignal hatte eine Beweishierarchie

RFC 2070 benannte Einsatzprobleme des Jahres 1997: Server ließen passende charset-Angaben weg, und manche Browser verarbeiteten Content-Type mit charset fehlerhaft. Das ist eine historische Beobachtung, keine Aussage über heutige Marktanteile.

Vorrang hatte der Charset von der Quelle, danach ein frühes META HTTP-EQUIV, zuletzt das beratende CHARSET-Attribut eines Links. META litt unter einem Startproblem: Der Parser konnte es nur finden, wenn die Bytes davor bereits hinreichend gut decodiert waren. Deshalb nannte der RFC das Verfahren nicht narrensicher und beschränkte seinen praktischen Nutzen auf Codierungen, deren Beginn ASCII-Werte geeignet darstellte.

Die Rangfolge trennte Autorität von Verfügbarkeit. Ein naher Hinweis konnte früher sichtbar sein, ohne die Autorität der Antwortmetadaten zu erhalten. Umgekehrt blieb ein autoritatives Label eine Behauptung. Es bewies weder die Übereinstimmung des Körpers noch die korrekte Implementierung des Decoders.

Ein decodiertes Zeichen konnte auf dem Bildschirm scheitern

UCS erweiterte, was HTML identifizieren konnte, erzeugte aber keine Schriften. RFC 2070 rechnete mit Zeichen, die ein System parsen, jedoch nicht darstellen konnte, und schrieb keine einzige Ersatzdarstellung vor. Ein Kästchen oder eine Hexadezimalanzeige war Präsentationspolitik, keine neue Zeichenidentität.

Sprache und Richtung fügten weitere Zustände hinzu. LANG konnte Glyphenauswahl, Anführungszeichen, Trennung, Ligaturen, Abstand und Sprachausgabe beeinflussen. DIR, BDO und der Unicode-Bidi-Algorithmus konnten die visuelle Reihenfolge für semantische Lesbarkeit ändern. Sie arbeiteten nach der Zeichenbestimmung und deuteten nicht die externen Bytes neu.

Damit gab es mindestens vier verschiedene Fehler: falsches Codierungssignal, falsche Decoder-Ausgabe, abgelehntes oder fehlerhaft strukturiertes Markup sowie fehlende Schrift oder schlechte Sprach- und Richtungsbehandlung. Ein Screenshot identifiziert die zuerst gescheiterte Stufe nicht. Ein korrekter Bytehash beweist keinen späteren Erfolg.

Die Grenze überdauerte den institutionellen Wechsel

Als die Zuständigkeit für HTML zum W3C wechselte, erklärte RFC 2854 RFC 2070 und ältere IETF-HTML-Dokumente für überholt. Das ist eine Tatsache der Governance und Dokumentgeschichte, kein Beleg für das Ende der Decodergrenze. Die spätere Registrierung von text/html beschrieb charset weiterhin als Codierung, mit der ein HTML-Dokument als Bytes dargestellt wird. HTML 4.01 hielt ebenfalls fest, dass der Dokumentzeichensatz allein eine ausgetauschte Bytefolge nicht interpretieren kann.

Lu Hengs spätere Unterscheidung zwischen minimaler Anfangsspezifikation, lokalen Zukunftsentscheidungen und freiwilliger Übernahme bietet eine hilfreiche Rückschau. Der feste Nummernraum war eine kleine gemeinsame Invariante. Unterstützte Decoder, Fehlerverhalten, Schriften und Präsentation blieben lokale Implementierungsentscheidungen. Eine veröffentlichte Regel führt diese Entscheidungen nicht aus.

Die bleibende Lehre lautet: Angekommene Bytes sind noch kein Dokument, und eine aufgelöste Nummer ist noch keine Glyphe. Jeder Übergang braucht eigene Evidenz. Keine Stufe kann ihre Reichweite vergrößern, indem sie den Beleg der vorherigen ausleiht.

Quellen