UTF-7 - UTF-7

UTF-7

Sprachen)	International
Standard	RFC  2152
Einstufung	Unicode Transformation Format , ASCII Armor , Codierung mit variabler Breite , Stateful Codierung
Transformiert / Codiert	Unicode
Vorangestellt	HZ-GB-2312
gefolgt von	UTF-8 über 8BITMIME
v T e

UTF-7 (7- Bit- Unicode-Transformationsformat ) ist eine veraltete Zeichencodierung mit variabler Länge zur Darstellung von Unicode- Text unter Verwendung eines ASCII- Zeichenstroms. Es war ursprünglich dazu gedacht, ein Mittel zum Codieren von Unicode- Text für die Verwendung in Internet- E-Mail- Nachrichten bereitzustellen , das effizienter war als die Kombination von UTF-8 mit quoted-printable .

UTF-7 (laut RFC) ist kein „ Unicode Transformation Format “, da die Definition nur Codepunkte im BMP codieren kann (die ersten 65536 Unicode-Codepunkte, die keine Emojis und viele andere Zeichen enthalten). Wenn jedoch ein UTF-7-Übersetzer zu/von UTF-16 ist, kann er (und tut es wahrscheinlich) jede Ersatzhälfte so codieren, als ob es ein 16-Bit-Codepunkt wäre, und kann somit alle Codepunkte codieren. Es ist unklar, ob andere UTF-7-Software (wie Übersetzer zu UTF-32 oder UTF-8) dies unterstützt.

UTF-7 war nie ein offizieller Standard des Unicode-Konsortiums . Es ist bekannt, dass es Sicherheitsprobleme hat, weshalb die Software geändert wurde, um die Verwendung zu deaktivieren. Es ist in HTML 5 verboten .

Motivation

MIME , der moderne Standard für das E-Mail-Format, verbietet die Codierung von Headern mit Bytewerten oberhalb des ASCII-Bereichs. Obwohl MIME die Codierung des Nachrichtentexts in verschiedenen Zeichensätzen (weiter als ASCII) ermöglicht, kann die zugrunde liegende Übertragungsinfrastruktur ( SMTP , der wichtigste E-Mail-Übertragungsstandard) immer noch nicht garantiert 8-Bit-sauber sein . Daher muss im Zweifelsfall eine nicht triviale Content-Transfer-Codierung angewendet werden. Leider hat base64 den Nachteil, dass selbst US-ASCII- Zeichen in Nicht-MIME-Clients unlesbar sind. Andererseits erzeugt UTF-8 in Kombination mit Quoted-Printable ein sehr größenineffizientes Format, das 6–9 Byte für Nicht-ASCII-Zeichen aus dem BMP und 12 Byte für Zeichen außerhalb des BMP erfordert .

Sofern bei der Kodierung bestimmte Regeln befolgt werden, kann UTF-7 in E-Mail gesendet werden, ohne eine zugrunde liegende MIME- Übertragungskodierung zu verwenden, muss aber dennoch explizit als Textzeichensatz identifiziert werden. Darüber hinaus muss UTF-7 bei Verwendung in E-Mail-Headern wie "Betreff:" in MIME- codierten Wörtern enthalten sein , die den Zeichensatz identifizieren. Da codierte Wörter die Verwendung von quoted-printable oder base64 erzwingen , wurde UTF-7 entwickelt, um die Verwendung des = -Zeichens als Escape-Zeichen zu vermeiden, um doppeltes Escaping zu vermeiden, wenn es mit Quoted-Printable (oder seiner Variante, dem RFC 2047/1522) kombiniert wird ?Q?-Codierung von Headern).

UTF-7 wird im Allgemeinen nicht als native Darstellung innerhalb von Anwendungen verwendet, da es sehr umständlich zu verarbeiten ist. Trotz seines Größenvorteils gegenüber der Kombination von UTF-8 mit Quoted-Printable oder base64 empfahl das inzwischen aufgelöste Internet Mail Consortium von dessen Verwendung.

8BITMIME wurde ebenfalls eingeführt, wodurch die Notwendigkeit reduziert wird, Nachrichtentexte in ein 7-Bit-Format zu codieren.

Eine modifizierte Form von UTF-7 (manchmal auch 'mUTF-7' genannt) wird derzeit im IMAP- E-Mail -Abrufprotokoll für Mailbox-Namen verwendet.

Beschreibung

UTF-7 wurde erstmals als experimentelles Protokoll in RFC 1642, A Mail-Safe Transformation Format of Unicode, vorgeschlagen . Dieser RFC wurde durch RFC 2152 obsolet, ein Informations-RFC, der nie zum Standard wurde. Wie RFC 2152 klar feststellt, spezifiziert der RFC „keinen Internetstandard irgendeiner Art“. Trotzdem wird RFC 2152 als Definition von UTF-7 in der Zeichensatzliste der IANA zitiert. UTF-7 ist auch kein Unicode-Standard. Der Unicode-Standard 5.0 listet nur UTF-8, UTF-16 und UTF-32 auf. Es gibt auch eine modifizierte Version, spezifiziert in RFC 2060, die manchmal als UTF-7 bezeichnet wird.

Einige Zeichen können direkt als einzelne ASCII-Bytes dargestellt werden. Die erste Gruppe ist als "Direktzeichen" bekannt und enthält 62 alphanumerische Zeichen und 9 Symbole: ' ( ) , - . / : ?. Die direkten Zeichen sind buchstäblich sicher einzuschließen. Die andere Hauptgruppe, bekannt als "optionale direkte Zeichen", enthält alle anderen druckbaren Zeichen im Bereich U+ 0020 –U+007E außer ~ \ +und Leerzeichen (die Zeichen \und ~werden aufgrund der Neudefinition in "ASCII-Varianten" wie JIS- Römer ). Die Verwendung der optionalen Direktzeichen verringert die Größe und verbessert die Lesbarkeit für den Menschen, erhöht aber auch die Wahrscheinlichkeit eines Bruchs durch Dinge wie schlecht gestaltete Mail-Gateways und kann zusätzliche Escape-Zeichen erfordern, wenn sie in codierten Wörtern für Header-Felder verwendet werden.

Leerzeichen, Tabulator, Wagenrücklauf und Zeilenvorschub können auch direkt als einzelne ASCII-Bytes dargestellt werden. Wenn der codierte Text jedoch in E-Mail verwendet werden soll, ist darauf zu achten, dass diese Zeichen so verwendet werden, dass keine weitere Codierung zur Inhaltsübertragung erforderlich ist, um für E-Mail geeignet zu sein. Das Pluszeichen ( +) kann als codiert werden +-.

Andere Zeichen müssen in UTF-16 kodiert werden (daher würden U+10000 und höher in zwei Ersatzzeichen kodiert) und dann in modifiziertem Base64 . Der Beginn dieser Blöcke von modifiziertem Base64-codiertem UTF-16 wird durch ein +Zeichen angezeigt . Das Ende wird durch ein beliebiges Zeichen angezeigt, das nicht im modifizierten Base64-Set enthalten ist. Wenn das Zeichen nach dem modifizierten Base64 ein -(ASCII- Bindestrich-Minus ) ist, wird es vom Decoder verbraucht und die Decodierung wird mit dem nächsten Zeichen fortgesetzt. Andernfalls wird die Dekodierung mit dem Zeichen nach base64 fortgesetzt.

Beispiele

• " Hello, World!" ist codiert als " Hello, World+ACE-"
• " 1 + 1 = 2" ist codiert als " 1 +- 1 +AD0- 2"
• " £1" wird als " +AKM-1" codiert . Der Unicode-Codepunkt für das Rautezeichen ist U+00A3, der wie in der Tabelle unten gezeigt in modifiziertes Base64 konvertiert wird. Es bleiben zwei Bits übrig, die auf 0 aufgefüllt werden.

Hex-Ziffer	0				0				EIN				3
Bitmuster	0	0	0	0	0	0	0	0	1	0	1	0	0	0	1	1	0	0
Index	0						10						12
Base64-kodiert	EIN						K						m

Algorithmus zum Kodieren und Dekodieren

Codierung

Zunächst muss ein Encoder entscheiden, welche Zeichen direkt im ASCII-Format dargestellt werden sollen, welche +als Escapezeichen verwendet werden +-müssen und welche in Blöcken von Unicode-Zeichen platziert werden sollen. Ein einfacher Kodierer kann alle Zeichen kodieren, die er für eine direkte Kodierung als sicher erachtet. Die Kosten für das Beenden einer Unicode-Sequenz, die Ausgabe eines einzelnen Zeichens direkt in ASCII und das anschließende Starten einer anderen Unicode-Sequenz betragen jedoch 3 bis 3+2 ⁄ 3 Byte. Das ist mehr als die 2+2 ⁄ 3 Byte werden benötigt, um das Zeichen als Teil einer Unicode-Sequenz darzustellen. Jede Unicode-Sequenz muss mit dem folgenden Verfahren codiert und dann von den entsprechenden Trennzeichen umgeben werden.

Am Beispiel der Zeichenfolge £† (U+00A3 U+2020):

Dekodierung

Zuerst müssen codierte Daten in einfache ASCII- Textblöcke (einschließlich + es gefolgt von einem Bindestrich) und nicht leere Unicode-Blöcke getrennt werden, wie im Beschreibungsabschnitt erwähnt. Sobald dies erledigt ist, muss jeder Unicode-Block mit dem folgenden Verfahren decodiert werden (unter Verwendung des Ergebnisses des obigen Codierungsbeispiels als unser Beispiel):

1. Drücken Sie jeden Base64-Code als die Bitsequenz aus, die er repräsentiert:
   AKMgIA → 000000 001010 001100 100000 001000 000000
2. Gruppieren Sie die Binärdatei neu in Gruppen von sechzehn Bits, beginnend von links:
   000000 001010 001100 100000 001000 000000 → 0000000010100011 0010000000100000 0000
3. Wenn am Ende eine unvollständige Gruppe nur Nullen enthält, verwerfen Sie diese (wenn die unvollständige Gruppe Einsen enthält, ist der Code ungültig):
   0000000010100011 0010000000100000
4. Jede Gruppe von 16 Bit ist die Unicode (UTF-16)-Zahl eines Zeichens und kann in anderen Formen ausgedrückt werden:
   0000 0000 1010 0011 ≡ 0x00A3 ≡ 163 ₁₀

Byte-Reihenfolge-Marke

Eine Byte-Reihenfolge-Markierung (BOM) ist eine optionale spezielle Byte-Sequenz ganz am Anfang eines Streams oder einer Datei, die, ohne selbst Daten zu sein, die Codierung angibt, die für die folgenden Daten verwendet wird; es kann verwendet werden, wenn Metadaten fehlen, die die Kodierung angeben. Für ein bestimmtes Codierungsschema ist es die Darstellung des Unicode-Codepoints durch dieses Schema U+FEFF.

Während es in der Regel eine einzige, feste Bytefolge ist, in UTF-7 vier Variationen können auftreten, da die letzten 2 Bits der 4 Bytes der UTF-7 - Codierung von U+FEFFgehören in den folgenden Charakter, in 4 möglichen Bitmustern und damit zu 4 verschiedene mögliche Bytes an der 4. Stelle. Siehe den UTF-7-Eintrag in der Tabelle der Unicode-Byte-Reihenfolgemarkierungen .

Sicherheit

UTF-7 ermöglicht mehrere Darstellungen derselben Quellzeichenfolge. Insbesondere können ASCII-Zeichen als Teil von Unicode-Blöcken dargestellt werden. Wenn also Standard-ASCII-basierte Escape- oder Validierungsprozesse für Zeichenfolgen verwendet werden, die später als UTF-7 interpretiert werden können, können Unicode-Blöcke verwendet werden, um bösartige Zeichenfolgen daran vorbeizuschieben. Um dieses Problem zu mildern, sollten Systeme vor der Validierung eine Dekodierung durchführen und den Versuch vermeiden, UTF-7 automatisch zu erkennen.

Ältere Versionen von Internet Explorer können dazu verleitet werden, die Seite als UTF-7 zu interpretieren. Dies kann für einen Cross-Site-Scripting- Angriff verwendet werden, da die <und >Markierungen als +ADw-und +AD4-in UTF-7 codiert werden können , was die meisten Validatoren als einfachen Text durchlassen.

UTF-7 gilt zumindest für Microsoft-Software (.NET) als veraltet, wobei Codepfade es zuvor absichtlich in .NET 5 im Jahr 2020 unterstützt haben (um Sicherheitsprobleme zu vermeiden).

Verweise

Siehe auch

• Vergleich von Unicode-Kodierungen