Ascii85 - Ascii85

Ascii85 , également appelé Base85 , est une forme d' encodage binaire en texte développée par Paul E. Rutter pour l' utilitaire btoa . En utilisant cinq ASCII des caractères pour représenter quatre octets de données binaires (fabrication de la taille codée une / 4 supérieur à l'original, en supposant que huit bits par caractère ASCII), il est plus efficace que uuencode ou base64 , qui utilisent quatre caractères pour représenter trois octets de données ( 13 augmentation, en supposant huit bits par caractère ASCII).

Ses principales utilisations modernes sont dans Adobe de PostScript et Portable Document Format formats de fichiers, ainsi que dans le correctif encodage pour les fichiers binaires utilisés par Git .

Aperçu

Le besoin fondamental d'un codage binaire-texte vient d'un besoin de communiquer des données binaires arbitraires sur des protocoles de communication préexistants qui ont été conçus pour transporter uniquement du texte lisible par l'homme en anglais . Ces protocoles de communication ne peuvent être sûrs que sur 7 bits (et à l'intérieur de ceux-ci, évitez certains codes de contrôle ASCII), et peuvent nécessiter des sauts de ligne à certains intervalles maximum, et peuvent ne pas conserver d' espace blanc . Ainsi, seuls les 94 caractères ASCII imprimables sont "sûrs" à utiliser pour transmettre des données.

Quatre octets peuvent représenter 2 32  = 4 294 967 296 valeurs possibles. Cinq chiffres de base -85 fournissent 85 5  = 4 437 053 125 valeurs possibles, suffisamment pour fournir une représentation unique pour chaque valeur 32 bits possible. Étant donné que cinq chiffres de base 84 ne fournissent que 84 5  = 4 182 119 424 valeurs représentables, 85 est la base intégrale minimale possible qui représentera quatre octets en cinq caractères, d'où son choix.

Lors de l'encodage, chaque groupe de 4 octets est considéré comme un nombre binaire de 32 bits, l'octet de poids fort en premier (Ascii85 utilise une convention big-endian ). Ceci est converti, en divisant à plusieurs reprises par 85 et en prenant le reste, en 5 chiffres de base-85. Ensuite, chaque chiffre (encore une fois, le plus significatif en premier) est codé en tant que caractère imprimable ASCII en y ajoutant 33, donnant les caractères ASCII 33 (" !") à 117 (" u").

Étant donné que les données entièrement nulles sont assez courantes, une exception est faite pour des raisons de compression des données , et un groupe entièrement nul est encodé sous la forme d'un seul caractère " z" au lieu de " !!!!!".

Les groupes de caractères qui décodent à une valeur supérieure à 2 32 − 1 (encodés comme " s8W-!") provoqueront une erreur de décodage, tout comme les caractères " z" au milieu d'un groupe. L'espace blanc entre les caractères est ignoré et peut apparaître n'importe où pour tenir compte des limitations de longueur de ligne.

Un inconvénient d'Ascii85 est que les données codées peuvent contenir des caractères d'échappement tels que la barre oblique inverse et les guillemets, qui ont une signification particulière dans de nombreux langages de programmation et dans certains protocoles textuels. D'autres encodages base-85 comme Z85 et RFC 1924 sont conçus pour être sûrs dans le code source.

Histoire

version btoa

Le programme btoa d'origine a toujours encodé des groupes complets (en remplissant la source si nécessaire), avec une ligne de préfixe de "xbtoa Begin" et une ligne de suffixe de "xbtoa End", suivie de la longueur du fichier d'origine (en décimal et hexadécimal ) et trois 32 -bits de contrôle . Le décodeur doit utiliser la longueur du fichier pour voir dans quelle mesure le groupe était rempli. La proposition initiale d'encodage btoa utilisait un alphabet d'encodage commençant par le caractère espace ASCII jusqu'à "t" inclus, mais cela a été remplacé par un alphabet d'encodage de "!" à "u" pour éviter "des problèmes avec certains expéditeurs (enlever les blancs de fin)". Ce programme a également introduit la zforme abrégée spéciale " " pour un groupe tout à zéro. La version 4.2 a ajouté une yexception " " pour un groupe de tous les caractères d' espace ASCII (0x20202020).

Version ZMODEM

"ZMODEM Pack-7 encoding" encode des groupes de 4 octets en groupes de 5 caractères ASCII imprimables d'une manière similaire, ou éventuellement de la même manière qu'Ascii85. Lorsque les programmes ZMODEM envoient des fichiers de données 8 bits pré-compressés sur des canaux de données 7 bits , ils utilisent "l'encodage ZMODEM Pack-7".

Version d'Adobe

Adobe a adopté l'encodage de base btoa, mais avec de légères modifications, et lui a donné le nom d'Ascii85. Les caractères utilisés sont les caractères ASCII 33 ( !) à 117 ( u) inclus (pour représenter les chiffres de base 85 de 0 à 84), ainsi que la lettre z(comme cas particulier pour représenter une valeur 0 de 32 bits) et l'espace blanc est ignoré. Adobe utilise le délimiteur " ~>" pour marquer la fin d'une chaîne encodée en Ascii85 et représente la longueur en tronquant le groupe final : Si le dernier bloc d'octets source contient moins de 4 octets, le bloc est complété avec jusqu'à 3 octets nuls avant codage. Après l'encodage, autant d'octets ajoutés que de remplissage sont supprimés de la fin de la sortie.

L'inverse est appliqué lors du décodage : le dernier bloc est rempli de 5 octets avec le caractère Ascii85 u, et autant d'octets ajoutés que de remplissage sont omis de la fin de la sortie (voir exemple).

REMARQUE : le remplissage n'est pas arbitraire. La conversion du binaire en base 64 ne regroupe que les bits et ne les modifie pas ni leur ordre (un bit haut en binaire n'affecte pas les bits bas dans la représentation base64). Lors de la conversion d'un nombre binaire en base85 (85 n'est pas une puissance de deux), les bits de poids fort affectent les chiffres de base85 d'ordre inférieur et inversement. Le remplissage du binaire bas (avec des bits zéro) lors de l'encodage et du remplissage de la valeur de base85 haut (avec us) lors du décodage garantit que les bits de poids fort sont préservés (le remplissage par zéro dans le binaire laisse suffisamment de place pour qu'un petit ajout soit piégé et là n'y a pas de « report » sur les bits de poids fort).

Dans les blocs codés en Ascii85, les caractères d'espacement et de saut de ligne peuvent être présents n'importe où, y compris au milieu d'un bloc de 5 caractères, mais ils doivent être ignorés en silence.

La spécification d'Adobe ne prend pas en charge l' yexception.

Exemple pour Ascii85

Une citation du Léviathan de Thomas Hobbes :

L'homme se distingue, non seulement par sa raison, mais par cette passion singulière des autres animaux, qui est une convoitise de l'esprit, qui par une persévérance de plaisir dans la génération continue et infatigable de la connaissance, dépasse la courte véhémence de tout plaisir charnel. .

S'il est initialement encodé en US-ASCII, il peut être réencodé en Ascii85 comme suit :

<~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~>
Contenu textuel M une m ... s vous r e
ASCII 77 97 110 32 ... 115 117 114 101
Modèle de bits 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
Valeur 32 bits 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
Base 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

Étant donné que le dernier 4-uplet est incomplet, il doit être complété par trois octets zéro :

Contenu textuel . \0 \0 \0
ASCII 46 0 0 0
Modèle de bits 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
Valeur 32 bits 771 751 936 = 14×85 4 + 66×85 3 + 56×85 2 + 74×85 + 46
Base 85 (+33) 14 (47) 66 (99) 56 (89) 74 (107) 46 (79)
ASCII / c Oui k O

Comme trois octets de remplissage ont dû être ajoutés, les trois derniers caractères « YkO » sont omis de la sortie.

Le décodage se fait à l'inverse, sauf que le dernier 5-uplet est rempli de caractères 'u' :

ASCII / c vous vous vous
Base 85 (+33) 14 (47) 66 (99) 84 (117) 84 (117) 84 (117)
Valeur 32 bits 771 955 124 = 14×85 4 + 66×85 3 + 84×85 2 + 84×85 + 84
Modèle de bits 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
Contenu textuel . [ ETX ] [ EM ] ´ ( ASCII étendu )

Étant donné que l'entrée devait être complétée par trois octets « u », les trois derniers octets de la sortie sont ignorés et nous nous retrouvons avec la période d'origine.

La phrase d'entrée ne contient pas 4 octets zéro consécutifs, donc l'exemple ne montre pas l'utilisation de l'abréviation 'z'.

Compatibilité

L'encodage Ascii85 est compatible avec MIME 7 bits et 8 bits , tout en ayant moins de surcharge que Base64 .

Un problème de compatibilité potentiel d'Ascii85 est que les guillemets "simples" et "doubles", les crochets <angle> et les esperluettes (&) ne peuvent pas être utilisés sans échappement dans les langages de balisage comme XML ou SGML.

Version RFC 1924

Publiée le 1er avril 1996 , la RFC d'  information 1924 : "A Compact Representation of IPv6 Addresses" de Robert Elz propose un codage en base-85 des adresses IPv6 . Cela diffère du schéma utilisé ci-dessus en ce qu'il propose un ensemble différent de 85 caractères ASCII et propose de faire toutes les opérations arithmétiques sur le nombre 128 bits, en le convertissant en un seul nombre base-85 à 20 chiffres (espaces internes non autorisés) , plutôt que de le diviser en quatre groupes de 32 bits.

Le jeu de caractères proposé est, dans l'ordre, 09, AZ, az, puis les 23 caractères !#$%&()*+-;<=>?@^_`{|}~. L'adresse représentable la plus élevée possible, 2 128 -1 = 74 × 85 19  + 53 × 85 18  + 5 × 85 17  + ..., serait codée sous la forme =r54lj&NUUO~Hi%c2ym0.

Ce jeu de caractères exclut les caractères "',./:[\] , ce qui le rend approprié pour une utilisation dans les chaînes JSON (où "et \nécessiterait un échappement). Cependant, pour les protocoles basés sur SGML , notamment XML , des échappements de chaîne peuvent toujours être nécessaires (pour s'adapter à <, >et &).

Voir également

Les références

Liens externes