Encoder et décoder en base64
La fonction btoa du navigateur ne mange que du latin-1 et casse sur le premier accent. Ici la chaîne passe par UTF-8 avant l'encodage, donc « déjà vu » revient intact.
Comment le contrôle fonctionne
- 1
Le texte devient des octets
Encodage UTF-8 d'abord : c'est ce qui préserve accents, emoji et idéogrammes.
- 2
Les octets deviennent du base64
Trois octets se transforment en quatre caractères pris dans un alphabet de 64 signes.
- 3
La variante URL-safe si besoin
Les caractères + et / deviennent - et _, et le remplissage = est retiré.
Le base64 n'est pas du chiffrement
C'est un encodage réversible sans clé : n'importe qui décode en une seconde. Il sert à faire transiter des octets par un canal qui n'accepte que du texte — un e-mail, une URL, un champ JSON. Y mettre un mot de passe revient à l'écrire en clair.
Autre conséquence : le base64 fait grossir la donnée d'environ un tiers. Une image en data-URI pèse donc plus lourd que le fichier d'origine.
Questions fréquentes
Pourquoi mes accents se transforment-ils en points d'interrogation ailleurs ?
Parce que l'outil utilisé encode en latin-1 au lieu d'UTF-8. La fonction btoa du navigateur lève une erreur au-delà du caractère 255 ; certaines implémentations la contournent en tronquant, ce qui détruit les accents.
Que signifient les signes = à la fin ?
C'est du remplissage. Le base64 travaille par groupes de trois octets ; quand le dernier groupe est incomplet, un ou deux signes = complètent le bloc. La variante URL-safe les retire, et le décodeur les remet.
Quand utiliser la variante URL-safe ?
Dès que la chaîne voyage dans une URL ou un nom de fichier. Les caractères + et / y ont une signification propre et seraient réinterprétés ; - et _ passent partout. C'est la variante utilisée par les jetons JWT.
Le même contrôle par API
Cet outil tourne dans votre navigateur. Pour le même contrôle dans votre code, en masse ou côté serveur, l'API répond en JSON.
Voir la documentation