Décodage à partir du format Base64

Aperçu

Base64 est une métamorphose réversible, et cet outil en est la moitié du retour : il prend le texte imprimable produit par un encodeur et le retransforme en données d'origine. Collez une chaîne, choisissez les réglages qui correspondent à sa provenance, et le résultat décodé est prêt à être lu ou copié. Quand la charge utile est un binaire, comme une image ou une archive, son texte Base64 vit dans un simple fichier : le formulaire fichier de cette page prend ce fichier et restitue le binaire d'origine en téléchargement. L'encodeur correspondant se trouve sur le site sœur, à un lien de là.

Options avancées

• Jeu de caractères : Base64 transporte des octets, pas des lettres, aussi le résultat décodé ne se lit correctement que si vous savez dans quel jeu de caractères les données étaient stockées avant l'encodage. Choisissez celui qui correspond à votre source : UTF-8 pour un texte moderne, Windows-1252 ou une variante ISO-8859 pour des documents plus anciens, ou AUTO-DETECT pour laisser l'outil décider (il affiche ce qu'il a retenu juste à côté de la liste, et part sur UTF-8 quand il ne sait pas trancher). Si la sortie a l'air d'un alphabet brouillé, c'est le premier réglage à toucher. Les fichiers sont exemptés : les données binaires sont décodées telles quelles, sans aucune conversion.
• Décoder chaque ligne séparément : Par défaut, toute l'entrée forme une seule charge utile continue : les retours à la ligne et les espaces sont retirés avant le décodage, aussi une chaîne coupée sur plusieurs lignes, copiée telle quelle depuis un e-mail, fonctionne tout simplement, et les caractères sûrs pour les URL - et _ sont acceptés à la place de + et /. Cochez cette case quand l'entrée est une liste d'entrées indépendantes : chaque ligne est alors décodée pour elle-même, et les résultats reviennent un par ligne. Le formulaire fichier propose la même option.
• Mode en temps réel : Activez-le et le décodage se fait dans votre navigateur pendant que vous tapez, relancé à chaque frappe de touche, sans rien envoyer à nos serveurs. Il respecte l'option par ligne et ne fonctionne qu'avec UTF-8, aussi la liste des jeux de caractères reste verrouillée tant qu'il est actif, et le bouton de décodage reste désactivé jusqu'à ce que vous le désactiviez.

Sûr et sécurisé

Tout se passe sur une connexion HTTPS chiffrée, et rien de ce que vous soumettez n'est conservé : les fichiers téléversés sont supprimés dès leur traitement, et le résultat téléchargeable disparaît juste après votre première tentative de téléchargement ou au bout de 15 minutes d'inactivité, selon ce qui arrive d'abord. Le contenu de ce que vous envoyez n'est jamais stocké ; le seul traitement au-delà de la conversion est une analyse de sécurité des fichiers téléversés, qui existe pour bloquer les contenus malveillants ou inappropriés. Avec le mode en temps réel actif, votre texte ne quitte jamais le navigateur. Tous les détails se trouvent dans notre politique de confidentialité, reliée dans le pied de page ci-dessous.

Entièrement gratuit

Tout sur cette page est gratuit - la liste complète des jeux de caractères, les téléversements de fichiers, et le mode en temps réel compris. Pas de compte, pas de logiciel à installer, pas de mur payant : pour une tâche aussi petite, c'est exactement comme ça que cela devrait se passer.

Base64 expliqué

Certaines données tout simplement ne peuvent pas voyager sur un canal réservé au texte : une photo, une archive, une empreinte, un morceau de binaire qui ferait s'étouffer une connexion e-mail 7 bits. Base64 est le traducteur pour des moments comme celui-ci. Il réécrit n'importe quelle suite d'octets en texte ordinaire, imprimable, pour que la donnée puisse se loger dans le corps d'un e-mail, dans un document JSON, dans un fichier XML ou dans une URL, et arrive exactement comme elle est partie. La traduction est parfaitement réversible : chaque octet revient, dans le même ordre, sans rien perdre en chemin.

Le format entier tient en une phrase : trois octets en entrée, quatre caractères en sortie. Le prix à payer est un résultat environ un tiers plus gros que l'original. La récompense, c'est une chaîne qui a l'air du texte, qui se comporte comme du texte, et qui survit aux canaux qui détruiraient des octets bruts. Et il vaut mieux préciser d'emblée ce que Base64 n'est pas : ce n'est pas du chiffrement, et ce n'est pas de la compression. C'est une métamorphose réversible, et c'est toute sa mission.

Pourquoi 64, et pourquoi ces caractères

Un octet tient 8 bits, mais les anciens canaux texte, l'e-mail en tête, ne transportaient l'ASCII 7 bits qu'en toute sécurité. L'astuce est de choisir un alphabet de caractères imprimables qui survit à n'importe quel trajet de ce genre, et de le dimensionner pour que le calcul tombe juste. Avec 64 caractères, chaque caractère encodé porte exactement 6 bits, et 24 se divise aussi bien par 8 (l'octet) que par 6 (le caractère) : trois octets en entrée deviennent quatre caractères en sortie, sans reste. Le nom n'est que la base de ce calcul de caractères, comme la base 10 pour nos chiffres.

L'alphabet standard, ce sont les 62 caractères alphanumériques, de A à Z, de a à z et de 0 à 9, avec + et / pour les deux derniers. La spécification ajoute un 65e caractère, =, qui n'appartient pas du tout à l'alphabet : il n'apparaît qu'en fin de chaîne, en bourrage. Le choix est délibéré. L'ensemble complet est imprimable ; il est commun à tous les systèmes texte ; et la spécification MIME note qu'il s'épelle de façon identique dans toutes les versions de l'ISO 646, y compris US-ASCII, et dans toutes les versions d'EBCDIC. C'est cette dernière propriété qui garde les données intactes lorsqu'elles traversent l'ancienne machinerie d'Internet, qui ne gérait pas les 8 bits.

L'encodage, pas à pas

L'encodeur est une chaîne de montage en quatre étapes. Il lit l'entrée trois octets à la fois et fusionne chaque triplet en une seule chaîne de 24 bits. Cette chaîne est coupée en quatre morceaux de 6 bits. Chaque morceau est un nombre de 0 à 63, et chaque nombre est repéré dans le tableau ci-dessus. Quatre nombres en entrée, quatre caractères en sortie.

Regardez-le en action sur le mot foo, qui arrive sous la forme des valeurs d'octet 102, 111 et 111 (hexadécimal 66, 6F, 6F). Posés bout à bout, les 24 bits sont 01100110 01101111 01101111. Coupés par six, on obtient 011001, 100110, 111101 et 101111, soit 25, 38, 61 et 47. Le tableau dit que ce sont Z, m, 9 et v, donc foo s'encode en Zm9v, et n'importe quel décodeur Base64 du monde le retransformera en les trois octets d'origine.

Le reste de l'entrée est traité de la même façon, triplet après triplet, jusqu'à ce qu'il n'en reste plus. Seul le groupe final, lorsqu'il contient moins de trois octets, a besoin d'un coup particulier.

Le bourrage : le = à la fin

L'entrée est toujours un nombre entier d'octets, mais trois ne le divise pas toujours exactement. Quand il reste un ou deux octets à la queue, l'encodeur doit tout de même terminer un groupe complet de quatre caractères. Il remplit les bits manquants de zéros, fait les recherches comme d'habitude, et remplace les caractères que les bits de bourrage auraient produits par des signes =. Exactement trois fins sont possibles :

Ainsi fo, deux octets, devient Zm8=, et le f solitaire devient Zg==, tandis que foo n'a besoin d'aucun bourrage. Le décodeur sait exactement quoi faire avec les bourrages : chaque = signifie huit bits de zéro de plus à jeter. Les bourrages ne se trouvent qu'en toute fin de chaîne, et ils ne sont jamais plus de deux. La spécification MIME en fait même une fonctionnalité : puisque = ne peut apparaître nulle part ailleurs, une charge utile bourragée annonce sa propre fin, et le destinataire peut ainsi voir que les données n'ont pas été tronquées pendant le transit. Et pour le cas le plus petit : l'entrée vide s'encode en sortie vide. Même le néant a droit à un aller-retour parfait.

Le décodage : la chaîne de montage en marche arrière

Décoder, c'est la même machine qui tourne à l'envers, et c'est tout aussi mécanique. Prenez quatre caractères, cherchez les vrais (un bourrage tient lieu de six zéros), écrivez les 24 bits, et rendez les 16 premiers bits s'il y a un bourrage, ou les 24 s'il n'y en a aucun. Quatre caractères en entrée, trois octets en sortie ; deux octets en sortie avec un bourrage ; un octet en sortie avec deux. Les bits de zéro ajoutés par l'encodeur sont la seule chose jetée, et chaque autre bit est exactement celui qui est entré. C'est ce que réversible veut vraiment dire ici : le format lui-même est sans perte, et les seules choses qui peuvent nuire à vos données sont un canal qui corrompt la chaîne, ou un décodeur qui abandonne en silence.

C'est pourquoi la norme est stricte sur un point : les caractères qui ne font pas partie de l'alphabet. La RFC 4648 dit qu'un décodeur doit rejeter une charge utile qui porte un caractère quelconque en dehors des 64, à moins que la spécification qui l'entoure ne l'autorise explicitement. La raison est pratique, pas pointilleuse. Un décodeur qui avale en silence des caractères étrangers peut être trompé : les caractères introduits en fraude deviennent un canal latéral caché, et ce tour a servi à cacher des données aux filtres et à sonder les bogues des décodeurs. L'exception célèbre est MIME lui-même, qui précède la norme et dit le contraire : ignorez tous les caractères en dehors de l'alphabet, et c'est ainsi que les retours à la ligne passent dans une pièce jointe d'e-mail. Quand vous validez vous-même l'entrée, c'est la règle moderne qui est la bonne : si votre chaîne contient un @, un espace ou quoi que ce soit d'autre qui n'est pas dans le tableau, ce n'est pas du Base64 propre.

Retours à la ligne et règle des 76 caractères

Vous croiserez souvent du Base64 coupé en lignes, et l'habitude vient de l'e-mail. L'ancienne machinerie SMTP avait des limites de longueur de ligne, aussi le MIME coupe la charge utile à 76 caractères par ligne, avec un retour à la ligne CRLF, et l'ancien format PEM, celui qui transporte les certificats et les clés, coupe à 64. La règle de la RFC 4648, pour le code neuf, est l'inverse : n'ajoutez aucun retour à la ligne, sauf si le format que vous implémentez le demande. En pratique, le décodeur s'en fiche. Un retour à la ligne n'est qu'un caractère en dehors de l'alphabet, aussi une charge utile coupée en MIME, un bloc PEM et une seule longue chaîne non coupée se décodent tous en les mêmes octets. Si vous collez du Base64 d'où que ce soit, retirez d'abord les retours à la ligne, et c'est réglé.

Le coupage a un petit prix, qui se voit dans le calcul des tailles. Sans retours à la ligne, le Base64 fait exactement quatre fois un tiers de l'original, environ 33 % plus gros. Coupé à 76 caractères avec des retours CRLF, il fait environ 37 % plus gros, ce qui explique pourquoi un fichier censé faire 100 KB arrive souvent en à peu près 137 KB de texte. Le compte y est toujours.

Base64URL : le jumeau sûr pour les URL

L'alphabet standard a deux caractères qui n'aiment pas les URL. Un + dans une chaîne de requête se lit traditionnellement comme un espace, et / est un séparateur de chemin, aussi une chaîne Base64 brute dans une URL a besoin d'un échappement en pourcentage pour les deux, en plus des bourrages =. La section 5 de la RFC 4648 définit la solution : l'alphabet sûr pour les URL et les noms de fichiers, où + devient - et / devient _. Les bourrages disparaissent généralement aussi, car ceux qui manquent se déduisent de la longueur. La RFC est catégorique : il ne faut pas appeler ça du simple Base64 ; c'est un encodage différent, généralement écrit base64url.

En pratique, les deux ne se séparent que d'un seul échange, dans le sens dangereux. Donnez une chaîne base64url à un décodeur standard, et ça se gâte, car - et _ ne sont pas dans l'alphabet standard : un décodeur tolérant les jette et renvoie une chaîne d'octets plus courte et fausse - ou, quand le reste est trop court pour tenir seul, une erreur - tandis qu'un décodeur strict rejette toute la charge utile. La bonne danse, c'est de rééchanger - en + et _ en /, de compléter les bourrages manquants, et seulement alors de décoder. C'est le dialecte que l'on rencontre dans les JSON Web Tokens (JWT), les chaînes d'état OAuth et les identifiants d'un certain très grand site vidéo.

Un guide de terrain express

Avant de sortir un outil, vous pouvez lire une bonne partie de la chaîne vous-même. Quelques vérifications suffisent à savoir si une charge utile est du Base64 ou pas, et ce qu'elle cache :

• Regardez les caractères. Le Base64 standard n'utilise que A à Z, a à z, 0 à 9, + et / ; le jumeau sûr pour les URL utilise - et _ à la place de ces deux-là. Tout autre symbole, ou un espace égaré, veut dire que ce n'est pas du Base64 propre.
• Vérifiez les bourrages. Les signes =, s'ils sont présents, ne se trouvent qu'en toute fin de chaîne, et ils ne sont jamais plus de deux. Un bourrage au milieu de la chaîne est un signal d'alerte.
• Comptez la longueur. Avec bourrage, la longueur est toujours un multiple de 4. Sans bourrage, la longueur divisée par 4 laisse un reste de 0, 2 ou 3. Un reste de 1 est impossible, car un seul caractère ne porte que 6 bits et un octet en demande 8.
• Estimez la taille. Chaque groupe de 4 caractères contient 3 octets, moins un octet par signe =. Ainsi Zm9vYmFy, huit caractères sans bourrage, fait 6 octets, et Zm9vYg==, huit caractères avec deux bourrages, en fait 4.

Une dernière astuce de terrain, et la plus utile. L'encodeur doit mettre les bits de bourrage à zéro, mais un décodeur tolérant ne les vérifie pas. La charge utile Zg== se décode en l'unique octet f, et Zh== aussi : les bits de poids faible du dernier caractère sont du bourrage dans les deux cas, et les deux forment donc le même octet. La norme appelle la version à bits nuls la forme canonique, ce qui permet aux décodeurs stricts de rejeter l'autre. Deux chaînes, une seule charge utile. Si deux systèmes ne sont pas d'accord sur une valeur Base64, les bits de bourrage sont un bon endroit pour commencer à chercher.

Ce que Base64 n'est pas

• Ce n'est pas du chiffrement. Ni clé ni secret ; n'importe qui peut retransformer une chaîne Base64 en octets en une seconde. La RFC cite même des incidents réels où des gens ont signalé des échanges de protocole contenant un mot de passe « encodé », certains convaincus que l'encodage le cachait. Si les données sont sensibles, protégez-les avec de vrai chiffrement avant de les encoder, pas après.
• Ce n'est pas de la compression. Ça va dans l'autre sens : le résultat est environ 33 % plus gros que l'entrée, et encore plus une fois les retours à la ligne ajoutés. Le Base64 vous offre la sécurité du texte, et il vous la facture en taille.
• Ce n'est pas un jeu de caractères. Base64 transporte des octets, pas des lettres. Il ne sait pas, et s'en fiche, que ces octets soient du texte UTF-8, un encodage hérité à un octet ou un JPEG. La question « quel jeu de caractères est-ce ? » se pose avant l'encodage et après le décodage, jamais dedans.
• Ce n'est pas un encodage unique. Le nom recouvre une famille : l'alphabet standard, le jumeau sûr pour les URL, les charges utiles coupées à 76 ou 64 caractères, les variantes qui sautent les bourrages, et une poignée d'originals (IMAP, par exemple, utilise une virgule à la place du / de l'alphabet pour encoder les noms de boîtes aux lettres internationaux). Quand deux systèmes ne sont pas d'accord sur une charge utile, c'est souvent une différence de dialecte qui est en cause.

Les petits caractères

Les sources primaires sont courtes et lisibles. La RFC 4648, Les encodages de données Base16, Base32 et Base64 (2006), est la norme actuelle : les deux alphabets, les règles de bourrage et de retours à la ligne, les règles de stricte observance, et un jeu de vecteurs de test officiels, comme foo devenant Zm9v, contre lesquels les implémentations se testent. Derrière elle se tient la RFC 2045, la spécification MIME de 1996 d'où viennent la règle de la ligne de 76 caractères et la tolérance aux caractères égarés, et la RFC 1421, la spécification obsolète de Privacy Enhanced Mail qui a lancé la famille avec des lignes de 64 caractères. Une tentative d'unification antérieure, la RFC 3548, a été remplacée par la RFC 4648.

Voilà toute l'histoire : 64 caractères, trois octets en entrée et quatre caractères en sortie, = pour terminer la queue, et un aller-retour parfait. Chaque outil, chaque bibliothèque et chaque convertisseur en ligne que vous rencontrerez n'est qu'une porte d'entrée vers tout ça. Une fois que vous pouvez regarder une chaîne Base64 et voir les octets se tenir derrière elle, rien dans ce format ne vous surprendra plus. Et quand vous serez prêt à écrire vous-même le décodeur, les articles sur les langages de programmation juste en dessous de cette section vous remettent les mêmes 64 caractères sous forme de code fonctionnel : un guide complet par langage.