Base64 : encoder, décoder et éviter les pièges

Vous collez une chaîne qui commence par iVBORw0KGgo dans un décodeur, il répond « chaîne invalide », et rien n'indique pourquoi. Ou l'inverse : vous encodez Café et le service d'en face ne retrouve pas le bon mot. Base64 passe pour trivial, mais trois détails — le jeu de caractères, l'alphabet employé et le padding — expliquent la quasi-totalité des échecs.

Ce que Base64 fait, et ce qu'il ne fait pas

Base64 découpe un flux d'octets en tranches de 3 octets (24 bits), redécoupe chaque tranche en 4 groupes de 6 bits, et remplace chaque groupe par un caractère pris dans un alphabet de 64 signes : A–Z, a–z, 0–9, plus + et /. Quand la longueur totale n'est pas un multiple de 3, la dernière tranche est complétée par un ou deux signes =. C'est tout : une transformation mécanique, sans clé et sans secret.

L'intérêt est de faire passer du binaire dans un canal qui n'accepte que du texte. Les cas courants aujourd'hui :

• les pièces jointes d'e-mail (MIME), pour lesquelles le format a été conçu ;
• un fichier transporté dans un champ JSON ou un attribut XML, puisque ni l'un ni l'autre n'a de type binaire ;
• les certificats et les clés au format PEM, entre les lignes -----BEGIN…----- ;
• les jetons JWT et l'en-tête HTTP Authorization: Basic ;
• les data URI, qui embarquent une image directement dans du HTML ou du CSS.

Ce que Base64 n'est pas : ni du chiffrement, ni de la compression. N'importe qui décode la chaîne en une seconde. Écrire un mot de passe en Base64 dans un fichier de configuration ne le protège de rien. Si l'objectif est de vérifier qu'un fichier n'a pas été altéré, c'est une empreinte qu'il faut et non un encodage : un calcul d'empreinte SHA-256 répond à ce besoin, et il n'est justement pas réversible.

Le surcoût : +33 %, sans exception

Quatre caractères pour trois octets : le rapport est fixe, la chaîne encodée pèse toujours un tiers de plus que la source. Ce n'est pas une moyenne, c'est de l'arithmétique.

Ajoutez-y les retours à la ligne : MIME coupe traditionnellement toutes les 76 colonnes, PEM toutes les 64, ce qui rajoute encore 2 à 3 %. C'est la raison pour laquelle une pièce jointe de 20 Mo — près de 27 Mo une fois encodée et découpée en lignes — fait sauter une limite serveur fixée à 25 Mo : la limite porte sur le message encodé, pas sur le fichier d'origine.

Encoder du texte : tout dépend du jeu de caractères

Base64 encode des octets, jamais des caractères. Avant d'encoder du texte, il faut donc décider comment ce texte devient des octets, et c'est là que ça dérape. Le mot Café en UTF-8 vaut les octets 43 61 66 C3 A9 et donne Q2Fmw6k=. Le même mot en ISO-8859-1 vaut 43 61 66 E9 et donne Q2Fm6Q==. Deux résultats pour un seul mot : si l'émetteur et le destinataire ne s'accordent pas sur l'encodage, l'accent revient en mojibake à l'autre bout.

UTF-8 est aujourd'hui le choix par défaut partout, et c'est celui qu'applique l'encodeur-décodeur Base64 de Convertu. Deux pièges reviennent malgré tout :

• en JavaScript, btoa() lève une InvalidCharacterError dès qu'un caractère dépasse le code 255 ; il faut convertir le texte en octets avec TextEncoder avant d'appeler la fonction ;
• dans un traitement de texte ou un tableur, une apostrophe typographique ou une espace insécable se glisse dans la chaîne et fausse tout ce qui suit. Recoller la valeur en texte brut règle le problème.

Standard ou URL-safe : deux alphabets, un seul décodeur

L'alphabet standard (RFC 4648, §4) utilise + et /. Placés dans une URL, ces deux caractères posent problème : le + est relu comme une espace dans une chaîne de requête, le / découpe le chemin, et le = final doit être échappé en %3D. D'où la variante base64url (§5) : + devient -, / devient _, et le padding est le plus souvent supprimé.

Vous la croisez sans le savoir dans les jetons JWT — trois segments base64url séparés par des points — et dans le code_challenge d'OAuth PKCE. Identifier la variante d'une chaîne prend une seconde : un - ou un _ signent l'URL-safe, un + ou un / signent le standard. Les deux familles présentes dans la même chaîne trahissent une corruption.

À ne pas confondre avec le percent-encoding des URL, qui répond à une autre question. Base64 rend du binaire transportable en texte ; le percent-encoding rend admissibles dans une URL des caractères qui sont déjà du texte. Les deux se combinent parfois — Base64 standard, puis percent-encoding du résultat — et cet empilement explique bien des %2B mystérieux dans les journaux d'un serveur.

Data URI et contenus binaires

Une data URI ressemble à data:image/png;base64,iVBORw0KGgo… : le fichier est écrit en toutes lettres dans le document. L'avantage est réel, une requête HTTP en moins, mais le calcul se retourne vite. L'image gonfle de 33 %, elle n'est plus mise en cache séparément du HTML ou du CSS qui la porte, et elle est retéléchargée à chaque modification de ce document. En dessous de 2 Ko environ — une petite icône, un motif répété — l'opération se défend. Au-delà, un fichier séparé reste préférable ; et pour une icône, un SVG inline est presque toujours plus léger que le même dessin en PNG encodé.

Dans l'autre sens, une chaîne Base64 ne contient pas forcément du texte. Les premiers caractères suffisent souvent à deviner ce qu'on tient :

• iVBORw0KGgo — une image PNG
• /9j/ — une image JPEG
• JVBERi0 — un PDF
• UEsDB — une archive ZIP, donc aussi un DOCX, un XLSX ou un ODT
• R0lGOD — un GIF

Coller ce genre de chaîne dans un décodeur qui ne sait afficher que du texte produit une bouillie de caractères. Un décodeur correct repère le binaire et propose un téléchargement plutôt qu'un affichage illisible.

Quand le décodage échoue : le diagnostic

Les messages d'erreur des décodeurs sont laconiques. Voici les causes réelles, par fréquence décroissante.

La longueur n'est pas cohérente

Une chaîne Base64 valide a une longueur qui, divisée par 4, laisse un reste de 0, 2 ou 3. Un reste de 1 est mathématiquement impossible : la chaîne a été tronquée, le plus souvent par un copier-coller arrêté au bord d'une zone de saisie ou par un champ de base de données trop court. Un reste de 2 ou 3 signale seulement un padding absent, ce qui se répare en ajoutant les = manquants.

Des espaces, des retours à la ligne, un préfixe

Une chaîne issue d'un fichier PEM ou d'un en-tête MIME arrive découpée en lignes. Un décodeur tolérant nettoie ces blancs ; un décodeur strict refuse. Même chose pour le préfixe data:image/png;base64, : il fait partie de l'URI, pas de la charge utile, et doit être retiré avant décodage.

Un double encodage

Si le résultat du décodage est lui-même une suite de lettres et de chiffres terminée par un ou deux =, la valeur a été encodée deux fois — un classique lorsqu'une couche applicative encode ce qu'une autre avait déjà encodé. Relancez simplement l'opération sur le résultat.

La chaîne vient d'un JSON abîmé

Les charges Base64 voyagent très souvent dans un champ JSON, où elles côtoient des guillemets échappés et des séquences \\n. Si la réponse a été tronquée ou mal recollée, la chaîne l'est aussi. Passer le document dans un formateur JSON permet de vérifier d'abord que le conteneur est valide, avant de chercher la faute dans le contenu.

L'encodeur-décodeur de Convertu travaille entièrement dans votre navigateur : ni le texte ni le fichier ne quittent votre machine, ce qui compte quand la charge utile est un certificat ou un jeton d'authentification. Il accepte les fichiers jusqu'à 10 Mo, reconnaît les deux alphabets au décodage sans qu'il faille les déclarer, et tolère les blancs, le padding absent et le préfixe data:. Au-delà d'un certain volume, l'aperçu affiché à l'écran est tronqué pour ne pas figer l'onglet, mais la copie et le téléchargement portent bien sur le résultat complet.