Encodeur et décodeur Base64

À quoi cela sert

Le Base64 résout un seul problème : vous avez des octets quelconques, et un canal qui ne transporte que du texte imprimable. Les en-têtes d’e-mail, les champs texte du JSON, les URL, les attributs HTML et une bonne part des infrastructures anciennes se brisent sur du binaire brut. Le Base64 fait correspondre chaque groupe de trois octets à quatre caractères tirés d’un alphabet de 64 symboles qui, lui, passe partout.

C’est là tout son rôle. Ce n’est pas de la compression — la sortie est un tiers plus longue. Ce n’est pas du chiffrement — il n’y a pas de clé. C’est un encodage de transport, et toutes les propriétés qu’on lui prête à tort viennent de la confusion entre « je n’arrive pas à lire ça » et « c’est protégé ».

Où vous le croiserez

• Les JWT. Les trois segments, dans l’alphabet compatible URL et sans le remplissage.
• L’authentification HTTP Basic. Authorization: Basic, c’est simplement utilisateur:motdepasse encodé en Base64 — et c’est exactement pour cela que l’authentification Basic sur du HTTP en clair revient à envoyer le mot de passe en clair.
• Les URI de données. data:image/png;base64,... intègre un fichier directement dans le HTML ou le CSS.
• Les certificats et clés PEM. Les lignes situées entre -----BEGIN----- et -----END----- sont du DER encodé en Base64.
• Les pièces jointes d’e-mail. SMTP est un protocole texte ; MIME se sert du Base64 pour transporter tout ce qui ne l’est pas.

Le piège Unicode

Le navigateur vous offre btoa et atob, et ce sont des pièges. Tous deux travaillent sur des octets représentés sous forme de chaîne : btoa lève donc une erreur sur tout caractère au-delà de U+00FF. Essayez avec un émoji et vous obtenez InvalidCharacterError.

La solution consiste à convertir d’abord en octets UTF-8, ce que fait cette page :

// Encode any string safely
const bytes = new TextEncoder().encode(text);
const b64 = btoa(String.fromCharCode(...bytes));

// Decode back
const binary = atob(b64);
const out = new TextDecoder().decode(
  Uint8Array.from(binary, c => c.charCodeAt(0))
);

Une réserve sur la ligne d’encodage : étaler un grand tableau dans String.fromCharCode fait déborder la pile d’appels aux alentours de cent mille éléments. Pour tout ce qui est volumineux, bouclez par morceaux — cette page le fait, et c’est pourquoi elle encaisse un collage de plusieurs mégaoctets sans broncher.

Les deux alphabets

C’est le remplissage qui pose problème. Son seul rôle est de rendre la longueur multiple de quatre, et un décodeur peut toujours déduire ce qui manque — la variante compatible URL le supprime donc. Les décodeurs stricts rejettent alors le résultat, et c’est pourquoi un segment de JWT collé dans un autre outil échoue si souvent. Celui-ci rétablit le remplissage de lui-même.

Où on en fait mauvais usage

Comme le Base64 est illisible au premier coup d’œil, on s’en sert comme s’il s’agissait d’un secret. Il vaut la peine de nommer les cas précis :

• Le Base64 comme stockage de mots de passe. C’est du texte en clair déguisé. Les mots de passe exigent un hachage lent à sens unique — bcrypt, scrypt, Argon2.
• Le Base64 dans la charge utile d’un JWT comme si elle était privée. Cette charge est lisible par quiconque détient le jeton, l’utilisateur compris. N’y mettez jamais rien que vous ne lui montreriez pas.
• Le Base64 pour faire passer des données devant un filtre. Cela marche un moment, et tout scanner digne de ce nom le décode de toute façon.

La règle qui couvre les trois cas : si la sécurité d’une chose repose sur le fait que le lecteur ne la décode pas, elle n’a aucune sécurité.

À voir aussi

Le décodeur de JWT découpe un jeton et analyse les deux segments d’un seul coup. Pour échapper du texte destiné à une URL plutôt que pour encoder des octets, c’est l’encodage pour cent que vous cherchez sans doute — c’est autre chose. Et si ce que vous avez décodé se révèle être du JSON, le formateur vous le mettra au propre.