ASCII85 - Ascii85

Ascii85 , auch Base85 genannt , ist eine Form der Binär-zu-Text-Codierung, die von Paul E. Rutter für das Dienstprogramm btoa entwickelt wurde . Durch die Verwendung von fünf ASCII- Zeichen zur Darstellung von vier Bytes binärer Daten (wodurch die codierte Größe 1 ⁄ 4 größer als das Original ist, unter der Annahme von acht Bits pro ASCII-Zeichen), ist es effizienter als uuencode oder Base64 , die vier Zeichen verwenden, um drei Bytes darzustellen der Daten ( Anstieg um 1 ⁄ 3 , unter der Annahme von acht Bits pro ASCII-Zeichen).

Seine wichtigsten modernen Anwendungen sind in Adobe ‚s PostScript- und Portable Document Format Dateiformate sowie in der Patch - Codierung für binäre Dateien durch verwendet Git .

Überblick

Die grundlegende Notwendigkeit für eine Binär-zu-Text-Codierung ergibt sich aus der Notwendigkeit, beliebige Binärdaten über bereits existierende Kommunikationsprotokolle zu übertragen, die nur für den Menschen lesbaren Text in englischer Sprache transportieren sollen . Diese Kommunikationsprotokolle sind möglicherweise nur 7-Bit-sicher (und vermeiden dabei bestimmte ASCII-Steuercodes), erfordern möglicherweise Zeilenumbrüche in bestimmten maximalen Intervallen und behalten möglicherweise keine Leerzeichen bei . Somit sind nur die 94 druckbaren ASCII-Zeichen "sicher", um Daten zu übertragen.

Vier Bytes können 2 32  = 4.294.967.296 mögliche Werte darstellen. Fünf Radix- 85-Ziffern ergeben 85 5  = 4.437.053.125 mögliche Werte, genug, um für jeden möglichen 32-Bit-Wert eine eindeutige Darstellung bereitzustellen. Da fünf Radix-84-Ziffern nur 84 5  = 4.182.119.424 darstellbare Werte liefern, ist 85 die minimal mögliche ganzzahlige Basis, die vier Bytes in fünf Zeichen darstellt, daher seine Wahl.

Bei der Codierung wird jede Gruppe von 4 Bytes als 32-Bit-Binärzahl verwendet, das höchstwertige Byte zuerst (Ascii85 verwendet eine Big-Endian- Konvention). Dies wird durch wiederholtes Dividieren durch 85 und Aufnehmen des Rests in 5 Radix-85-Ziffern umgewandelt. Dann wird jede Ziffer (wieder die höchstwertige zuerst) als druckbares ASCII-Zeichen codiert, indem 33 hinzugefügt wird, wodurch die ASCII-Zeichen 33 (" !") bis 117 (" u") erhalten werden.

Da nur Null-Daten recht häufig vorkommen, wird aus Gründen der Datenkomprimierung eine Ausnahme gemacht und eine Gruppe ausschließlich aus Nullen wird als einzelnes Zeichen " z" anstelle von " !!!!!" codiert .

Zeichengruppen, die auf einen Wert größer als 2 32 − 1 (kodiert als " s8W-!") dekodiert werden, verursachen einen Dekodierfehler, ebenso wie " z" Zeichen in der Mitte einer Gruppe. Leerzeichen zwischen den Zeichen werden ignoriert und können überall vorkommen, um Beschränkungen der Zeilenlänge zu berücksichtigen.

Ein Nachteil von Ascii85 besteht darin, dass codierte Daten Escape-Zeichen wie Backslash und Anführungszeichen enthalten können, die in vielen Programmiersprachen und in einigen textbasierten Protokollen eine besondere Bedeutung haben. Andere Base-85-Codierungen wie Z85 und RFC 1924 sind so konzipiert, dass sie im Quellcode sicher sind.

Geschichte

btoa-Version

Das ursprüngliche btoa-Programm codierte immer vollständige Gruppen (wobei die Quelle nach Bedarf aufgefüllt wurde), mit einer Präfixzeile von "xbtoa Begin" und einer Suffixzeile von "xbtoa End", gefolgt von der ursprünglichen Dateilänge (in dezimal und hexadezimal ) und drei 32 -bit Prüfsummen . Der Decoder muss die Dateilänge verwenden, um zu sehen, wie viel von der Gruppe aufgefüllt wurde. Der ursprüngliche Vorschlag für die Btoa-Codierung verwendete ein Codierungsalphabet, das mit dem ASCII-Leerzeichen bis einschließlich "t" begann, aber dies wurde durch ein Codierungsalphabet von "!" auf "u", um "Probleme mit einigen Mailern (Abtrennen von abschließenden Leerzeichen)" zu vermeiden. In diesem Programm wurde auch die spezielle zKurzform " " für eine Null-Gruppe eingeführt. Version 4.2 fügte eine yAusnahme " " für eine Gruppe aller ASCII- Leerzeichen (0x20202020) hinzu.

ZMODEM-Version

Die "ZMODEM Pack-7-Kodierung" kodiert Gruppen von 4 Oktetten in Gruppen von 5 druckbaren ASCII-Zeichen auf ähnliche oder möglicherweise dieselbe Weise wie Ascii85. Wenn ZMODEM- Programme vorkomprimierte 8-Bit-Datendateien über 7-Bit-Datenkanäle senden , verwendet es die "ZMODEM Pack-7-Kodierung".

Adobe-Version

Adobe hat die grundlegende btoa-Kodierung übernommen, jedoch mit geringfügigen Änderungen, und ihr den Namen Ascii85 gegeben. Die verwendeten Zeichen sind die ASCII-Zeichen 33 ( !) bis ueinschließlich 117 ( ) (für die Basis-85-Ziffern 0 bis 84), zusammen mit dem Buchstaben z(als Sonderfall für einen 32-Bit-Wert 0) und Leerzeichen wird ignoriert. Adobe verwendet das Trennzeichen " ~>", um das Ende eines ASCII85-codierten Strings zu markieren und stellt die Länge durch Abschneiden der letzten Gruppe dar: Wenn der letzte Block von Quellbytes weniger als 4 Byte enthält, wird der Block mit bis zu 3 Null-Bytes aufgefüllt, bevor Codierung. Nach der Codierung werden am Ende der Ausgabe so viele Bytes entfernt, wie Padding hinzugefügt wurde.

Beim Decodieren wird umgekehrt: Der letzte Block wird mit dem ASCII85-Zeichen auf 5 Byte aufgefüllt u, und so viele Bytes, wie aufgefüllt wurden , werden am Ende der Ausgabe weggelassen (siehe Beispiel).

HINWEIS: Die Polsterung ist nicht willkürlich. Beim Konvertieren von Binär zu Base 64 werden nur Bits neu gruppiert und sie oder ihre Reihenfolge nicht geändert (ein High-Bit in Binär hat keinen Einfluss auf die Low-Bits in der Base64-Darstellung). Bei der Umwandlung einer Binärzahl in base85 (85 ist keine Zweierpotenz) beeinflussen hohe Bits die niederwertigen base85-Ziffern und umgekehrt. Das Auffüllen des binären Low (mit Null-Bits) während des Codierens und das Auffüllen des base85-Wertes High (mit us) beim Decodieren stellt sicher, dass die höherwertigen Bits erhalten bleiben (das Null-Auffüllen in der Binärdatei bietet genügend Platz, so dass eine kleine Addition eingefangen wird und dort ist kein "Übertragen" zu den hohen Bits).

In ASCII85-codierten Blöcken können Leerzeichen und Zeilenumbruchzeichen überall vorhanden sein, auch in der Mitte eines 5-Zeichen-Blocks, sie müssen jedoch stillschweigend ignoriert werden.

Die Spezifikation von Adobe unterstützt die yAusnahme nicht.

Beispiel für ASCII85

Ein Zitat aus dem Leviathan von Thomas Hobbes :

Der Mensch unterscheidet sich nicht nur durch seine Vernunft, sondern auch durch diese einzigartige Leidenschaft von anderen Tieren, die eine Begierde des Geistes ist, die durch eine Beharrlichkeit der Freude an der fortwährenden und unermüdlichen Erzeugung von Wissen die kurze Heftigkeit jedes fleischlichen Vergnügens übersteigt .

Wenn diese anfänglich mit US-ASCII kodiert ist, kann sie wie folgt in ASCII85 neu kodiert werden: 

<~9jqo^BlbD-BleB1DJ+*+F(f,q/0JhKF<GL>Cj@.4Gp$d7F!,L7@<6@)/0JDEF<G%<+EV:2F!,
O<DJ+*.@<*K0@<6L(Df-\0Ec5e;DffZ(EZee.Bl.9pF"AGXBPCsi+DGm>@3BB/F*&OCAfu2/AKY
i(DIb:@FD,*)+C]U=@3BN#EcYf8ATD3s@q?d$AftVqCh[NqF<G:8+EV:.+Cf>-FD5W8ARlolDIa
l(DId<j@<?3r@:F%a+D58'ATD4$Bl@l3De:,-DJs`8ARoFb/0JMK@qB4^F!,R<AKZ&-DfTqBG%G
>uD.RTpAKYo'+CT/5+Cei#DII?(E,9)oF*2M7/c~>
Textinhalt m ein n ... S du R e
ASCII 77 97 110 32 ... 115 117 114 101
Bitmuster 0 1 0 0 1 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0 0 0 1 0 0 0 0 0 ... 0 1 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 1 1 0 0 1 0 0 1 1 0 0 1 0 1
32-Bit-Wert 1.298.230.816 = 24×85 4 + 73×85 3 + 80×85 2 + 78×85 + 61 ... 1.937.076.837 = 37×85 4 + 9×85 3 + 17×85 2 + 44×85 + 22
Basis 85 (+33) 24 (57) 73 (106) 80 (113) 78 (111) 61 (94) ... 37 (70) 9 (42) 17 (50) 44 (77) 22 (55)
ASCII 9 J Q Ö ^ ... F * 2 m 7

Da das letzte 4-Tupel unvollständig ist, muss es mit drei Null-Bytes aufgefüllt werden:

Textinhalt . \0 \0 \0
ASCII 46 0 0 0
Bitmuster 0 0 1 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
32-Bit-Wert 771.751.936 = 14×85 4 + 66×85 3 + 56×85 2 + 74×85 + 46
Basis 85 (+33) 14 (47) 66 (99) 56 (89) 74 (107) 46 (79)
ASCII / C Ja k Ö

Da drei Byte Padding hinzugefügt werden mussten, werden die drei letzten Zeichen 'YkO' bei der Ausgabe weggelassen.

Die Dekodierung erfolgt invers, außer dass das letzte 5-Tupel mit 'u'-Zeichen aufgefüllt wird:

ASCII / C du du du
Basis 85 (+33) 14 (47) 66 (99) 84 (117) 84 (117) 84 (117)
32-Bit-Wert 771.955.124 = 14×85 4 + 66×85 3 + 84×85 2 + 84×85 + 84
Bitmuster 0 0 1 0 1 1 1 0 0 0 0 0 0 0 1 1 0 0 0 1 1 0 0 1 1 0 1 1 0 1 0 0
ASCII 46 3 25 180
Textinhalt . [ ETX ] [ EM ] ´ ( Erweitertes ASCII )

Da die Eingabe mit drei 'u'-Bytes aufgefüllt werden musste, werden die letzten drei Bytes der Ausgabe ignoriert und wir erhalten den ursprünglichen Punkt.

Der Eingabesatz enthält keine 4 aufeinanderfolgenden Nullbytes, daher zeigt das Beispiel die Verwendung der Abkürzung 'z' nicht.

Kompatibilität

Die Ascii85-Codierung ist mit 7-Bit- und 8-Bit- MIME kompatibel , hat aber weniger Overhead als Base64 .

Ein potenzielles Kompatibilitätsproblem von Ascii85 besteht darin, dass 'einfache' und "doppelte" Anführungszeichen, <Winkel>-Klammern und kaufmännische Und-Zeichen (&) in Auszeichnungssprachen wie XML oder SGML nicht ohne Escapezeichen verwendet werden können.

RFC 1924-Version

Das am 1. April 1996 veröffentlichte Informationsblatt RFC  1924 : "A Compact Representation of IPv6 Addresses" von Robert Elz schlägt eine Base-85-Codierung von IPv6- Adressen vor. Dies unterscheidet sich von dem oben verwendeten Schema darin, dass er einen anderen Satz von 85 ASCII-Zeichen vorschlägt und vorschlägt, die gesamte Arithmetik für die 128-Bit-Zahl durchzuführen und sie in eine einzelne 20-stellige Basis-85-Zahl umzuwandeln (interner Leerraum nicht zulässig). , anstatt es in vier 32-Bit-Gruppen aufzuteilen.

Der vorgeschlagene Zeichensatz ist der Reihe nach 0– 9, A– Z, a– z, und dann die 23 Zeichen !#$%&()*+-;<=>?@^_`{|}~. Die höchstmögliche darstellbare Adresse, 2 128 –1 = 74×85 19  + 53×85 18  + 5×85 17  + ..., würde als codiert werden =r54lj&NUUO~Hi%c2ym0.

Dieser Zeichensatz schließt die Zeichen aus "',./:[\] , wodurch er für die Verwendung in JSON- Strings geeignet ist (wo "und wo \Escapezeichen erforderlich wären). Für SGML- basierte Protokolle, insbesondere einschließlich XML , können jedoch immer noch Zeichenfolgen-Escapes erforderlich sein (um <, >und unterzubringen &).

Siehe auch

Verweise

Externe Links