Base85

Base85 (inne nazwy Ascii85, Z85) – rodzaj kodowania transportowego umożliwiającego przekazywanie binarnych danych w środowisku, w którym dopuszczalne jest używanie jedynie znaków ASCII^[1].

Strumień danych dzielony jest na bloki podlegające transformacji. W dziedzinie danych binarnych rozmiar bloku to cztery bajty ${\displaystyle (b_{1}\ b_{2}\ b_{3}\ b_{4}).}$ Po stronie ASCII odpowiada im pięć znaków ${\displaystyle (c_{1}\ c_{2}\ c_{3}\ c_{4}\ c_{5}).}$ Oba zestawy łączy następująca relacja^[2]:

${\displaystyle b_{1}\times 256^{3}+b_{2}\times 256^{2}+b_{3}\times 256+b_{4}=c_{1}\times 85^{4}+c_{2}\times 85^{3}+c_{3}\times 85^{2}+c_{4}\times 85+c_{5}.}$

Proces konwersji wykorzystuje pozycyjny system liczbowy o podstawie ${\displaystyle 85}$ do reprezentacji liczb zapisanych na 32 bitach^[3] . Liczby trzydziestodwubitowe można traktować jak czterocyfrowe w systemie o podstawie ${\displaystyle 256}$^[4].

Proces translacji z dziedziny binarnej jest jednoznaczny dzięki relacji^[3] :

${\displaystyle 85^{5}>2^{32}}$^[a].

ASCII zawiera 95 znaków drukowalnych (wliczając w to odstęp). Do reprezentacji cyfr wykorzystuje się z niego podzbiór 85 znaków^[5].

Podstawowa funkcja konwertująca wymaga na wejściu liczb trzydziestodwubitowych. Oznacza to, że strumień danych binarnych powinien mieć całkowitą liczbę bajtów podzielną przez cztery. Sposób obsługi przypadków nie spełniających tego warunku zależy od implementacji. Jednym z rozwiązań jest dodanie brakujących bajtów o wartości zero do ostatniego bloku^[3]  i skrócenie wyniku o tyle cyfr ile bajtów zostało dodanych^[2][b].

• Rozmiar danych binarnych do zakodowanych pozostaje w stosunku ${\displaystyle 4:5}$^[6], czyli kodowanie zwiększa objętość o 25%^[7] . Daje to przewagę nad alternatywnym kodowaniem 7-bitowym. Na przykład base16 zwiększa rozmiar w stosunku ${\displaystyle 1:2}$^[8], natomiast base64 zamienia 24 bity na 4 znaki^[9] (stosunek ${\displaystyle 3:4,}$ czyli wzrost objętości o 33%).
• Podstawa o wartości ${\displaystyle 85}$ jest wielkością minimalną aby umożliwić prezentację każdej liczby trzydziestodwubitowej za pomocą pięciu cyfr^[c]. Możliwe jest użycie wszystkich 94 znaków ASCII, nie zmienia to jednak minimalnej liczby cyfr potrzebnej do zakodowania informacji^[10]. Stosowanie minimalnej bazy pozwala na użycie pozostałych znaków do innych celów^[10].
• Algorytmu nie można poddać optymalizacji polegającej na zdefiniowaniu predefiniowanych tablic mapujących wybrane grupy bitów na odpowiadające im znaki, co jest na przykład osiągalne dla base64^[11].

Różnice między istniejącymi wariantami polegają głównie na odpowiednim skojarzeniu znaków z wartościami cyfr w systemie o podstawie ${\displaystyle 85.}$

Program btoa w systemie Unix przydziela cyfrom kolejne kody ASCII począwszy od znaku ! dla cyfry o wartości ${\displaystyle 0}$ i kończywszy na znaku u dla cyfry o wartości ${\displaystyle 84}$^[3] . Znak x oznacza koniec zakodowanych danych, z jest skrótem oznaczającym cztery bajty o wartości zero^[3] . Nowsza wersja programu dodała również znak y, który oznacza cztery bajty o wartości 32 (cztery spacje)^[7] .

Implementacja Adobe Inc. na potrzeby języka PostScript wykorzystuje zestaw znaków od ! do u dla cyfr od ${\displaystyle 0}$ do ${\displaystyle 84}$ oraz stosuje skrót z na oznaczenie czterech bajtów o wartości zero. Symbolem końca danych jest sekwencja ~>^[2]. Kodowanie to jest określane nazwą ASCII85^[12].

Standard umożliwiający łatwe użycie kodowania bezpośrednio w kodzie źródłowym stosuje następującą kolejność znaków 0–9, a–z, A–Z, . - : + = ^ ! / * ? & < > ( ) [ ] { } @ % $ #^[13] . Można go używać w pojedynczych lub podwójnych cudzysłowach oraz przekazywać w linii poleceń. Umieszczenie znaku 0 jako reprezentacji cyfry 0 ułatwia naoczne wyszukiwanie zer binarnych^[13] .

Primaaprilisowa specyfikacja z propozycją zwartego zapisu adresów w sieci IPv6 zaleca następującą kolejność znaków dla cyfr o podstawie ${\displaystyle 85}$: 0–9, A–Z, a–z, ! # $ % & ( ) * + - ; < = > ? @ ^ _ ` { | } ~^[10].

Wykluczenie ' i " upraszcza cytowanie, a brak , i . umożliwia tworzenie list i zapis w zdaniu. Znaki / : [ ] mają już zarezerwowane znaczenie w CIDR i IPv6 stąd również nie są używane w kodowaniu. Natomiast znak \ mógłby powodować problemy w niektórych środowiskach, gdyż jest często używany do podawania sekwencji specjalnych^[14].

Dodatkową różnicą względem pozostałych wariantów jest brak dzielenia danych na czterobajtowe bloki. Specyfikacja omawia kodowanie w konteście adresów IPv6, które mają rozmiar 128 bitów i traktowane są w całości jako liczby całkowite w celu przekształcenia ich na zakodowaną 20 znakową postać^[14]. W ogólnym przypadku taki zapis adresu jest znacząco krótszy niż format standardowy lub skompresowany^[15].

Zestaw znaków z tej specyfikacji używany jest przez system kontroli wersji git do generowania łat z danych binarnych^[16][17].

Nie ma oficjalnego standardu dla efektywnego kodowania w dokumentach XML. Paul Kwiatkowski zaproponował następujący zestaw: 0–9, A–Z, a–y, ! # $ ( ) * + , - . / : ; = ? @ ^ ` { | } ~ z _^[5]. Jednak pozostał on jedynie w fazie propozycji jako INTERNET-DRAFT.

Zestaw unika znaków < > & ' " %, które muszą być zamieniane na sekwencje specjalne w niektórych przypadkach w kodzie XML^[18]. Ponadto wykluczone są \ [ ], które również mogłyby stanowić problemy w innych środowiskach^[18].

Znak z ma podwójną funkcję. Reprezentuje cyfrę ${\displaystyle 83}$ i na podobieństwo z programem btoa grupę czterech bajtów o wartości zero. Cyfra o wartości ${\displaystyle 83}$ nigdy nie wystąpi na pierwszej pozycji, a to umożliwia jej równoległe zastosowanie do tego celu^[19].

Najmniej znacząca cyfra jest kodowana w systemie liczbowym o podstawie ${\displaystyle 84.}$ Umożliwia to przypisanie ostatnim cyfrom kodowanym przez _ drugiej funkcji oznaczającej wyrównanie długości bloku^[20].

• R.R. Elz R.R., A Compact Representation of IPv6 Addresses, RFC 1924, IETF, 1 kwietnia 1996, DOI: 10.17487/RFC1924, ISSN 2070-1721, OCLC 943595667  (ang.).
• DakeD. He DakeD. i inni, A Proposal of Substitute for Base85/64 – Base91, [w:] CCCT SUMMER 2010 [online], 2010 [dostęp 2019-08-05]  (ang.).
• PieterP. Hintjens PieterP., 32/Z85 · ZeroMQ RFC [online] [dostęp 2019-08-04]  (ang.).
• S.S. Josefsson S.S., The Base16, Base32, and Base64 Data Encodings, RFC 4648, IETF, październik 2006, DOI: 10.17487/RFC4648, ISSN 2070-1721, OCLC 943595667  (ang.).
• PaulP. Kwiatkowski PaulP., A Base-85 Encoding Suitable for XML., [w:] INTERNET-DRAFT [online], maj 2004 [dostęp 2019-08-03]  (ang.).
• PeterP. Loshin PeterP., IPv6: Theory, Protocol, and Practice, Second Edition, Elsevier, 2004, ISBN 1-55860-810-9 .
• PaulP. Rutter PaulP., JoeJ. Orost JoeJ., [kod źródłowy btoa, wersja 4.0] [online] [dostęp 2019-08-03]  (ang.).
• P.P. Rutter P.P., J.J. Orost J.J., S.S. Parmark S.S., [kod źródłowy btoa, wersja 5.2] [online] [dostęp 2019-08-03]  (ang.).
• DavidD. Salomon DavidD., Data Compression. The complete reference, Fouth Edition, London: Springer, 2007, ISBN 978-1-84628-602-5 .
• Portable Document Format. Reference Manual. Version 1.3, Adobe Systems Incorporated, 11 marca 1999 [dostęp 2019-08-03]  (ang.).
• Supporting Data Compression in PostScript Level 2 and the filter Operator. Technical Note #5115, Adobe Systems Incorporated, 31 marca 1992 [dostęp 2019-08-03]  (ang.).
• Filters and Reusable Streams. Technical Note #5603, Adobe Systems Incorporated, 9 października 1997 [dostęp 2019-08-03]  (ang.).

• John D.J.D. Cook John D.J.D., Base85, Ascii85, and Z85, [w:] John D. Cook Consulting [online], 5 marca 2019 [dostęp 2019-08-04]  (ang.).