Ascii85

Le besoin fondamental d'un encodage binaire vers texte provient du besoin de communiquer des données binaires quelconques sur des protocoles de communication préexistants qui ont été conçus pour transporter uniquement du texte lisible par un être humain et écrit en anglais. Ces protocoles de communication peuvent ne fonctionner correctement qu'avec des octets sur 7 bits (voire ne pas supporter certains codes de contrôle ASCII) ; ils peuvent ne pas supporter des lignes de texte trop longues, imposant alors l'insertion de sauts de ligne à intervalle régulier ; enfin, ils peuvent supprimer les espaces. Ainsi, seuls les 95 caractères ASCII imprimables peuvent de manière « sure » être utilisés pour transmettre des données.

Quatre octets permettent de représenter 2³²=4 294 967 296 valeurs possibles. Cinq chiffres en base 85 fournissent 85⁵=4 437 053 125 valeurs possibles, ce qui suffit pour fournir une représentation unique pour chaque valeur possible de 32 bits. C'est aussi la plus petite base possible pour pouvoir représenter quatre octets en cinq caractères, car en base 84, cinq chiffres ne fournissent que 84⁵=4 182 119 424 valeurs représentables, c'est-à-dire moins que les 2³² valeurs à représenter.

Lors de l'encodage, chaque groupe de 4 octets est pris comme un nombre binaire de 32 bits, l'octet le plus significatif d'abord (Ascii85 utilise une convention gros-boutiste). Il est converti sous la forme d'un nombre de 5 chiffres en base 85, en divisant à plusieurs reprises par 85 et en prenant à chaque fois le reste de la division euclidienne. Ensuite, en partant du chiffre de poids le plus fort, à chaque chiffre est ajouté 33, puis est codé comme un caractère imprimable ASCII, ce qui donne un caractère ASCII de code compris entre 33 (!) et 117 (u).

Parce que les séries de données à zéro sont courantes, on fait une exception pour permettre leur compression : un groupe à zéro est codé comme un seul caractère z au lieu de !!!!!.

Les groupes de caractères dont la valeur décodée est supérieure à 2³² - 1 (encodés en s8W-!) provoquent une erreur de décodage, tout comme les caractères z au milieu d'un groupe. Un blanc entre caractères est ignoré ; il peut apparaître n'importe où pour permettre de respecter les limitations de longueur de ligne.

L'un des inconvénients de Ascii85 est que les données ainsi encodées peuvent contenir des caractères d'échappement, comme des barres obliques inversées ou des guillemets, qui ont une signification particulière dans de nombreux langages de programmation et dans certains protocoles basés sur du texte. D'autres encodages en base 85 comme Z85 sont conçus pour pouvoir être inclus de manière sure dans du code source[2].

Prenons ces deux célèbres vers de Nicolas Boileau :

Ce qui se conçoit bien s'énonce clairement, / Et les mots pour le dire viennent aisément.

S'il est initialement codé en utilisant les caractères ISO-Latin-1, ce texte peut être codé comme suit en Ascii85 :

<~6Y.B[F_Mt>AKYK$DWbqPF<G%,ASrW3-g>MeDI[6#@r,RfEb0*!DKIEP0-E]*+DbV1+Dl%=F!,F?F`JU@

AKYMtEb-A:Bk;1"ASuT4@;0fID.RU,/cYkO~>

S'il est codé de façon interne selon le codage UTF-8 le codage en Ascii85 est alors :

<~6Y.B[F_Mt>AKYK$DSrAjBlkJ,Bk;0)F!nl)DJsE&AKYK!@;0anD.RU,/0HSg7<BYgATJu2D

fg%CE,Tl>+DbU3A8-'q+EhI1DJj$'F<G"+F2OtoASuTB~>

Comme le dernier 4-tuple est incomplet selon le codage ISO-Latin-1, il faut le compléter avec trois octets à zéro :

Il n'y a pas lieu a priori de supprimer quoi que ce soit dans le résultat qui peut être décodé inversement tel quel pour retrouver le chaîne d'origine suivie de zéros binaires. Néanmoins, à ce propos, Adobe spécifie dans le langage PostScript si le groupe final comprend n (1, 2 ou 3 octets)  de données binaires l'algorithme ajoute 4-n zéros binaires afin de compléter le tuple de quatre octets. Puis l'algorithme est mis en œuvre normalement sans tenir compte de l'exception z. Puis il écrit les n+1 premiers octets du tuple résultant de cinq octets.

Comme le texte d'exemple ne contient aucune suite de 4 octets consécutifs à zéro, il n'illustre pas l'utilisation de l'abréviation z.

L'encodage Ascii85 est compatible avec MIME 7 bits et 8 bits, et fait moins grossir les fichiers que Base64.

Cependant, Ascii85 peut poser un problème de compatibilité, dans la mesure où il utilise les apostrophes ('), les guillemets (""), les signes 'inférieur à' (<) et 'supérieur à' (>) et les esperluettes (&). Les textes encodés en Ascii85 ne peuvent donc pas être utilisés tels quels dans les langages de balisage comme XML ou SGML : ils exigent d'y ajouter des caractères d'échappement.

Publiée le 1^er avril 1996, la RFC 1924[5] informative propose d'utiliser « une représentation compacte des adresses IPv6 ». Initiée par Robert Elz, cette RFC propose d'utiliser un ensemble de 85 caractères ASCII différent, et de faire toute l'arithmétique sur des nombres de 128 bits plutôt que 32 bits, en les convertissant en nombres de 20 chiffres en base 85 (les espaces intérieurs étant non autorisés).

Le jeu de caractères proposé est, dans l'ordre, 0–9, A–Z, a–z, puis les 23 caractères !#$%&()*+-;<=>?@^_`{|}~. Le nombre représentable le plus élevé, 2¹²⁸−1 = 74×85¹⁹ + 53×85¹⁸ + 5×85¹⁷ + ..., serait encodé en =r54lj&NUUO~Hi%c2ym0.

Ce jeu de caractères exclut les caractères "',./:[\] , ce qui le rend utilisable dans les chaînes JSON (où " et \ exigent un échappement). Cependant, pour les protocoles basés sur SGML, y compris notamment XML, les caractères <, > et & exigeraient malgré tout d'être échappés explicitement.

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Ascii85 » (voir la liste des auteurs).