UTF-7 (Unicode 7-Bit-Transformationsformat) ist ein Charakter der variablen Länge, der verschlüsselt, der vorgeschlagen wurde, für Text von Unicode mit einem Strom von ASCII Charakteren zu vertreten. Es war ursprünglich beabsichtigt, um ein Mittel zur Verfügung zu stellen, Text von Unicode für den Gebrauch in InternetE-Mail-Nachrichten zu verschlüsseln, der effizienter war als die Kombination von UTF-8 mit dem angesetzten - druckfähig.

Motivation

PANTOMIME, der moderne Standard des E-Mail-Formats, verbietet Verschlüsselung von Kopfbällen mit Byte-Werten über der ASCII-Reihe. Obwohl PANTOMIME erlaubt, den Nachrichtenkörper in verschiedenen Codierungen zu verschlüsseln (breiter als ASCII), wie man noch immer nicht versichert, ist die zu Grunde liegende Übertragungsinfrastruktur (SMTP, der HauptE-Mail-Übertragungsstandard) saubere 8 Bit. Deshalb muss eine nichttriviale zufriedene Übertragungsverschlüsselung im Falle Zweifel angewandt werden. Leider hat base64 einen Nachteil des Bildens sogar von in Nichtpantomime-Kunden unlesbaren Charakteren des US-ASCII. Andererseits erzeugt UTF-8, der mit dem angesetzten verbunden ist - druckfähig ein sehr mit der Größe ineffizientes Format, das 6-9 Bytes für non-ASCII Charaktere vom BMP und 12 Bytes für Charaktere außerhalb des BMP verlangt.

Vorausgesetzt dass bestimmten Regeln während der Verschlüsselung gefolgt wird, kann UTF-7 in der E-Mail gesandt werden, ohne eine zu Grunde liegende PANTOMIME-Übertragungsverschlüsselung zu verwenden, aber muss noch als die Textcodierung ausführlich identifiziert werden. Außerdem, wenn verwendet, innerhalb von E-Mail-Kopfbällen wie "Thema:" UTF-7 muss in verschlüsselten Wörtern der PANTOMIME enthalten werden, die die Codierung identifizieren. Da verschlüsselte Wörter Gebrauch entweder angesetzten - druckfähig oder base64 zwingen, wurde UTF-7 entworfen, um zu vermeiden, = Zeichen als ein Flucht-Charakter zu verwenden, um das doppelte Entgehen zu vermeiden, wenn es mit dem angesetzten - druckfähig verbunden wird (oder seine Variante, der RFC 2047/1522? Q? - Verschlüsselung von Kopfbällen).

UTF-7 wird allgemein als eine heimische Darstellung innerhalb von Anwendungen nicht verwendet, weil es sehr ungeschickt ist, um in einer Prozession zu gehen. Trotz seines Größe-Vorteils gegenüber der Kombination von UTF-8 entweder mit angesetztem - druckfähig oder mit base64 empfiehlt das Internetpostkonsortium gegen seinen Gebrauch.

8BITMIME ist auch eingeführt worden, der das Bedürfnis reduziert, Nachrichtenkörper in einem 7-Bit-Format zu verschlüsseln.

Eine modifizierte Form von UTF-7 wird zurzeit im IMAP-E-Mail-Wiederauffindungsprotokoll für Briefkasten-Namen verwendet.

Beschreibung

UTF-7 wurde zuerst als ein experimentelles Protokoll RFC 1642, Ein Postsicheres Transformationsformat von Unicode vorgeschlagen. Dieser RFC ist veraltet durch RFC 2152, ein Informations-RFC gemacht worden, der nie ein Standard geworden ist. Als RFC 2152 klar Staaten gibt der RFC "keinen Internetstandard keiner Art an". Trotz dieses RFC 2152 wird als die Definition von UTF-7 in der Liste des IANA von charsets angesetzt. Keiner ist UTF-7 ein Unicode Standard. Die Unicode Normalen 5.0 nur Listen UTF-8, UTF-16 und UTF-32.

Es gibt auch eine modifizierte Version, angegeben RFC 2060, der manchmal als UTF-7 identifiziert wird.

Einige Charaktere können direkt als einzelne ASCII Bytes vertreten werden. Die erste Gruppe ist als "direkte Charaktere" bekannt und enthält 62 alphanumerische Charaktere und 9 Symbole:. Die direkten Charaktere sind sicher, wörtlich einzuschließen. Die andere Hauptgruppe, die als "fakultative direkte Charaktere bekannt ist," enthält alle anderen druckfähigen Charaktere in der Reihe-u+007e außer und dem Raum. Das Verwenden der fakultativen direkten Charaktere reduziert Größe und erhöht menschliche Lesbarkeit sondern auch vergrößert die Chance der Brechung durch Dinge wie schlecht bestimmte Posttore und kann das Extraentgehen, wenn verwendet, in verschlüsselten Wörtern für Kopfball-Felder verlangen.

Raum, Etikett, Wagen-Rückkehr und Linienfutter können auch direkt als einzelne ASCII Bytes vertreten werden. Jedoch, wenn der verschlüsselte Text in der E-Mail verwendet werden soll, ist Sorge erforderlich, um sicherzustellen, dass diese Charaktere auf Weisen verwendet werden, die nicht verlangen, dass weitere zufriedene Übertragungsverschlüsselung für die E-Mail passend ist. Das Pluszeichen kann als verschlüsselt werden.

Andere Charaktere müssen in UTF-16 verschlüsselt werden (folglich U+10000, und würde höher in Stellvertreter verschlüsselt), und dann in modifiziertem Base64. Der Anfang dieser Blöcke von modifiziertem Base64 hat UTF-16 verschlüsselt wird durch ein Zeichen angezeigt. Das Ende wird durch jeden Charakter nicht im modifizierten Base64-Satz angezeigt. Wenn der Charakter nach dem modifizierten Base64 ist (ASCII Bindestrich - minus) dann wird es durch den Decoder und die decodierenden Zusammenfassungen mit dem folgenden Charakter verbraucht. Sonst decodierende Zusammenfassungen mit dem Charakter nach dem base64.

Verwirrend nennt Microsoft in seiner.NET Dokumentation seine LEB128-Schnur-Länge, die UTF-7 verschlüsselt: "Eine Länge-vorfeste Schnur vertritt die Schnur-Länge durch das Vorbefestigen zur Schnur eines einzelnen Bytes oder Wortes, das die Länge dieser Schnur enthält. Diese Methode schreibt zuerst die Länge der Schnur, wie ein UTF-7 nicht unterzeichnete ganze Zahl verschlüsselt hat, und dann dass viele Charaktere dem Strom durch das Verwenden der Beispiel-Strom-Verschlüsselung von BinaryWriter schreibt." Der Begleitbeispiel-Code zeigt jedoch, dass statt UTF-7 wenig-endian zu LEB128 identische Menge der Variablen Länge verwendet wird; und das tatsächlich die Zählung ist eine Byte-Zählung und nicht eine Charakter-Zählung.

Beispiele

• "" wird als "" verschlüsselt

"" wird als "" verschlüsselt

• "" wird als "" verschlüsselt. Der Unicode-Codepunkt für das Pfund-Zeichen ist U+00A3 (der in UTF-16 ist), der sich zu modifiziertem Base64 als im Tisch unten umwandelt. Es gibt zwei Bit verlassen zu Ende, die zu 0 ausgepolstert werden.

Algorithmus, um zu verschlüsseln und zu decodieren

Verschlüsselung

Erstens muss ein encoder entscheiden, welche Charaktere, direkt in der ASCII-Form zu vertreten, als die entkommen werden muss, und welch man in Blöcke von Charakteren von Unicode legt. Ein einfacher encoder kann alle Charaktere verschlüsseln, die er als sicher für die direkte Verschlüsselung direkt betrachtet. Jedoch sind die Kosten, eine Folge von Unicode, outputing ein einzelner Charakter direkt in ASCII zu beenden und dann eine andere Folge von Unicode anzufangen, 3 zu 3⅔ Bytes. Das ist mehr, als die 2⅔ Bytes den Charakter als ein Teil einer Folge von Unicode vertreten mussten. Jede Unicode Folge muss mit dem folgenden Verfahren verschlüsselt werden, das dann durch die passenden Begrenzungszeichen umgeben ist.

Das Verwenden des £ + (U+00A3 U+2020) Charakter-Folge als ein Beispiel:

</ol>

Entzifferung

Zuerst müssen verschlüsselte Daten in ASCII einfache Textklötze (einschließlich +es getrennt werden, der von einer Spur gefolgt ist) und nichtleere Blöcke von Unicode, wie erwähnt, in der Beschreibungsabteilung. Sobald das getan wird, muss jeder Block von Unicode mit dem folgenden Verfahren decodiert werden (das Ergebnis des Verschlüsselungsbeispiels oben als unser Beispiel verwendend)

,

1. Drücken Sie jeden Base64-Code als die Bit-Folge aus, die er vertritt:
2. Gruppieren Sie die Dualzahl in Gruppen von sechzehn Bit um, vom links anfangend:
3. Wenn es eine unvollständige Gruppe am Ende gibt, verwerfen Sie es (Wenn die unvollständige Gruppe mehr als vier Bit enthält oder irgendwelche enthält, ist der Code ungültig):
4. Jede Gruppe von 16 Bit ist Unicode eines Charakters (UTF-16) Zahl und kann in anderen Formen ausgedrückt werden:

Sicherheit

UTF-7 erlaubt vielfache Darstellungen derselben Quellschnur. In besonderen ASCII Charakteren kann als ein Teil von Blöcken von Unicode vertreten werden. Als solcher, wenn normaler ASCII Entgehen- oder Gültigkeitserklärungsprozesse gestützt hat, werden auf Schnuren verwendet, die später als UTF-7 dann interpretiert werden können, können Blöcke von Unicode verwendet werden, um böswillige Schnuren vorbei an ihnen gleiten zu lassen. Um dieses Problem zu lindern, sollten Systeme Entzifferung vor der Gültigkeitserklärung durchführen und sollten vermeiden zu versuchen, UTF-7 zu autoentdecken.

Ältere Versionen von Internet Explorer können in die Interpretation der Seite als UTF-7 beschwindelt werden. Das kann für eine Quer-Seite scripting Angriff als verwendet werden, und Zeichen können als und in UTF-7 verschlüsselt werden, bis den die meisten validators als einfacher Text lassen.

Siehe auch

• Vergleich von Unicode encodings