Zusammenfassung

  • RFC 2152 öffnete mit + eine Modified-Base64-Sequenz ohne =-Padding über 16-Bit-Unicode-Größen in Big-Endian-Reihenfolge; sie endete vor einem Zeichen außerhalb des Alphabets und durfte nie einen Zeilenumbruch kreuzen.
  • Set-O-Zeichen durften trotz Gateway-Risiko direkt bleiben, und jede Unicode-Sequenz durfte verschoben werden. Erfolgreiches Decodieren belegte Zeichen, nicht ursprüngliche UTF-7-Bytes, Zeilengrenzen, Transitweg oder Autorenabsicht.

Bei einer Archivmigration überlebt oft zuerst das Sichtbare. Lateinische Betreffzeilen erscheinen lesbar, UTF-7-Fragmente lassen sich öffnen. Ersetzt die Unicode-Projektion jedoch das Rohobjekt, ist später nicht mehr feststellbar, welche Satzzeichen direkt reisten, welches Gateway Zeilen neu setzte oder welche Bytes signiert waren.

David Goldsmith und Mark Davis veröffentlichten RFC 2152 im Mai 1997 als Informational-Dokument und Ersatz für RFC 1642. Es war kein Internet Standard. Sieben-Bit-US-ASCII dominierte den Mailpfad; UTF-8 plus MIME-Transfercodierung konnte zwei Transformationen und starke Expansion für Nicht-ASCII-Text bedeuten. UTF-7 erzeugte ausschließlich ASCII-Oktette und ließ ASCII-Anteile lesbar.

Das Dokument beschränkte den Einsatz ausdrücklich auf Sieben-Bit-Transporte wie Mail; anderswo waren direktes Unicode oder UTF-8 vorzuziehen.

Direkt war keine einheitliche Schutzklasse

Set D enthielt Buchstaben, Ziffern und neun direkte Sonderzeichen, jedoch nicht + und =. Set O durfte optional direkt codiert werden. RFC 2152 warnte zugleich, dass viele dieser Zeichen in Headern illegal waren oder manche Gateways nicht korrekt passierten. Backslash und Tilde fehlten, weil ASCII-Varianten sie oft neu belegten.

Anhang A zeigte denselben chinesischen Text zweimal. Die Fassung mit optionalem Set O war lesbarer, konnte aber an Gateways scheitern; die zweite vermied diese Wahl. Sichtbarkeit war ein lokaler Vorteil, keine Transportquittung.

Das Pluszeichen öffnete Zustand

Nach + galt das Base64-Alphabet aus RFC 2045 ohne =. Ein Zeichen außerhalb von Set B beendete die Sequenz. Ein terminierendes wurde verbraucht; +- stand für ein wörtliches Plus. Folgte auf Plus sofort weder Set B noch Bindestrich, war die Folge fehlerhaft.

Zuvor wurden 16-Bit-Unicode-Größen mit dem höchstwertigen Oktett zuerst serialisiert. Die Hälften eines UTF-16-Surrogatpaars galten als getrennte Größen. Eine ungerade Oktettzahl war ungültig; unvollständige Restbits durften nur verworfen werden, wenn sie null waren.

Diese Grammatik prüft Syntax, nicht Herkunft. Hi Mom +Jjo-! liefert bei intaktem Eingang ein Lächeln. Es belegt weder die ursprüngliche Encoderwahl noch unveränderte Relays oder die Darstellung beim Autor.

Der Zeilenrand schloss den Korridor

Eine Shift-Sequenz endete stets am Zeilenende und durfte es nicht überschreiten. Deshalb musste der Umbruch vor oder gemeinsam mit der UTF-7-Codierung erfolgen. War die Ausgabe danach zu lang, verlangte sie eine geeignete MIME content-transfer encoding statt eines Schnitts im Block.

RFC 2152 empfahl kurze SMTP-Zeilen mit CRLF und die Umwandlung von Unicode-Zeilen- und Absatztrennern, um Altgeräte lesbarer zu bedienen. Das konnte interoperabel korrekt sein und trotzdem die Ursprungsfolge verändern. Betriebliche Normalisierung ist keine Byte-Verwahrung.

Decodieren faltet verschiedene Vorgeschichten zusammen

Regel 2 erlaubte jede Unicode-Sequenz im Shift-Modus; Regeln 1 und 3 ließen ausgewählte Zeichen direkt. Verschiedene UTF-7-Ströme konnten daher dasselbe Unicode-Ergebnis liefern. Der Decoder erfüllte seine Textaufgabe, auch wenn er diese Wahlgeschichte verwarf.

Abnahme braucht getrennte Belege: Rohbytes und Zeilenenden, striktes Syntaxurteil, Unicode-Einheiten und Clientdarstellung. Für Signaturen, Forensik oder Streitfälle müssen Rohobjekt und Hashes jeder Grenze erhalten bleiben.

IANA führt UTF-7, MIBenum 1012 und csUTF7. Das belegt den Namen, nicht Einführung oder Sicherheit. UTF-7-IMAP ist ein anderes, auf IMAP-Mailboxnamen beschränktes Verfahren und soll außerhalb dieses Kontexts nie verwendet werden.

RFC 2152 diskutierte Sicherheit nicht. Spätere Unicode-Hinweise erklären Gefahren unterschiedlicher Vergleiche und Transformationen, weisen heute aber darauf hin, dass UTR 36 stabilisiert und teilweise überholt ist. Weder Schweigen noch Warnung ersetzen Produktmessung.

Zwei Errata sind verified: Wert 96 bezeichnet den Grave Accent, und im Satz über das Zeilenende fehlte ein Wort. Ein dritter Vorschlag wurde rejected. Der Status ist Teil des Belegs.

Heng Lus Prinzip der Mindestspezifikation ordnet UTF-7 als enge gemeinsame Grammatik ein. Running-Code Primacy verlangt die Beobachtung des wirklichen Gateways; Reality Layers verbietet, Charset-Label oder Lesbarkeit zum ausgeführten Verwahrergebnis aufzuwerten.

Quellen