ASCII85

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 17. september 2016; checks kræver 14 redigeringer .

Ascii85 (også kendt som "Base85") er en form for kodning af binære data med tekst udviklet af Paul E. Rutter til btoa-biblioteket. På grund af det faktum, at 5 ASCII -tegn bruges til at kode 4 bytes data (de behandlede data er ¹⁄₄ større end originalen ved brug af 8-bit ASCII-tegn), opnås der mere effektivitet end i tilfældet med uuencode eller Base64 , hvor hver 3. byte er kodet med 4 tegn (en stigning på ¹⁄₃ under de samme betingelser).

Det bruges hovedsageligt i formaterne PostScript og Portable Document Format fra Adobe .

Hovedidé

Hovedbehovet for kodning af data i tekst stammer fra behovet for at overføre binære data ved hjælp af eksisterende protokoller designet udelukkende til teksttransmission (f.eks. e-mail). Sådanne protokoller kan kun garanteres at passere 7-bit-værdier (og undgå brugen af ​​ASCII-kontroltegn), og kan kræve indsættelse af et ende-på-linje-tegn for at begrænse længden af ​​linjer og tillade indrykning af hvidt mellemrum. Dette efterlader kun 94 printbare tegn, der kan bruges.

4 bytes kan indeholde 232 = 4294967296  forskellige værdier. 5 cifre i base 85 giver 855  = 4437053125 distinkte værdier, hvilket er nok til at repræsentere 32-bit værdier utvetydigt. Fem cifre i basis 84 kan kun give 84 5  = 4.182.119.424 værdier. Derfor er 85 minimumsbasen i talsystemet, hvor 4 bytes kan kodes med fem cifre, hvorfor det blev valgt.

Ved kodning opdeler vi datastrømmen i grupper på 4 bytes og betragter hver af dem som et 32-bit tal, med den høje byte i begyndelsen . Ved fortløbende division med 85 får vi 5 cifre i det 85-årige talsystem. Yderligere er hvert ciffer kodet med et printbart ASCII-tegn og output til outputstrømmen med rækkefølgen bevaret fra det mest signifikante ciffer til det mindst signifikante.

Indkodningen af ​​et ciffer med ASCII-tegn udføres ved at øge med 33, det vil sige tegn med koder fra 33 (" !") til 117 (" u").

Da nulværdier ikke er så sjældne, er der af hensyn til yderligere komprimering lavet en ekstra undtagelse - nul fire bytes kodes med et enkelt tegn " z" i stedet for " !!!!!".

En gruppe af tegn, der, når de afkodes, giver en værdi større end 2 32 − 1 (kodet som " s8W-!"), resulterer i en afkodningsfejl, ligesom tegnet " z" i gruppen. Alle hvide mellemrumsindrykninger mellem tegn ignoreres og kan indsættes vilkårligt for bekvem formatering.

Den eneste ulempe ved Ascii85 er, at den resulterende tekst vil indeholde tegn (såsom skråstreger og anførselstegn), der har særlige betydninger i programmeringssprog og tekstprotokoller.

btoa

Det originale btoa-program er altid kodet i hele grupper (sidstnævnte polstret med nuller) og foran den resulterende tekst med strengen "xbtoa Begin" efterfulgt af "xbtoa End" efterfulgt af størrelsen af ​​kildefilen (decimal og hexadecimal) og tre 32 -bit kontrolsummer. Dekoderen brugte den originale længdeinformation til at finde ud af, hvor mange polstringsnuller der blev indsat.

Dette program understøttede også den særlige værdi " z" til at kode nuller (0x00000000), samt " y" for en gruppe på fire mellemrum (0x20202020).

Adobe

Adobe tilpassede btoa-kodningen med nogle ændringer og kaldte den Ascii85. Især er afgrænsningstegnet " ~>" blevet tilføjet for at angive slutningen af ​​den kodede streng og bestemme, hvor den afkodede streng skal klippes for at få den korrekte længde. Dette gøres på følgende måde: hvis den sidste blok indeholder mindre end 4 bytes, så suppleres den med nul bytes før kodning, og efter indkodning fjernes lige så mange ekstreme tegn, som der blev tilføjet nuller fra de sidste fem.

Under afkodningen polstres den sidste blok til en længde på 5 med symbolet " u" (kode 84), og efter afkodningen slettes det samme antal bytes (se eksempel nedenfor).

Bemærk: Fyldkarakteren blev ikke valgt tilfældigt. I Base64, ved omkodning, omgrupperes bits simpelthen, hverken deres rækkefølge eller deres værdier ændres (de høje bits i kildesekvensen påvirker ikke de lave bits af resultatet). Når de konverteres til et talsystem med basis 85 (85 er ikke en potens af to), påvirker værdierne af de høje bits i den oprindelige sekvens de lave bits af resultatet (på samme måde ved tilbagekonvertering). Tilføjelsen af ​​en minimumsværdi (0) ved indkodning og en maksimumværdi (84) ved afkodning sikrer, at de høje bits bevares.

I en blok med Ascii85-tekst kan mellemrum og linjeskift indsættes hvor som helst, inklusive inde i fem bogstaver. De skal simpelthen ignoreres.

Specifikationen fra Adobe inkluderer ikke " "-udvidelsen ytil fire mellemrum.

Eksempel

For eksempel Wikipedias historiske slogan ,

Mennesket udmærker sig, ikke blot ved sin fornuft, men ved denne enestående lidenskab fra andre dyr, som er et sinds begær, som ved en udholdenhed af glæde ved den fortsatte og utrættelige generation af viden overstiger den korte heftighed af enhver kødelig nydelse. .

at blive kodet i Ascii85 ser sådan ud:

<~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~>
Tekst M -en n ... s u r e
ASCII 77 97 110 32 ... 115 117 114 101
binær repræsentation 0 en 0 0 en en 0 en 0 en en 0 0 0 0 en 0 en en 0 en en en 0 0 0 en 0 0 0 0 0 ... 0 en en en 0 0 en en 0 en en en 0 en 0 en 0 en en en 0 0 en 0 0 en en 0 0 en 0 en
decimalrepræsentation 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
85 repræsentation (+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

Da de sidste fire ikke er færdige, skal vi "afslutte" det med nuller:

Tekst . \0 \0 \0
ASCII 46 0 0 0
binær repræsentation 0 0 en 0 en en en 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
decimalrepræsentation 771 751 936 = 14x85 4 + 66x85 3 + 56x85 2 + 74x85 + 46
85 repræsentation (+33) 14 (47) 66 (99) 56 (89) 74 (107) 46 (79)
ASCII / c Y k O

Vi har tilføjet 3 bytes ved kodning og skal fjerne de sidste tre 'YkO'-tegn fra resultatet.

Afkodningen er absolut symmetrisk, bortset fra de sidste fem, som vi "afslutter" med 'u'-tegn:

ASCII / c u u u
85 repræsentation (+33) 14 (47) 66 (99) 84 (117) 84 (117) 84 (117)
decimalrepræsentation 771 955 124 = 14×85 4 + 66×85 3 + 84×85 2 + 84×85 + 84
binær repræsentation 0 0 en 0 en en en 0 0 0 0 0 0 0 en en 0 0 0 en en 0 0 en en 0 en en 0 en 0 0
ASCII 46 3 25 180
Tekst . [ ETX ] [EM] ikke defineret i ASCII

Da vi har tilføjet 3 'u'er, skal vi fjerne de sidste 3 bytes fra resultatet. Som et resultat får vi en besked af den oprindelige længde.

Det originale eksempel havde ikke en kvartet af nulbytes, så vi så ikke det forkortede 'z' i resultatet.

Kompatibilitet

Ascii85-kodning er kompatibel med både 7-bit og 8-bit MIME , men kommer alligevel med mindre plads overhead end Base64 .

Det eneste potentielle problem er, at Ascii85 kan indeholde tegn, der skal escapes i markup-sprog, såsom XML eller SGML , såsom enkelte og dobbelte anførselstegn, vinkelparenteser, og- tegn (" '"<>&").

Joke RFC 1924 til at skrive IPv6-adresser

Udgivet den 1. april 1996, informativ RFC 1924 : "A Compact Representation of IPv6 Addresses" foreslår at indkode IPv6 -adresser som tal i base 85 (base-85, svarende til base-64). Dette forslag adskiller sig fra ovenstående skemaer ved, at det for det første bruger et sæt af andre 85 ASCII-tegn, og for det andet behandler det hele gruppen på 128 bits som et enkelt tal og konverterer det til 20 endelige tegn og ikke i grupper på 32 bit. Desuden er pladser ikke tilladt.

Foreslået tegnsæt i stigende rækkefølge af koder: 0- 9, A- Z, a- zog yderligere 23 tegn !#$%&()*+-;<=>?@^_`{|}~. Den største værdi, der passer i 128 bit af en IPv6-adresse er 2 128 −1 = 74×85 19  + 53×85 18  + 5×85 17  + …, har formen =r54lj&NUUO~Hi%c2ym0.

Tegnsættet er valgt for at undgå at bruge de mest problematiske tegn ( "',./:[]\), der skal escapes i nogle protokoller, såsom JSON. Men dette sæt indeholder stadig tegn, der skal escapes i SGML-protokoller, såsom XML.

Se også

Links