Base64
7 outils
Qu'est-ce que l'encodage ?
L'encodage est le processus de conversion de données d'une représentation à une autre. Dans le développement Web, l'encodage est utilisé pour transmettre des données en toute sécurité via des canaux conçus pour un jeu de caractères limité. Sans encodage adapté, des octets binaires arbitraires peuvent être mal interprétés, tronqués ou corrompus par des systèmes intermédiaires qui ne gèrent que le texte ASCII.
L'encodage de caractères définit comment les caractères textuels se mappent aux octets. L'encodage Base64 convertit les données binaires en texte ASCII. L'encodage URL rend le texte arbitraire sûr pour une utilisation dans les URL. Comprendre ces trois couches d'encodage permet d'éviter des bogues subtils et des failles de sécurité dans les applications Web.
Histoire de l'encodage de caractères
L'encodage de caractères est le mappage entre les caractères et leurs représentations binaires :
Code standard américain à 7 bits. 128 caractères : lettres anglaises, chiffres, ponctuation et codes de contrôle.
ASCII étendu pour les langues d'Europe occidentale. Ajout de 128 caractères. Non adapté aux scripts non latins.
Jeu de caractères universel couvrant tous les systèmes d'écriture du monde. Définit des points de code pour plus de 149 000 caractères.
Encodage à largeur variable d'Unicode utilisant 1 à 4 octets par caractère. Compatible ASCII. L'encodage dominant sur le Web.
Encodage à largeur variable utilisant 2 ou 4 octets par caractère. Utilisé en interne par Windows, Java et les chaînes JavaScript.
Encodage à largeur fixe : toujours 4 octets par caractère. Rarement utilisé sur le Web.
Pourquoi UTF-8 a gagné
UTF-8 est devenu dominant car il est rétrocompatible avec ASCII, auto-synchronisant et économe en espace pour le texte latin. Tout document ASCII est un document UTF-8 valide.
Encodage Base64
Base64 convertit les données binaires en une représentation textuelle utilisant seulement 64 caractères ASCII imprimables : A-Z, a-z, 0-9, + et /. Ce mécanisme est indispensable lorsque des données binaires doivent transiter par des canaux textuels — pièces jointes d'e-mail, URI de données, tokens JWT et authentification HTTP Basic utilisent tous Base64. L'alphabet de 64 caractères a été choisi précisément parce que ces caractères sont présents dans tous les jeux de caractères ASCII et ne sont pas altérés par les systèmes de transmission textuels hérités.
Comment ça fonctionne
Base64 regroupe les octets d'entrée en blocs de 3 octets (24 bits) et encode chaque bloc en 4 caractères Base64 (6 bits chacun). Ce ratio de 3 octets pour 4 caractères explique pourquoi la taille des données encodées est toujours environ 33 % plus grande que l'entrée d'origine. Si l'entrée n'est pas un multiple de 3 octets, des caractères de remplissage = sont ajoutés pour compléter le dernier groupe de 4 caractères. Chacun des 64 symboles de l'alphabet Base64 représente exactement 6 bits, ce qui permet de reconstruire fidèlement les données binaires d'origine lors du décodage.
| Entrée | Octets hex | Base64 |
|---|---|---|
| "Man" | 77 61 6E | TWFu |
| "Ma" | 4D 61 | TWE= |
| "M" | 4D | TQ== |
Les caractères = de remplissage indiquent combien d'octets manquaient pour compléter le dernier groupe de 3 octets. Un seul = signifie qu'un octet de remplissage était nécessaire ; == en signifie deux. Le Base64 standard produit toujours une sortie dont la longueur est un multiple de 4. Certaines implémentations, notamment Base64url utilisé dans les JWT, omettent délibérément ce remplissage pour produire des chaînes plus compactes et directement utilisables dans les URL sans encodage supplémentaire.
Encodage URL
Les URL ne peuvent contenir qu'un ensemble limité de caractères ASCII sûrs. Tout caractère hors de cet ensemble doit être encodé en pourcentage.
L'encodage en pourcentage remplace chaque octet non sûr par % suivi de deux chiffres hexadécimaux représentant la valeur de cet octet.
Caractères couramment encodés
| Caractère | Encodé | Notes |
|---|---|---|
| Space | %20 | Le plus courant ; utilisé dans les soumissions de formulaires comme + dans application/x-www-form-urlencoded |
| & | %26 | Séparateur de chaîne de requête ; doit être encodé en valeur littérale |
| = | %3D | Séparateur clé-valeur dans les chaînes de requête ; encoder en données |
| + | %2B | Interprété comme espace dans application/x-www-form-urlencoded ; encoder pour conserver + |
| # | %23 | Identifiant de fragment ; encoder en données littérales dans un chemin ou une requête |
| / | %2F | Séparateur de segment de chemin ; encoder en données littérales |
| : | %3A | Séparateur de schéma ; encoder dans les contextes de chemin et de requête |
| @ | %40 | Utilisé dans mailto: et auth ; encoder en données littérales |
encodeURI vs encodeURIComponent
JavaScript fournit deux fonctions d'encodage aux portées différentes. encodeURI encode une URL complète. encodeURIComponent encode un composant d'URL — il encode tous les caractères sauf A-Z, a-z, 0-9, -, _, ., ~.
Où l'encodage apparaît dans le développement Web
L'en-tête Authorization: Basic encode les identifiants sous forme de Base64(utilisateur:motdepasse). C'est un encodage de commodité, PAS de sécurité. Toujours utiliser HTTPS avec Basic Auth. Étant donné que Base64 est une transformation parfaitement réversible sans clé secrète, toute personne interceptant le trafic HTTP peut décoder les identifiants en clair en une fraction de seconde — la protection est donc assurée exclusivement par le chiffrement TLS de la couche transport.
Les URI de données intègrent le contenu de fichier directement dans HTML ou CSS : data:image/png;base64,.... Cela élimine les requêtes HTTP au prix d'une taille de document accrue. Cette technique est particulièrement utile pour les petites icônes ou les images de faible dimension, mais elle devient contre-productive pour les ressources volumineuses car le navigateur ne peut pas les mettre en cache indépendamment de la page qui les contient.
L'e-mail a été conçu pour l'ASCII 7 bits. Les pièces jointes binaires sont encodées en Base64 par MIME avant transmission. L'encodage Base64 garantit que les octets binaires d'une image ou d'un PDF traversent sans altération tous les serveurs de messagerie intermédiaires, même ceux qui filtrent ou modifient les octets dont la valeur dépasse 127. Le client de messagerie destinataire décode transparemment les données lors de l'affichage.
Les tokens JWT utilisent l'encodage Base64url pour les trois parties (en-tête, charge utile, signature), les rendant sûrs pour les URL. Base64url est une variante de Base64 qui remplace + par - et / par _, et omet le remplissage = ; ainsi, le token peut être placé directement dans un paramètre de requête ou un en-tête HTTP sans encodage en pourcentage supplémentaire. Il est important de noter que Base64url protège uniquement le format de transport, pas la confidentialité des données — la charge utile d'un JWT est lisible par quiconque dispose du token.
Toutes les données fournies par l'utilisateur dans les chaînes de requête URL doivent être encodées en pourcentage.
Les noms de domaine non ASCII sont encodés en Punycode (préfixe xn--) pour la compatibilité avec le système DNS. Le navigateur affiche la forme Unicode mais envoie la forme Punycode aux résolveurs DNS.
Questions fréquentes
Non. Base64 est un encodage, pas un chiffrement. C'est une transformation réversible sans clé secrète. N'importe qui disposant d'une chaîne Base64 peut la décoder instantanément avec n'importe quel outil en ligne. N'utilisez jamais Base64 comme mesure de sécurité pour protéger des données sensibles.
Base64 traite l'entrée par groupes de 3 octets. Si l'entrée n'est pas un multiple de 3, un remplissage = est ajouté : un seul = indique qu'un octet manquait, == indique que deux octets manquaient. Certaines implémentations comme Base64url pour les JWT omettent ce remplissage, ce qui est valide tant que l'outil de décodage est configuré pour l'accepter.
Base64url est une variante sécurisée pour les URL qui remplace + par - et / par _, et omet généralement le remplissage =. Les JWT utilisent Base64url. Cette substitution de caractères est nécessaire car + et / ont une signification réservée dans les URL : + est interprété comme un espace dans les chaînes de requête, et / comme un séparateur de chemin. Base64url permet donc d'incorporer une valeur encodée directement dans une URL sans encodage en pourcentage supplémentaire.
Utiliser encodeURIComponent pour les valeurs individuelles. Utiliser encodeURI pour une chaîne URL complète où les caractères de structure URL doivent être préservés.
UTF-8 est compatible ASCII et économe en espace pour le texte latin. HTTP et HTML utilisent UTF-8 par défaut.
L'encodage en pourcentage représente les caractères comme % suivi de leur valeur d'octet hexadécimale. Un espace est %20. Pour les caractères multi-octets UTF-8, chaque octet est encodé séparément : é devient %C3%A9 car il est représenté par les octets 0xC3 et 0xA9 en UTF-8.
Base64 augmente la taille des données d'environ 33 % et ajoute une charge CPU pour l'encodage et le décodage. Pour les systèmes à haut débit, il est préférable d'utiliser des protocoles binaires natifs comme HTTP/2 ou WebSockets qui gèrent les données binaires sans conversion. L'encodage URL ajoute une surcharge minimale mais peut rendre les URL sensiblement plus longues lorsque de nombreux caractères spéciaux sont présents.
Punycode est un encodage pour représenter les caractères Unicode dans le système DNS compatible ASCII. Les domaines comme münchen.de sont encodés en xn--mnchen-3ya.de.