Encodeur base85 : trois variantes, côte à côte

Qu’est-ce que le base85 ?

Le base85 loge des données binaires dans du texte imprimable à l’aide de 85 caractères différents. Quatre octets deviennent cinq caractères, et c’est là toute sa raison d’être : le base64 transforme trois octets en quatre, soit 33 % d’expansion, quand le base85 s’en tient à 25 %. Cette économie explique son adoption par PostScript et le PDF, et pourquoi il réapparaît partout où du binaire doit survivre à un canal texte.

L’ennui est que le base85 n’est pas un format unique. Au moins trois choses portent ce nom et aucune ne sait lire la sortie des autres. L’Ascii85 utilise les 85 caractères à partir du point d’exclamation, et c’est ce que produisent PostScript, le PDF et le btoa d’origine. Le Z85, spécifié par ZeroMQ, emploie un alphabet délibérément différent, choisi pour que la sortie se colle sans souci dans du code source. Et une troisième variante, celle que comprennent la plupart des bibliothèques, utilise l’alphabet de la RFC 1924.

Cette page encode vos octets avec les trois à la fois, pour que les écarts se voient au lieu de rester théoriques, et elle fonctionne aussi dans l’autre sens : donnez-lui une chaîne et elle montre ce que chaque variante croit y lire.

Comment l’utiliser

1. Donnez-lui des octets. En hexadécimal ou en texte, à votre convenance. Les exemples couvrent le vecteur de test de la spécification ZeroMQ elle-même, une série d’octets nuls et un octet isolé, chacun se comportant différemment selon les trois variantes.
2. Comparez les trois sorties. Elles apparaissent ensemble, avec une note sur ce qu’est chaque variante. L’Ascii85 a deux options qui valent l’essai : les délimiteurs Adobe et l’abréviation qui écrit quatre octets nuls sous la forme d’un simple z.
3. Ou passez à la lecture d’une chaîne. Collez du texte base85 et toutes les variantes capables de le décoder le feront, avec les octets que chacune produit. Quand deux d’entre elles divergent, la chaîne elle-même ne peut pas dire laquelle a raison.

Pourquoi changer de variante est dangereux

Une chaîne base85 ne porte aucune marque indiquant quelle variante l’a produite. Confiez-la au mauvais décodeur et il se passe l’une de deux choses : il la refuse, ou il l’accepte et vous rend d’autres octets sans se plaindre le moins du monde.

Mesuré sur cinq mille entrées aléatoires, décoder une sortie Ascii85 avec l’alphabet de la RFC 1924 renvoie des octets faux sans erreur dans environ 16 % des cas, et échoue le reste du temps. Le sens inverse se comporte pareil, à 16,6 %. Donc à peu près une fois sur six vous obtenez de la bouillie plausible au lieu d’un message vous signalant que quelque chose a mal tourné.

C’est l’exact inverse de ce que ce site a trouvé pour le base58, où les deux alphabets concurrents contiennent les mêmes 58 caractères dans un ordre différent. Là, une confusion décode toujours en silence, puisque tout caractère valide dans un alphabet l’est aussi dans l’autre. Les variantes du base85 emploient des jeux de caractères réellement distincts, si bien que la plupart du temps la confusion produit une erreur. Ces cinq fois sur six où l’échec est bruyant, c’est le format qui vous protège ; la fois restante explique pourquoi la variante doit être notée ailleurs que dans la chaîne.

Le Z85 est le plus strict des trois et le moins susceptible d’accepter ce qu’il ne devrait pas. Sa spécification exige que la longueur binaire soit divisible par quatre et celle du texte par cinq, et ne définit aucun remplissage, le laissant à l’appelant. Il refuse donc purement et simplement des entrées que les deux autres compléteraient, et c’est pourquoi l’un des exemples proposés ici s’encode en Ascii85 et avec l’alphabet de la RFC 1924, et se fait refuser par le Z85.

La variante qui n’est pas ce que son nom annonce

On appelle généralement la troisième variante base85 de la RFC 1924, et ce nom induit en erreur. La RFC 1924 porte sur les adresses IPv6. Sa section d’encodage indique de traiter une adresse comme un unique entier de 128 bits, d’écrire cet entier en base 85 et de le représenter avec 85 caractères ASCII, ce qui donne exactement vingt chiffres. Elle ne décrit aucune façon d’encoder un flux d’octets, et nulle part le document ne mentionne de traiter quatre octets à la fois.

Ce que les bibliothèques implémentent sous ce nom, c’est l’alphabet de la RFC auquel on a ajouté le groupement par quatre octets de l’Ascii85. C’est parfaitement raisonnable à construire, et ce n’est pas ce que la RFC spécifie. Le troisième mode de cette page implémente le véritable algorithme de la RFC : vous pouvez donc encoder une adresse réelle et obtenir les vingt chiffres que le document décrit.

La RFC mérite d’ailleurs d’être lue pour elle-même. Elle est datée du 1er avril 1996, classée Informational, et annonce dès ses premières lignes qu’elle ne spécifie aucune norme de l’internet. Sa section sur le choix de 85 passe en revue la base 84 puis la base 94 avant de trancher, et explique que le jeu de caractères a été choisi avec un soin considérable afin de laisser la ponctuation libre pour délimiter les adresses. Tirez vos propres conclusions de la date.

Ce que cela ne peut pas vous dire

Cela ne peut pas vous dire quelle variante a produit une chaîne qu’on vous a remise. C’est précisément le problème : rien dans l’encodage ne le consigne. Si une chaîne se décode proprement avec deux variantes, les deux réponses sont affichées et le choix vous revient, guidé par la provenance de la chaîne et non par son contenu.

Les trois variantes présentées ici sont celles d’usage courant, pas toutes celles qui existent. L’Ascii85 en particulier a des dialectes : le programme btoa disposait d’une abréviation pour quatre espaces en plus de celle pour quatre octets nuls, et certains outils coupent la sortie à une colonne fixe quand d’autres non. Ce sont des variations à l’intérieur de l’Ascii85 plutôt que des formats distincts, mais elles suffisent à faire diverger deux implémentations sur le texte exact.

Enfin le base85 convient mal partout où la sortie doit survivre à une URL, à un nom de fichier ou à une commande shell. Toutes les variantes usent abondamment de la ponctuation, et les caractères diffèrent de l’une à l’autre : un texte sûr dans un contexte peut demander un échappement dans un autre. C’est le problème que le Z85 a cherché à régler, et la raison pour laquelle son alphabet écarte les guillemets et la barre oblique inverse qu’il faudrait sinon échapper à l’intérieur d’une chaîne de code.

Pourquoi est-ce gratuit ?

Un changement de base est de l’arithmétique, et il s’exécute dans votre navigateur. Aucun serveur n’intervient, il n’y a donc rien à facturer ni de compte à créer.

Rien n’est envoyé. Les octets que vous collez ne quittent pas l’onglet.