De A à C
Alphabet
L’ensemble des caractères qu’écrit un encodage, dans l’ordre des index. Le Base64 standard utilise A-Z, a-z, 0-9, + et / : A vaut 0 et / vaut 63. Voir la table de l’alphabet.
ASN.1
Abstract Syntax Notation One, un langage de description de structures de données utilisé par les certificats X.509, les clés et de nombreux protocoles télécoms. ASN.1 définit la structure. Des règles d’encodage comme DER définissent les octets.
Base16
Le nom que la RFC 4648 donne à l’hexadécimal : chaque octet devient deux caractères parmi 0-9 A-F. La taille double. Essayez l’outil Base16.
Base32
Un encodage à 32 caractères (A-Z et 2-7 dans la RFC 4648) qui transforme 5 octets en 8 caractères, soit 60 % de plus que l’entrée. Ses alphabets insensibles à la casse en font un bon choix pour les secrets TOTP et les noms DNS. Essayez l’encodeur Base32.
Base45
Défini dans la RFC 9285, il transforme 2 octets en 3 caractères pris dans le jeu de 45 caractères que les codes QR stockent en mode alphanumérique. Le certificat COVID numérique de l’UE l’utilisait. Essayez l’encodeur Base45.
Base58
L’alphabet de 58 caractères de Bitcoin : Base64 sans 0, O, I, l, + ni /. Il convertit toute l’entrée comme un seul grand nombre, et chaque octet nul de tête devient un 1. Essayez l’encodeur Base58.
Base58Check
Base58 avec un octet de version au début et une somme de contrôle de 4 octets à la fin. Cette somme correspond aux 4 premiers octets d’un double SHA-256. Les anciennes adresses Bitcoin et les clés privées WIF l’utilisent. Voir l’outil Base58Check.
Base64
Un encodage binaire-texte qui écrit chaque groupe de 3 octets sous forme de 4 caractères d’un alphabet de 64, en complétant la fin par =. La sortie est environ 33 % plus grande que l’entrée. Commencez par l’encodeur et le décodeur, ou lisez le fonctionnement de Base64.
Base64URL
Base64 avec - et _ à la place de + et /, d’après la section 5 de la RFC 4648. Le remplissage est souvent omis. Utilisé dans les JWT et les URL. Voir Base64 ou Base64URL et l’encodeur Base64URL.
Base85
Une famille d’encodages qui écrivent 4 octets en 5 caractères, soit 25 % de surcoût. Les variantes courantes sont Ascii85 (Adobe, utilisé dans PDF et PostScript), Z85 (ZeroMQ) et l’alphabet de la RFC 1924 utilisé par git. Essayez l’outil Base85.
Base91
basE91, créé par Joachim Henke, utilise 91 caractères ASCII imprimables et range 13 ou 14 bits dans chaque paire de caractères. Son surcoût se situe ainsi entre 14 % et 23 % environ, le plus faible de cette liste, au prix d’un alphabet qui contient le guillemet droit et bien d’autres signes de ponctuation. Essayez l’outil Base91.
Basic Auth
L’authentification HTTP Basic (RFC 7617) envoie user:password en Base64 dans l’en-tête Authorization : Aladdin:open sesame devient Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==. Quiconque voit l’en-tête peut le décoder : HTTPS reste donc indispensable. Créez ou lisez un en-tête avec le générateur Basic Auth et le décodeur.
BOM
Byte order mark (indicateur d’ordre des octets), le caractère U+FEFF placé au début d’un fichier texte. En UTF-8, il vaut EF BB BF (Base64 77u/), en UTF-16LE FF FE. Les décodeurs qui ne s’y attendent pas l’affichent sous la forme  ou d’un caractère invisible parasite.
CRLF
Retour chariot suivi d’un saut de ligne, les octets 0D 0A. MIME exige CRLF entre les lignes de Base64, alors que les outils Unix n’écrivent en général que LF (0A). Les décodeurs tolérants ignorent les deux, les décodeurs stricts les rejettent.
De D à J
Data URI
Une URL qui contient les données elles-mêmes au lieu de pointer vers elles, définie dans la RFC 2397 : data:image/png;base64,iVBORw0KGgo…. Pratique pour les petites images et les icônes en HTML et CSS. Voir le générateur de data URI, l’analyseur et les data URI et les performances.
Deflate
L’algorithme de compression (RFC 1951) au cœur de ZIP, gzip, zlib et PNG. « Raw deflate » désigne le flux compressé sans en-tête ni somme de contrôle autour. Compressez et encodez avec l’outil zlib et deflate.
DER
Distinguished Encoding Rules, l’encodage binaire strict des structures ASN.1 défini dans la recommandation UIT-T X.690. Les certificats et les clés sont des octets DER. Une structure DER commence en général par 30 (une SEQUENCE), ce qui explique que le corps d’un PEM commence par M, souvent MII.
Encodage binaire-texte
Tout procédé qui représente des octets quelconques avec des caractères imprimables uniquement, pour que les données survivent aux systèmes conçus pour le texte comme l’e-mail, JSON ou les URL. Hex, Base32, Base64, Base85, uuencode et quoted-printable sont tous des encodages binaire-texte. Comparez-les dans Base64, hex, Base32, Base58 et Base85 comparés.
Encodage canonique
La forme encodée unique et « correcte » de certaines données. En Base64, elle exige que les bits inutilisés avant le remplissage soient à zéro (RFC 4648, section 3.5) : SGk/Pg== est canonique ; SGk/Ph== donne les mêmes octets avec un décodeur tolérant, mais ne l’est pas.
gzip
Un format de fichier (RFC 1952) qui enveloppe des données compressées en deflate avec un en-tête de 10 octets et une somme de contrôle CRC-32. Il commence par les octets 1F 8B, donc du gzip en Base64 commence par H4sI. Utilisez gzip et Base64 pour compresser et décoder du gzip en Base64 pour revenir en arrière.
Hex
L’hexadécimal : chaque octet s’écrit avec deux chiffres parmi 0-9 et a-f, par exemple 48 65 6c 6c 6f pour Hello. Facile à lire octet par octet, il fait deux fois la taille de l’entrée. Convertissez avec Base64 en hex et hex en Base64.
Jeu de caractères (charset)
L’encodage de caractères qui associe du texte à des octets, comme UTF-8, UTF-16LE ou Windows-1252. Base64 stocke des octets : pour décoder du Base64 en texte, il faut connaître le jeu de caractères dans lequel le texte a été enregistré. Une mauvaise supposition produit du mojibake comme Café. L’outil Base64 en texte permet de changer de jeu de caractères.
JWE
JSON Web Encryption (RFC 7516). Un jeton chiffré dont la forme compacte compte cinq parties en Base64URL : en-tête, clé chiffrée, vecteur d’initialisation, texte chiffré et tag d’authentification. Contrairement à un JWS, son contenu ne peut pas être lu sans la clé.
JWS
JSON Web Signature (RFC 7515). Un message signé en trois parties Base64URL : en-tête, payload et signature. Tout le monde peut lire le payload. La signature prouve seulement qu’il n’a pas été modifié.
JWT
JSON Web Token (RFC 7519), un ensemble de claims en JSON transporté dans un JWS ou un JWE. La plupart des JWT que vous croiserez sont des jetons JWS qui commencent par eyJ. Décodez-en un avec le décodeur JWT, créez-en un avec l’encodeur JWT et lisez Base64 dans les JWT.
De M à Q
MIME
Multipurpose Internet Mail Extensions (RFC 2045 à 2049), la norme qui permet aux e-mails de transporter des pièces jointes et du texte non ASCII. Son Content-Transfer-Encoding base64 est la façon dont les pièces jointes voyagent dans un message en texte seul. Voir Base64 dans les e-mails et le décodeur EML.
Nombre magique
Une séquence d’octets fixe au début d’un fichier qui identifie son format, comme %PDF- pour un PDF ou 89 50 4E 47 pour un PNG. Comme Base64 encode 3 octets à la fois, les nombres magiques deviennent des préfixes Base64 reconnaissables. Voir les préfixes Base64 courants et Base64 en fichier.
Nonce CSP
Une valeur aléatoire dans un en-tête Content-Security-Policy (script-src 'nonce-…') qui n’autorise que les scripts inline portant le même attribut nonce. Elle s’écrit en Base64, doit être nouvelle à chaque réponse et contenir au moins 128 bits d’aléa. Générez-en une avec le générateur de nonce CSP.
PEM
Privacy-Enhanced Mail, à l’origine une norme d’e-mail sécurisé (RFC 1421). Aujourd’hui, le nom désigne son format texte pour les clés et les certificats : le Base64 d’octets DER entre des lignes -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----, coupé à 64 caractères (RFC 7468). Inspectez-en un avec le décodeur de certificat.
Quoted-printable
L’autre encodage de transfert MIME. Il garde l’ASCII imprimable tel quel et écrit les autres octets sous la forme = suivi de deux chiffres hexadécimaux : Café en UTF-8 devient Caf=C3=A9. Efficace pour du texte presque entièrement ASCII, coûteux pour du binaire. Essayez l’outil quoted-printable.
De R à Z
Radix-64
Le nom que donne OpenPGP à son armure ASCII : du Base64 standard plus une ligne de somme de contrôle facultative qui commence par = et contient un CRC-24 en Base64. Voir les normes Base64.
Remplissage (padding)
Les caractères = à la fin d’une chaîne Base64 qui complètent le dernier groupe de 4 caractères : == après 1 octet restant, = après 2. Certains formats l’omettent. Lisez le guide du remplissage.
Retour à la ligne
L’insertion de sauts de ligne dans une longue sortie Base64. MIME coupe à 76 caractères au plus, PEM à exactement 64. GNU base64 coupe à 76 par défaut (-w 0 le désactive), openssl base64 à 64 (-A le désactive). L’encodeur MIME s’en charge pour vous.
SRI
Subresource Integrity, une fonction du navigateur qui vérifie un script ou une feuille de style téléchargés par rapport à un hachage placé dans l’attribut integrity, écrit sous la forme du nom de l’algorithme suivi de l’empreinte en Base64 : sha384-…. Les algorithmes pris en charge sont SHA-256, SHA-384 et SHA-512. Générez des valeurs avec le générateur de hachage SRI.
uuencode
Unix-to-Unix encoding, un format binaire-texte plus ancien que MIME. Chaque ligne commence par un caractère de longueur, et les caractères de données vont de l’ASCII 32 à 95 : on y trouve donc des signes de ponctuation que le Base64 de MIME évite. Voir l’outil uuencode.
UTF-8
L’encodage de texte dominant sur le Web. Les caractères ASCII occupent un octet, les autres de deux à quatre. Quand un outil parle de « texte en Base64 », il s’agit presque toujours d’octets UTF-8 convertis en Base64 : é vaut C3 A9. Voir UTF-8 en Base64.
UTF-16LE
UTF-16 avec l’octet de poids faible en premier, le format interne des chaînes sous Windows et .NET. Du texte ASCII en UTF-16LE contient un octet nul après chaque caractère : Hello devient SABlAGwAbABvAA==, plein de A. Le paramètre -EncodedCommand de PowerShell l’attend. Voir UTF-16 en Base64 et le décodeur PowerShell.
Z85
La variante Base85 de ZeroMQ (ZeroMQ RFC 32). Elle encode 4 octets en 5 caractères, évite les guillemets et la barre oblique inverse pour que la sortie tienne dans des chaînes de code source, et exige une entrée multiple de 4 octets. Essayez l’outil Z85.
zlib
Une fine enveloppe (RFC 1950) autour de données deflate : un en-tête de 2 octets et une somme de contrôle Adler-32. L’en-tête commence en général par 78 : des données zlib en Base64 commencent donc par eJ, eN, eF ou eA selon le niveau de compression. Utilisez l’outil zlib.
FAQ
Quelle différence entre encodage et chiffrement ?
L’encodage change la façon dont les données sont écrites et n’importe qui peut l’inverser. Le chiffrement exige une clé pour revenir en arrière. Base64 est un encodage. Voir encodage ou chiffrement.
Base64 et Radix-64, c'est la même chose ?
Radix-64 est le nom que donne OpenPGP à Base64 accompagné d’une ligne de somme de contrôle CRC-24 facultative. L’alphabet et la disposition des bits sont ceux du Base64 standard.
Quelle est la différence entre PEM et DER ?
DER est l’encodage binaire d’un certificat ou d’une clé. PEM, ce sont ces mêmes données DER en Base64, coupées à 64 caractères entre des lignes -----BEGIN et -----END. Convertissez avec PEM en DER et DER en PEM.