Ascii85 - Ascii85

Ascii85, také zvaný Base85, je forma kódování binárního textu vyvinutý Paulem E. Rutterem pro Btoa nástroj. Použitím pěti ASCII znaky, které představují čtyři bajty binární data (vytvoření kódované velikosti¹⁄₄ větší než originál, za předpokladu osmi bitů na znak ASCII), je efektivnější než uuencode nebo Base64, které pomocí čtyř znaků představují tři bajty dat (¹⁄₃ zvýšit za předpokladu osmi bitů na znak ASCII).

Jeho hlavní moderní použití je v Adobe je PostScript a Přenosný formát dokumentu formátů souborů, stejně jako v náplast kódování pro binární soubory používá Git.^[1]

Přehled

Základní potřeba kódování binárního textu vychází z potřeby svévolné komunikace binární data přes existující komunikační protokoly které byly navrženy tak, aby nesly pouze anglický jazyk čitelné člověkem text. Tyto komunikační protokoly mohou být pouze 7bitové bezpečné (a v rámci toho se vyhýbají určitým řídicím kódům ASCII) a mohou vyžadovat konce řádků v určitých maximálních intervalech a nemusí udržovat mezery. Tedy pouze 95 tisknutelné znaky ASCII jsou „bezpečná“ pro přenos dat.

Čtyři bajty mohou představovat 2³² = 4 294 967 296 možných hodnot. Pět základ -85 číslic poskytuje 85⁵ = 4 437 053 125 možných hodnot, dostačující k zajištění jedinečné reprezentace pro každou možnou 32bitovou hodnotu. Protože pět číslic radix-84 poskytuje pouze 84⁵ = 4 182 119 424 reprezentovatelných hodnot, 85 je minimální možná integrální základna, která bude představovat čtyři bajty v pěti znacích, proto je jeho volba.

Při kódování je každá skupina 4 bajtů brána jako 32bitové binární číslo, nejdříve nejvýznamnější bajt (Ascii85 používá big-endian konvence). To se převede opakovaným dělením na 85 a převzetím zbytku na 5 radix-85 číslic. Poté je každá číslice (opět nejvýznamnější) zakódována jako tisknutelný znak ASCII přidáním 33, což dává znakům ASCII 33 ("!„) až 117 („u").

Vzhledem k tomu, že nulová data jsou docela běžná, je kvůli nim vytvořena výjimka komprese dat a skupina s nulovou hodnotou je zakódována jako jeden znak "z" namísto "!!!!!".

Skupiny znaků, které dekódují na hodnotu větší než 2³² − 1 (kódováno jako „s8W-!") způsobí chybu dekódování, stejně jako" "z"znaky uprostřed skupiny. Prázdné místo mezi znaky je ignorováno a může se vyskytnout kdekoli, aby vyhovovalo omezením délky řádku.

Jednou z nevýhod Ascii85 je, že kódovaná data mohou obsahovat uniknout znaky jako zpětné lomítko a citace, které mají v mnoha programovacích jazycích a v některých textových protokolech zvláštní význam. Další kódování base-85 jako Z85 a RFC 1924 jsou navrženy tak, aby byly bezpečné ve zdrojovém kódu.^[2]

Dějiny

verze btoa

Původní program btoa vždy kódoval celé skupiny (podle potřeby doplňte zdroj) s předponou „xbtoa Begin“ a příponou „xbtoa End“, za kterou následuje původní délka souboru (v desítkovém a hexadecimální ) a tři 32bitové kontrolní součty. Dekodér musí použít délku souboru, aby zjistil, jak velká část skupiny byla polstrována. Původní návrh pro kódování btoa používal kódovací abecedu začínající od znaku mezery ASCII až po „t“ včetně, ale toto bylo nahrazeno kódovací abecedou „!“ „u“, aby se předešlo „problémům s některými poštovními zásilkami (odizolování koncových mezer).“^[3] Tento program také zavedl speciální „z"krátký formulář pro skupinu s nulovou hodnotou. Verze 4.2 přidala"y"výjimka pro skupinu všech ASCII prostor znaků (0x20202020).

Verze ZMODEM

„ZMODEM Pack-7 encoding“ kóduje skupiny 4 oktetů do skupin po 5 tisknutelných ASCII znakech podobným způsobem, případně stejným způsobem jako Ascii85. Když ZMODEM programy odesílají předkomprimované 8bitové datové soubory 7bitové datové kanály, používá „kódování ZMODEM Pack-7“.^[4]

Verze Adobe

Společnost Adobe přijala základní kódování btoa, ale s malými změnami, a dala mu název Ascii85. Použité znaky jsou znaky ASCII 33 (!) Až 117 (u) včetně (k reprezentaci číslic základny-85 0 až 84), spolu s písmenem z (jako speciální případ k reprezentaci 32bitové hodnoty 0), a prázdné místo je ignorováno. Adobe používá oddělovač “~>"k označení konce řetězce kódovaného Ascii85 a představuje délku zkrácením finální skupiny: Pokud poslední blok zdrojových bytů obsahuje méně než 4 bajty, blok je před kódováním polstrován až třemi nulovými bajty. Po kódování , na konci výstupu bude odebráno tolik bajtů, kolik bylo přidáno jako odsazení.

Při dekódování se použije reverz: Poslední blok je vyplněn na 5 bajtů znakem Ascii85 "u", a tolik bajtů, kolik bylo přidáno jako odsazení, je na konci výstupu vynecháno (viz příklad).

POZNÁMKA: Polstrování není libovolné. Konverze z binárního na základní 64 pouze přeskupuje bity a nemění je ani jejich pořadí (vysoký bit v binárním formátu neovlivňuje nízké bity v reprezentaci base64). Při převodu binárního čísla na base85 (85 je ne síla dvou) vysokých bitů má vliv na základnu nízkého řádu85 číslic a naopak. Polstrování binárního minima (s nulovými bity) při kódování a polstrování vysoké hodnoty base85 (pomocí 'u) v dekódování zajišťuje, že bity vysokého řádu budou zachovány (nulové polstrování v binárním kódu poskytuje dostatek prostoru, aby byl zachycen malý přídavek a neexistuje žádný "přenos" k vysokým bitům).

V blocích kódovaných Ascii85 mohou být mezery a znaky zalomení řádků přítomny kdekoli, včetně uprostřed bloku o 5 znacích, ale musí být tiše ignorovány.

Specifikace Adobe nepodporuje „y"výjimka.

Příklad pro Ascii85

Citát z Thomase Hobbese Leviatan:

Člověk se vyznačuje nejen svým rozumem, ale také touto jedinečnou vášní od ostatních zvířat, kterou je chtíč mysli, který vytrvalostí radosti v pokračující a neúnavné generaci znalostí překračuje krátkou prudkost jakéhokoli tělesného potěšení .

Pokud je to původně zakódováno pomocí US-ASCII, může být překódováno v Ascii85 následujícím způsobem:

<~9jqo^BlbD-BleB1DJ+*+F(f,q/0JhKF<GL>[email protected]$d7F!,L7@<6@)/0JDEF<G%<+EV:2F!,O<DJ+*.@<*K0@<6L(Df-\0Ec5e;DffZ(EZee.Bl.9pF"AGXBPCsi+DGm>@3BB/F*&OCAfu2/AKYi(DIb:@FD,*)+C]U=@3BN#EcYf8ATD3s@q?d$AftVqCh[NqF<G:8+EV:.+Cf>-FD5W8ARlolDIal(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~>

Protože poslední 4-tice je neúplná, musí být vyplněna třemi nulovými bajty:

Vzhledem k tomu, že bylo nutné přidat tři bajty odsazení, jsou tři poslední znaky „YkO“ z výstupu vynechány.

Dekódování se provádí inverzně, až na to, že poslední 5-tice je vyplněna znaky „u“:

Protože vstup musel být vyplněn třemi bajty „u“, poslední tři bajty výstupu jsou ignorovány a my skončíme s původní periodou.

Vstupní věta neobsahuje 4 po sobě jdoucí nulové bajty, takže příklad neukazuje použití zkratky „z“.

Kompatibilita

Kódování Ascii85 je kompatibilní s 7bitovým a 8bitovým MIM, zatímco má menší režii než Base64.

Jedním z možných problémů s kompatibilitou Ascii85 je to, že uvozovky typu „single“ a „double“, závorky a ampersands (&) nelze použít bez kódování ve značkovacích jazycích, jako je XML nebo SGML.

Verze RFC 1924

Publikováno dne 1. dubna 1996, informační RFC  1924: "Kompaktní reprezentace adres IPv6" od Robert Elz navrhuje kódování base-85 IPv6 adresy. To se liší od výše použitého schématu v tom, že navrhuje jinou sadu 85 znaků ASCII a navrhuje provést veškerou aritmetiku na 128bitovém čísle a převést ji na jedno 20místné číslo base-85 (interní mezera není povolena) , spíše než rozdělit jej do čtyř 32bitových skupin.

Navrhovaná znaková sada je v pořadí 0–9, A–Z, A–za poté 23 znaků !#$%&()*+-;<=>?@^_`{|}~. Nejvyšší možná zastupitelná adresa, 2¹²⁸−1 = 74×85¹⁹ + 53×85¹⁸ + 5×85¹⁷ + ..., bude zakódováno jako = r54lj & NUUO ~ Ahoj% c2ym0.

Tato znaková sada vylučuje znaky "',./:[\] , takže je vhodný pro použití v JSON řetězce (kde " a \ by vyžadovalo únik). Nicméně pro SGML - založené na protokolech, zejména včetně XML, stále mohou být vyžadovány úniky řetězců (k přizpůsobení <, > a &).

Viz také

• Base32
• Base36
• Base64
• Binární kódování textu pro srovnání různých kódovacích algoritmů
• Standardní kódování PostScript

Reference

externí odkazy

• BasE91
• Referenční příručka jazyka PostScript (Adobe) - viz ASCII85Encode Filter