Table de l'alphabet Base64

Les 64 caractères

Base64 lit l’entrée par blocs de 3 octets (24 bits) et les découpe en quatre nombres de 6 bits. Chaque nombre, de 0 à 63, est un index dans cette table. L’ordre est fixé par la RFC 4648 : majuscules de 0 à 25, minuscules de 26 à 51, chiffres de 52 à 61, puis + et /. La dernière colonne donne le code ASCII du caractère, c’est-à-dire ce qui est réellement stocké ou transmis.

Deux plages valent la peine d’être retenues. Tous les caractères de A à P (0 à 15) commencent par les bits 00, et tous ceux de w à / (48 à 63) par 11. Cela suffit pour décoder un caractère de tête quand vous vérifiez un préfixe à la main. Un exemple détaillé du découpage des bits se trouve dans le fonctionnement de Base64.

L’ordre de l’alphabet n’est pas l’ordre ASCII. En ASCII, + et / viennent en premier, puis les chiffres, les majuscules et enfin les minuscules. Trier des chaînes Base64 ne trie donc pas les octets sous-jacents : +A== (l’octet F8) passe avant AA== (l’octet 00). Si vous avez besoin de valeurs encodées qui se trient comme les octets bruts, utilisez base32hex de la RFC 4648 ou simplement l’hexadécimal.

L’alphabet URL-safe

+ et / ont tous deux un sens particulier dans les URL. + est décodé en espace dans les chaînes de requête et les données de formulaire, et / sépare les segments du chemin. Base64URL, défini à la section 5 de la RFC 4648, conserve les index 0 à 61 et remplace les deux derniers :

Tout le reste, y compris la disposition des bits, est identique : passer de l’un à l’autre revient à remplacer des caractères et à ajouter ou retirer le remplissage. Les JWT, de nombreux jetons d’API et les identifiants compatibles avec les noms de fichiers utilisent Base64URL, le plus souvent sans =. L’encodeur Base64URL le produit directement. La comparaison complète se trouve dans Base64 ou Base64URL.

Le caractère de remplissage

= (ASCII 0x3D) ne fait pas partie de l’alphabet de 64 caractères et n’encode jamais de données. Il sert uniquement à compléter le dernier groupe de 4 caractères quand la longueur de l’entrée n’est pas un multiple de 3 :

• 1 octet restant : 2 caractères de données plus ==.
• 2 octets restants : 3 caractères de données plus =.
• Aucun octet restant : pas de remplissage.

Une chaîne avec remplissage a donc toujours une longueur multiple de 4, et vous ne verrez jamais ===. Sans remplissage, la longueur divisée par 4 laisse un reste de 0, 2 ou 3, jamais 1. Le guide du remplissage explique quand = peut être omis et comment le rétablir.

Quels caractères apparaissent où

Quelques régularités découlent directement de la disposition des bits. Elles ont été vérifiées par force brute sur toutes les valeurs d’octets concernées.

Avant ==, vous ne verrez que A, Q, g ou w. Avec un octet restant, le deuxième caractère porte 2 bits de données suivis de 4 bits à zéro : son index vaut donc 0, 16, 32 ou 48. Avant un seul =, le troisième caractère se termine par 2 bits à zéro et fait donc partie de 16 caractères : A E I M Q U Y c g k o s w 0 4 8. Tout autre caractère à cette position signale un encodage non canonique, que les décodeurs stricts rejettent.

Des octets aléatoires utilisent les 64 caractères à parts égales. Chaque groupe de 6 bits de données aléatoires suit une distribution uniforme : les données chiffrées, les clés et les fichiers compressés donnent une répartition des caractères plate. Une répartition déséquilibrée indique que les données sont du texte ou ont une structure.

Du texte ASCII ne place jamais en tête les minuscules de g à z, les chiffres, + ou /. Le premier caractère de chaque groupe de 4 contient les 6 bits de poids fort d’un octet. En ASCII 7 bits, le bit de poids fort vaut 0, donc ce caractère est toujours compris entre A et f (index 0 à 31). Dans SGVsbG8gd29ybGQh (Hello world!), les groupes commencent par S, b, d et b.

Dans le Base64 d’un texte ASCII, + et / sont rares. Pour des octets inférieurs à 0x80, + ne peut apparaître qu’en quatrième position d’un groupe, quand le troisième octet est > ou ~. / ne peut y apparaître que si cet octet est ? ou le caractère de contrôle DEL. Voilà pourquoi Hi?> s’encode en SGk/Pg== et <b> en PGI+.

Les suites de A sont des octets nuls, les suites de / des 0xFF. AAAA correspond à trois octets 00, //// à trois octets FF. De longues séries de A sont typiques des formats binaires creux, du texte UTF-16 (Hello donne SABlAGwAbABvAA==) et des champs de longueur au début des clés SSH. D’autres motifs reconnaissables figurent dans les préfixes Base64 courants.

Autres alphabets Base64

Plusieurs systèmes ont gardé l’idée de 64 caractères pour 6 bits, mais avec d’autres caractères :

• IMAP remplace / par , parce que / sert couramment de séparateur de hiérarchie dans les noms de boîtes aux lettres. Un dossier nommé Entwürfe est stocké sous la forme Entw&APw-rfe.
• bcrypt place . et / en tête et garde les lettres avant les chiffres. Ses sels et ses hachages sont en Base64 dans cet alphabet, sans remplissage : c’est pourquoi un décodeur standard en tire des octets erronés.
• crypt(3) utilise ./0-9A-Za-z, qui suit l’ordre ASCII. Il range aussi les bits en partant du poids faible : même avec l’alphabet converti, un décodeur standard ne retrouvera pas les octets du hachage.
• uuencode et xxencode sont antérieurs à MIME. Les outils uuencode et xxencode lisent et écrivent les deux formats.

Pour les encodages dont l’alphabet a une autre taille, comme Base32, Base58 et Base85, voir Base64, hex, Base32, Base58 et Base85 comparés. Les termes employés ici sont définis dans le glossaire.

FAQ