Zusammenfassung
- RFC 1468 dokumentierte ein enges Sieben-Bit-Profil: Text begann in ASCII, vier Escape-Folgen wählten ASCII, JIS X 0201 Roman oder zwei Fassungen von JIS X 0208, und jede Zeile mit Doppelbytezeichen musste vor CRLF in einen Einzelbytezustand zurückkehren.
- Die MIME-Angabe
ISO-2022-JPbezeichnete den erwarteten Decodervertrag. Sie bewies weder die Grammatik des Körpers noch die unveränderte Relay-Übertragung, die rekonstruierten Zeichen, die gewählten Glyphen oder die Wahrnehmung des Lesers.
Ein Zeichensatzname klingt nach einer Tabelle. RFC 1468 beschrieb dagegen eine Abfolge von Zuständen.
Das Dokument erschien im Juni 1993 und hielt eine in JUNET entstandene, in japanischen IP-Gemeinschaften eingesetzte Kodierung fest. Sie blieb vollständig im Sieben-Bit-Raum alter Mailpfade. Japanische Zeichen wurden nicht durch das Setzen des hohen Bits transportiert, sondern indem Steuerfolgen innerhalb des Textes die Lesart der nächsten Werte änderten.
Damit entstand eine präzise Arbeitsteilung. Der Absender erzeugte einen begrenzten Strom. Das Relay musste ihn nicht sprachlich verstehen, aber unverändert verwahren. Der Empfänger musste dieselbe Zustandsfolge ausführen. Interoperabilität war nicht im Etikett enthalten; sie entstand erst, wenn diese drei Rollen denselben Vertrag tatsächlich einhielten.
Vier Sequenzen steuerten die Lesart
Der Ausgangszustand ist ASCII. ESC $ B bezeichnet JIS X 0208-1983, ESC $ @ die Fassung von 1978. Danach belegt jedes Zeichen zwei Bytes. ESC ( B kehrt zu ASCII zurück; ESC ( J wählt JIS X 0201 Roman.
Diese Folgen sind keine Metadaten neben dem Körper. Sie sind Teil des Körpers und ändern eine laufende Variable. Zwei Werte bilden nur dann ein japanisches Zeichen, wenn der letzte gültige Bezeichner den Doppelbytezustand geöffnet hat. Nach dem ASCII-Rücksprung besitzt dieselbe Folge eine andere Bedeutung. Der Decoder braucht also Vorgeschichte.
Auch die Einzelbytezustände sind nicht deckungsgleich. JIS X 0201 Roman ersetzt an zwei Positionen Backslash und Tilde durch Yen-Zeichen und Überstrich. Eine lokale Schrift kann das verdecken, ohne die Kodierungsdifferenz aufzuheben. Der Kana-Satz von JIS X 0201 ist ausdrücklich ausgeschlossen. Aus „JP“ durfte kein Empfänger zusätzliche lokale Zustände erraten.
Die formale Syntax reserviert ESC, SI und SO und nimmt sie von gewöhnlichen Einzelbytezeichen aus. Steuerung und Nutzzeichen bleiben dadurch getrennt. Der öffentliche Name ist zuverlässig, weil er eine kleine Maschine benennt, nicht weil er eine große kulturelle Kategorie bezeichnet.
Die Zeilengrenze begrenzte Erinnerung
Enthält eine Zeile JIS-X-0208-Zeichen, muss sie vor CRLF zu ASCII oder JIS X 0201 Roman wechseln. Die nächste Zeile beginnt im zuvor gewählten Einzelbytezustand. Der gesamte Text muss in ASCII enden.
Die Wiederholung von Escape-Folgen ist absichtliche Redundanz. Sie macht spätere Zeilen mit einer kurzen Vorgeschichte lesbar. Ein Zitierprogramm kann am neuen Zeilenanfang > einfügen, ohne es zur Hälfte eines Doppelbytezeichens zu machen. Ein Viewer kann in der Mitte beginnen, ohne vom Dokumentanfang an jeden Zustand nachzuvollziehen. Eine beschädigte Zeile muss ihren Doppelbytezustand nicht unbegrenzt vererben.
Vollständige Selbstsynchronisation ist das nicht. Ein Rücksprung nach JIS X 0201 Roman lässt die beiden Abweichungen zu ASCII bestehen, und für beschädigte Escape-Folgen können Decoder unterschiedliche Fehlerregeln verwenden. Doch der gefährlichste Zustand darf die Zeile nicht still überschreiten. CRLF erhält damit neben seiner typografischen eine semantische Grenzfunktion.
Das ist eine Form minimaler Spezifikation: Sie verlangt von gemeinsamen Komponenten genau die Grenze, die unabhängige Implementierungen wieder zusammenführt, und nicht die Vereinheitlichung jeder lokalen Darstellung.
Sieben Bit waren keine Integritätsgarantie
Das MIME-Beispiel lautet Content-Type: text/plain; charset=iso-2022-jp. Da sämtliche Werte siebenbittig sind, ist keine zusätzliche Transferkodierung nötig, nur um den alten Transportbereich einzuhalten.
Ein Relay kann den Inhalt dennoch zerstören, ohne ein einziges Acht-Bit-Byte zu erzeugen. Es genügt, ESC zu entfernen, einen Bezeichner zu ersetzen, ein Doppelbytepaar zu trennen oder Zeilenenden umzuschreiben. Die Zulässigkeit eines Bytewerts und seine Funktion in der Sequenz sind getrennte Eigenschaften.
RFC 1468 warnte, Base64 oder quoted-printable machten Nachrichten in der damaligen JUNET-Software unlesbar. Der historische Bezug ist entscheidend. Korrekt angewandt und umgekehrt können solche Verfahren die Ursprungsbytes bewahren. Unbrauchbar war die Kombination, wenn laufende Clients die äußere MIME-Schicht nicht entfernten, bevor sie das innere Charset decodierten. Reversible Spezifikation war noch keine installierte Fähigkeit.
Der spätere RFC 2046 bezeichnete den Charset-Parameter für MIME-Text als kritisch und hielt an Zeilenregeln fest. Das Feld gibt an, aus welchem Charset der Körper bestehen soll. Es protokolliert nicht, dass jedes Glied des Pfads dies korrekt verarbeitet hat.
Ein Relay durfte seine Sicht nicht verewigen
Einige Systeme unterschieden laut RFC 1468 bei der Anzeige weder ESC ( B und ESC ( J noch ESC $ @ und ESC $ B. Trotzdem mussten Relays die Escape-Folgen exakt erhalten.
Lokale Anzeigegleichheit schafft keine übertragbare Identität. Eine andere Schrift kann Yen und Backslash trennen. Ein späterer Konverter kann zwischen JIS-X-0208-Fassungen unterscheiden. Ein Archiv braucht womöglich das empfangene Objekt, nicht die hübscheste Normalform. Dass der aktuelle Vermittler eine Differenz nicht nutzt, verleiht ihm keine Befugnis, sie für alle Nachfolger zu löschen.
Bytegetreue Verwahrung hält außerdem die Fehlerquelle sichtbar. Bei einem unerwarteten Zeichen lassen sich Senderstrom, Relay-Kopie, Decoderergebnis und Schriftbild vergleichen. Eine gut gemeinte Normalisierung mischt diese Ebenen. Sie kann die lokale Lesbarkeit verbessern und gleichzeitig die Beweiskraft verschlechtern.
Das macht das Relay nicht zum Wahrheitsgaranten. Unveränderte Bytes können falsch deklariert oder inhaltlich unwahr sein. Die Verpflichtung ist enger: Der Vermittler soll seine Interpretation nicht in das fremde Objekt zurückschreiben.
Eine Zeile hatte mehrere Koordinaten
Der RFC empfahl etwa 75 bis 80 sichtbare Spalten, damit beim Zitieren Platz für ein zusätzliches Zeichen blieb. Ein JIS-X-0208-Zeichen zählte in seinem Modell als zwei Bytes und zwei Spalten; eine Escape-Folge verbrauchte Bytes, aber keine Spalte. Beim Umbruch durfte ein Doppelbytezeichen nicht geteilt werden.
Byteoffset, Zeichenposition und Anzeigespalte können sich daher auseinanderentwickeln. In einem ASCII-Abschnitt scheinen sie gleichzulaufen, nach dem ersten Bezeichner nicht mehr. Am achtzigsten Byte abzuschneiden ist kein Umbruch an der achtzigsten Spalte. Unsichtbare Steuerwerte vor der Validierung zu entfernen kann ausgerechnet die Erklärung der sichtbaren Werte löschen.
Ein Hash belegt die Identität einer Repräsentation, nicht die Schriftwahl. Ein Screenshot belegt eine konkrete Anzeige, nicht die ursprünglichen Bytes. Beide Belege sind nötig, wenn der Übergang nachvollziehbar bleiben soll.
Registriert wurde ein Konvertierungsvertrag
RFC 2978 definierte Charset später als Methode, eine Folge von Oktetten in Zeichen umzuwandeln, ausdrücklich einschließlich komplexer ISO-2022-Umschaltungen. Die Definition eines Namens muss die Abbildung vollständig bestimmen und darf kein verborgenes externes Profil voraussetzen.
Das heutige IANA Character Sets Registry führt ISO-2022-JP als Nummer 39 mit Verweisen auf RFC 1468 und RFC 2237; ISO-2022-JP-2 steht getrennt unter Nummer 40. Das Register stabilisiert den Wortschatz. Es untersucht keine Nachricht, zertifiziert keinen Decoder und misst keine heutige Verbreitung.
Die RFC-Editor-Metadaten weisen RFC 1468 als Informational aus, nicht als Internet Standard. Das sagt nichts gegen die dokumentierte historische Nutzung. Umgekehrt macht die IANA-Registrierung nicht jede entsprechend etikettierte Nachricht konform. Publikationsstatus, Namenskoordination und laufendes Verhalten brauchen je eigene Belege.
Größere Maschinen bekamen andere Namen
RFC 1554 beschrieb im Dezember 1993 die experimentelle mehrsprachige Erweiterung ISO-2022-JP-2. Chinesische, koreanische, ergänzende japanische, lateinische und griechische Bezeichner kamen hinzu, ebenso ein weiterer Zustandsbereich mit zeilenweiser Rücksetzung. Die zusätzliche Decoderpflicht wurde im MIME-Namen sichtbar.
1997 definierte RFC 2237 ISO-2022-JP-1 für JIS X 0212 mit ESC $ ( D. Der Text musste weiterhin in ASCII enden; ohne Zeichen des Ergänzungssatzes sollte das gewöhnliche ISO-2022-JP verwendet werden.
Ein neuer Name lässt alte Empfänger ehrlich ablehnen, statt unbekannte Zustände unter einem vertrauten Etikett erraten zu müssen. Erweiterbarkeit und die stabile Bedeutung alter Archive wurden nicht gegeneinander ausgespielt.
Vor der Wahrnehmung endet die Norm
Die Quellen beschreiben einen konformen Strom. Sie beweisen nicht, was eine konkrete Person sah. MIME-Feld, Originalbytes, Zustandsübergänge, Relay-Transformationen, Decoderversion, Zeichenfolge, Font und gerenderte Ausgabe müssen getrennt bleiben.
Die veröffentlichten Texte von Heng Lu schärfen diese Grenze. Minimum Initial Specification erklärt, wie ein kleiner gemeinsamer Kern lokale Entscheidungen ermöglicht. Running-Code Primacy trennt veröffentlichte Spezifikation und ausgeführten Code. On Reality Layers verhindert, dass Name, Bytes, Darstellung und menschliche Reaktion zu einer symbolischen Tatsache verschmelzen.
RFC 1468 war stark, weil es diese Ebenen nicht zu beherrschen vorgab. Der Name wählte die Regel, Escape-Folgen wählten den Zustand, Zeilen begrenzten seine Reichweite, Relays bewahrten das Objekt und Endpunkte führten die Interpretation aus. So konnte ein Pfad, der kein Japanisch verstand, japanische Mail tragen.
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
