Ascii85

Ascii85 , zwany także Base85 , to forma kodowania binarnego na tekst opracowana przez Paula E. Ruttera dla narzędzia btoa . Używając pięciu ASCII do reprezentowania czterech bajtów danych binarnych (dzięki czemu zakodowany rozmiar jest o 1 ⁄ 4 większy niż oryginał, przy założeniu ośmiu bitów na znak ASCII), jest bardziej wydajny niż uuencode lub Base64 , które używają czterech znaków do reprezentowania trzech bajtów danych ( wzrost o 1/3 , . przy założeniu ośmiu bitów na znak ASCII)

Jego główne współczesne zastosowania to formaty plików PostScript i Portable Document Format firmy Adobe , a także kodowanie poprawek dla plików binarnych używanych przez Git .

Przegląd

Podstawowa potrzeba kodowania binarnego na tekst wynika z potrzeby przesyłania dowolnych danych binarnych za pośrednictwem istniejących wcześniej protokołów komunikacyjnych , które zostały zaprojektowane do przenoszenia wyłącznie tekstu czytelnego dla człowieka w języku angielskim. Te protokoły komunikacyjne mogą być bezpieczne tylko 7-bitowo (i w ramach tego unikać pewnych kodów kontrolnych ASCII) i mogą wymagać łamania linii w określonych maksymalnych odstępach czasu i mogą nie zawierać białych znaków . Zatem tylko 94 drukowane znaki ASCII są „bezpieczne” w użyciu do przekazywania danych.

Osiemdziesiąt pięć to minimalna wartość całkowa n taka, że ​​n 5 ≥ 256 4 ; więc dowolna sekwencja 4 bajtów może być zakodowana jako 5 symboli, o ile dostępnych jest co najmniej 85 różnych symboli. (Pięć podstawy -85 może reprezentować liczby całkowite od 0 do 4 437 053 124 włącznie, co wystarcza do przedstawienia wszystkich 4 294 967 296 możliwych sekwencji 4-bajtowych.)

Kodowanie

Podczas kodowania każda grupa 4 bajtów jest traktowana jako 32-bitowa liczba binarna, zaczynając od najbardziej znaczącego bajtu (Ascii85 używa konwencji big-endian ). Jest to konwertowane przez wielokrotne dzielenie przez 85 i wzięcie reszty na 5 cyfr podstawy - 85. Następnie każda cyfra (ponownie najpierw najbardziej znacząca) jest kodowana jako drukowalny znak ASCII przez dodanie do niej 33, co daje znaki ASCII od 33 ( ! ) do 117 ( u ).

Ponieważ dane zerowe są dość powszechne, robi się wyjątek ze względu na kompresję danych , a grupa zerowa jest kodowana jako pojedynczy znak z zamiast !!!!! .

Grupy znaków, które dekodują do wartości większej niż 2 32 − 1 (zakodowane jako s8W-! ) spowodują błąd dekodowania, podobnie jak znaki z w środku grupy. Białe odstępy między znakami są ignorowane i mogą wystąpić w dowolnym miejscu, aby dostosować się do ograniczeń długości linii.

Ograniczenia

Oryginalna specyfikacja pozwala na zakodowanie tylko strumienia, który jest wielokrotnością 4 bajtów.

  Zakodowane dane mogą zawierać znaki , które mają specjalne znaczenie w wielu językach programowania i niektórych protokołach tekstowych, takie jak lewy nawias ostry < , odwrotny ukośnik \ oraz pojedyncze i podwójne cudzysłowy „ & ” . Inne kodowania base-85, takie jak Z85 i RFC 1924 zostały zaprojektowane tak, aby były bezpieczne w kodzie źródłowym.

Historia

wersja btoa

Oryginalny program btoa zawsze kodował pełne grupy (w razie potrzeby dopełniając źródło), z linią prefiksu „xbtoa Begin” i linią sufiksu „xbtoa End”, po której następowała oryginalna długość pliku (w systemie dziesiętnym i szesnastkowym) oraz trzy 32 -bitowe sumy kontrolne . Dekoder musi użyć długości pliku, aby zobaczyć, jaka część grupy była wypełniona. Początkowa propozycja kodowania btoa wykorzystywała alfabet kodowania zaczynający się od znaku spacji ASCII do „t” włącznie, ale został on zastąpiony alfabetem kodowania „!” do „u”, aby uniknąć „problemów z niektórymi programami pocztowymi (usuwanie końcowych spacji)”. W tym programie wprowadzono również specjalną krótką formę „ z ” dla grupy zerowej. Wersja 4.2 dodała wyjątek „ y ” dla grupy wszystkich spacji ASCII (0x20202020).

Wersja ZMODEM

„Kodowanie ZMODEM Pack-7” koduje grupy 4 oktetów w grupy po 5 drukowalnych znaków ASCII w podobny lub być może taki sam sposób, jak robi to Ascii85. Kiedy ZMODEM wysyła wstępnie skompresowane 8-bitowe pliki danych przez 7-bitowe kanały danych , używa „kodowania ZMODEM Pack-7”.

Wersja Adobe'a

Firma Adobe przyjęła podstawowe kodowanie btoa, ale z niewielkimi zmianami, i nadała mu nazwę Ascii85. Używane znaki to znaki ASCII od 33 ( ! ) do 117 ( u ) włącznie (reprezentujące cyfry w systemie base-85 od 0 do 84) wraz z literą z (jako przypadek specjalny reprezentujący 32-bitową wartość 0), a odstępy są ignorowane. Firma Adobe używa ogranicznika „ ~> ” do oznaczenia końca łańcucha zakodowanego w Ascii85 i reprezentuje długość przez obcięcie końcowej grupy: Jeśli ostatni blok bajtów źródłowych zawiera mniej niż 4 bajty, blok jest dopełniany maksymalnie 3 znakami zerowymi bajtów przed kodowaniem. Po zakodowaniu tyle bajtów, ile zostało dodanych jako dopełnienie, jest usuwanych z końca danych wyjściowych.

Odwrotna sytuacja jest stosowana podczas dekodowania: ostatni blok jest dopełniany do 5 bajtów za pomocą znaku Ascii85 u , a tyle bajtów, ile zostało dodanych jako dopełnienie, jest pomijanych na końcu wyjścia (patrz przykład).

UWAGA: Wyściółka nie jest dowolna. Konwersja z binarnego na base 64 tylko przegrupowuje bity i nie zmienia ich ani ich kolejności (wysoki bit w formacie binarnym nie wpływa na niskie bity w reprezentacji base64). Podczas konwersji liczby binarnej na podstawę 85 (85 nie jest potęgą dwóch) wysokie bity wpływają na cyfry podstawy 85 niższego rzędu i odwrotnie. Dopełnienie binarnego dolnego (bitami zerowymi) podczas kodowania i dopełnienie wartości base85 wysokiej (u s ) podczas dekodowania zapewnia zachowanie bitów wyższego rzędu (wypełnienie zerowe w binarnym daje wystarczająco dużo miejsca, aby mały dodatek został uwięziony i nie ma „przeniesienia” do wysokich bitów).

W blokach zakodowanych w Ascii85 spacje i znaki końca wiersza mogą występować w dowolnym miejscu, w tym w środku 5-znakowego bloku, ale muszą być po cichu ignorowane.

Specyfikacja firmy Adobe nie obsługuje wyjątku y .

Przykład dla Ascii85

Cytat z Lewiatana Thomasa Hobbesa :

Człowiek wyróżnia się nie tylko swoim rozumem, ale i tą szczególną namiętnością, która jest pożądaniem umysłu, które dzięki wytrwałości w ciągłym i niestrudzonym generowaniu wiedzy przewyższa krótkotrwałą gwałtowność jakiejkolwiek przyjemności cielesnej. .

Jeśli jest to początkowo zakodowane przy użyciu US-ASCII, można je ponownie zakodować w Ascii85 w następujący sposób:

9jqo^BlbD-BleB1DJ+*+F(f,q/0JhKF [email protected]$d7F!,L7@<6@)/0JDEF @3BB/F*&OCAfu2/AKYi( DIb:@FD,*)+C]U=@3BN#EcYf8ATD3s@q?d$AftVqCh[NqF -FD5W8ARlolDIal( DId u D.RTpAKYo'+CT/5+Cei#DII?(E,9)oF*2M7/c
Treść tekstu M A N ... S u R mi
ASCII 77 97 110 32 ... 115 117 114 101
Wzór bitowy 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
Wartość 32-bitowa 1 298 230 816 = 24×85 4 + 73×85 3 + 80×85 2 + 78×85 + 61 ... 1937076837 = 37×85 4 + 9×85 3 + 17×85 2 + 44×85 + 22
Baza 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 o ^ ... F * 2 M 7

Ponieważ ostatnia 4-krotka jest niekompletna, musi być uzupełniona trzema bajtami zerowymi:

Treść tekstu . \0 \0 \0
ASCII 46 0 0 0
Wzór bitowy 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
Wartość 32-bitowa 771 751 936 = 14×85 4 + 66×85 3 + 56×85 2 + 74×85 + 46
Baza 85 (+33) 14 (47) 66 (99) 56 (89) 74 (107) 46 (79)
ASCII / C Y k O

Ponieważ trzeba było dodać trzy bajty dopełnienia, trzy ostatnie znaki „YkO” są pomijane w danych wyjściowych.

Dekodowanie odbywa się odwrotnie, z wyjątkiem tego, że ostatnia 5-krotka jest uzupełniona znakami „u”:

ASCII / C u u u
Baza 85 (+33) 14 (47) 66 (99) 84 (117) 84 (117) 84 (117)
Wartość 32-bitowa 771 955 124 = 14×85 4 + 66×85 3 + 84×85 2 + 84×85 + 84
Wzór bitowy 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
Treść tekstu . [ ETX ] [ EM ] ´ ( Rozszerzony ASCII )

Ponieważ wejście musiało być uzupełnione trzema bajtami „u”, ostatnie trzy bajty danych wyjściowych są ignorowane i otrzymujemy pierwotną kropkę.

Zdanie wejściowe nie zawiera 4 kolejnych bajtów zerowych, więc przykład nie pokazuje użycia skrótu „z”.

Zgodność

Kodowanie Ascii85 jest kompatybilne z 7-bitowym i 8-bitowym MIME , a jednocześnie ma mniejszy narzut niż Base64 .

Jednym z potencjalnych problemów ze zgodnością Ascii85 jest to, że niektóre znaki, których używa, są znaczące w językach znaczników, takich jak XML lub SGML . Aby uwzględnić dane ascii85 w tych dokumentach, może być konieczne zastosowanie cudzysłowu , nawiasów ostrych i ampersandów .

Wersja RFC1924

  Opublikowany 1 kwietnia 1996 r . dokument informacyjny RFC 1924 : „A Compact Representation of IPv6 Addresses” autorstwa Roberta Elza sugeruje kodowanie adresów IPv6 base-85 . Różni się to od schematu użytego powyżej tym, że proponuje inny zestaw 85 znaków ASCII i proponuje wykonanie całej arytmetyki na 128-bitowej liczbie, konwertując ją na pojedynczą 20-cyfrową liczbę o podstawie 85 (wewnętrzne spacje niedozwolone) , zamiast dzielić go na cztery 32-bitowe grupy.

0 Proponowany zestaw znaków to w kolejności – 9 , A – Z , a – z , a następnie 23 znaki !#$%&()*+-;<=>?@^_`{|}~ . Najwyższy możliwy reprezentowalny adres, 2 128 −1 = 74×85 19 + 53×85 18 + 5×85 17 + ..., byłby zakodowany jako =r54lj&NUUO~Hi%c2ym0 .

Ten zestaw znaków wyklucza znaki "',./:[\] , dzięki czemu nadaje się do użycia w ciągach JSON (gdzie " i \ wymagałyby ucieczki). Jednak w przypadku protokołów opartych na SGML , w szczególności w tym XML , nadal mogą być wymagane znaki specjalne (aby pomieścić < , > i & ).

Zobacz też

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Ascii85&oldid=1124166077 ”