Qu’est-ce que le Base64 ?
Le Base64 réécrit les octets à l’aide de soixante-quatre caractères lisibles, pour que les données survivent sur un canal conçu pour du texte : le corps d’un e-mail, une chaîne JSON, un attribut XML, une URL. Chaque trois octets deviennent quatre caractères, d’où le nom : l’alphabet compte soixante-quatre symboles, et chacun porte exactement six bits.
C’est un encodage de transport, ni une mesure de sécurité ni une étape de compression. La sortie est environ un tiers plus grande que l’entrée, et quiconque possède la chaîne peut la reconvertir directement. Si vous voulez savoir si des données ont été altérées, c’est un hash (Générateur de hash) ; si vous voulez qu’elles restent secrètes, c’est du chiffrement. Le Base64 ne fait ni l’un ni l’autre.
Le seul nombre à retenir : trois octets d’entrée deviennent quatre caractères de sortie. Tout le reste de cette page en découle. Quatre caractères portent vingt-quatre bits, et vingt-quatre bits correspondent exactement à trois octets : aucune donnée n’est donc jamais perdue ni inventée, sauf à la toute fin, où l’entrée peut ne pas remplir le dernier groupe de trois.
Les cinq alphabets que cette page peut utiliser
Les deux premières lignes sont des normes et les trois dernières des conventions nées autour d’Unix. Les cinq portent le même six bits par caractère et ne diffèrent que par les soixante-quatre caractères qui les portent : les mêmes octets donnent donc cinq chaînes différentes. Rien dans une chaîne n’indique quel alphabet l’a produite, c’est pourquoi le sélecteur d’alphabet est par défaut sur le standard, et la case URL-safe est un raccourci vers la deuxième ligne.
Comment la page choisit un candidat : le sélecteur est la valeur par défaut dans les deux sens. Au décodage, le panneau de droite lit aussi la chaîne elle-même : - et _ ne peuvent provenir que de l’alphabet URL-safe, + ou / ne peuvent provenir que de l’alphabet standard, et un / ou un . en début de chaîne renvoie aux deux alphabets Unix. Chaque alphabet capable de lire l’entrée courante y figure, avec la raison pour laquelle il est, ou non, un candidat.
Retour à la ligne : 76 et 64 caractères
Le MIME demandait un Base64 qui tienne dans un e-mail sans qu’aucune ligne ne devienne déraisonnablement longue, et a retenu 76 caractères par ligne, séparées par CRLF. Les fichiers PEM, qui enveloppent les certificats et les clés, utilisent 64. Les retours à la ligne ne font pas partie des données : un décodeur les supprime et rassemble les lignes avant tout autre traitement, si bien qu’une chaîne découpée et une chaîne non découpée se décodent exactement en les mêmes octets. Chaque ligne, sauf la dernière, contient un nombre entier de groupes de quatre caractères, ce qui rend leur réassemblage sûr.
Cette page laisse la sortie sur une seule ligne, sauf si vous choisissez une largeur, et le décodeur accepte l’entrée avec ou sans retours à la ligne. Les retours que cette page écrit sont de simples sauts de ligne (LF), ce que peut contenir une zone de texte ; les corps de messages MIME utilisent traditionnellement un retour chariot avant chaque saut de ligne, et tous les décodeurs en usage acceptent les deux.
Le remplissage, et pourquoi on peut le retirer
Lorsque l’entrée n’est pas un multiple de trois octets, le dernier groupe de quatre caractères est incomplet, et un ou deux caractères = le complètent. Ils ne portent aucune donnée : ils indiquent seulement combien des quatre caractères sont réels. Un décodeur peut le déduire de la longueur, ce qui explique pourquoi le Base64 URL-safe omet traditionnellement le remplissage : un = est peu pratique dans une URL ou un nom de fichier, et certains systèmes l’encodent en pourcentage.
La case à cocher de la ligne d’options conserve le remplissage lorsque l’alphabet URL-safe est sélectionné. Rien d’autre ne change : les caractères qui portent les données sont identiques dans les deux cas.
Idées reçues courantes
- « Le Base64 cache les données. » Non. C’est une substitution sans clé, et le principe même est que n’importe quel lecteur peut l’inverser. Encoder un mot de passe ou un jeton en Base64 ne change rien à qui peut le lire.
- « Le Base64 compresse. » C’est l’inverse : chaque trois octets d’entrée deviennent quatre caractères de sortie, si bien que le texte est un tiers plus gros que les données qu’il porte.
- « Les retours à la ligne font partie de la valeur. » Ce sont des éléments de présentation. Les ajouter ou les retirer ne modifie jamais les octets restitués.
- « URL-safe désigne un encodage différent. » C’est le même encodage avec deux caractères échangés :
+ devient - et / devient _, si bien que la chaîne peut se placer dans un chemin d’URL ou une valeur de requête sans échappement.
- « Une chaîne qui se décode doit être du Base64 valide. » Toute chaîne de caractères de l’alphabet est du Base64 valide, car toute combinaison de valeurs de six bits forme une suite d’octets valide. Une chaîne ne se révèle fausse qu’à l’étape suivante, lorsque ces octets sont confrontés au format qu’ils étaient censés avoir.
- « Le remplissage indique quel alphabet a été utilisé. » Non, et dans la plupart des cas les caractères non plus : les alphabets standard et URL-safe s’accordent sur soixante-deux de leurs soixante-quatre symboles, si bien qu’une chaîne courte se lit souvent de la même façon dans les deux.
Questions fréquentes
Pourquoi une chaîne Base64 se termine-t-elle parfois par un = et parfois par deux ? Un signe signifie que le dernier groupe porte trois caractères réels, soit deux octets d’entrée ; deux signes signifient qu’il en porte deux, soit un octet d’entrée. Pas de = signifie que la longueur de l’entrée était un multiple de trois.
Le Base64 peut-il représenter des fichiers binaires quelconques ? Oui, et c’est son principal usage. Cette page traite l’entrée comme du texte UTF-8 ; l’outil dédié Fichier vers Base64 lit les octets bruts lorsque vous voulez encoder autre chose que du texte.
Quel alphabet utiliser dans une API ? Celui que documente le destinataire. S’il indique URL-safe, utilisez-le ; s’il ne dit rien et que la valeur voyage dans une URL, le URL-safe sans remplissage est le choix sûr.
La sortie est-elle sensible à la casse ? Totalement. a et A sont deux valeurs différentes, ce qui fait que le Base64 supporte bien moins gracieusement un caractère mal saisi que ne le font le Base32 ou le Crockford Base32.
