Coder et décoder Base64

Encoder et décoder Base64 convertit les octets arbitraires en une chaîne ASCII à l'aide de l'alphabet RFC 4648 et inverse cette chaîne en octets d'origine. Le mode texte accepte un codage de caractères tel que UTF-8 ; le mode fichier lit un téléchargement via le FileReader du navigateur et peut émettre un URI data: pour l'intégration. L'encodage n'est pas un cryptage. Toute personne recevant la chaîne peut la décoder.

Tout l’encodage et le décodage s’exécutent dans votre navigateur. Rien de ce que vous collez n'est envoyé à un serveur.

Encoder du texte ou un fichier en Base64

L'encodage prend des octets bruts et écrit une chaîne de A à Z, de a à z, de 0 à 9, plus une barre oblique et un remplissage =. Collez du texte ou choisissez un fichier, sélectionnez le codage des caractères lorsque la source est du texte et lisez le résultat.

Le mode fichier convient aux petites images et documents qui doivent voyager au sein de JSON, XML ou e-mail sans canal binaire.

La sortie peut être transportée en toute sécurité via des systèmes qui corrompent des binaires arbitraires, tels que des passerelles de messagerie plus anciennes ou un copier-coller dans XML. Il est plus long que l'entrée, de par sa conception. Une entrée vide non valide ne produit aucune chaîne ; l'outil attend des octets avant d'émettre des caractères.

Décoder une chaîne Base64 en données

Le décodage inverse la recherche alphabétique, reconstruit le flux binaire d'origine et renvoie du texte ou un fichier téléchargeable. Les caractères de remplissage = à la fin sont significatifs : ils indiquent le nombre d'octets dans le groupe final incomplet. Les caractères en dehors de l'alphabet provoquent une erreur évidente plutôt qu'un décodage partiel silencieux.

Les espaces sont souvent ignorés, de sorte que les chaînes copiées à partir de certificats PEM ou de corps MIME fonctionnent toujours. Une chaîne qui ressemble à Base64 mais qui utilise l'alphabet sécurisé pour les URL nécessite le mode de décodage sécurisé pour les URL, sinon le trait d'union et le trait de soulignement seront rejetés comme illégaux dans l'alphabet standard.

Comprendre comment fonctionne l'encodage Base64

Base64 traite les entrées par blocs de trois octets (24 bits). Ces 24 bits sont répartis en quatre groupes de 6 bits. Chaque valeur de 6 bits est un index de 0 à 63 dans l'alphabet de 64 caractères. Trois octets d'entrée deviennent donc quatre caractères de sortie.

Bytes:  [ byte1 ][ byte2 ][ byte3 ]
Bits:   aaaaaaaa bbbbbbbb cccccccc
Groups: aaaaaa aabbbb bbbbcc cccccc
Chars:  Char1  Char2  Char3  Char4

Lorsqu'il reste moins de trois octets, l'encodeur émet toujours quatre caractères mais ajoute un remplissage afin que le décodeur connaisse la longueur d'origine. Le regroupement de bits représente l'ensemble de l'algorithme ; il n'y a pas de somme de contrôle ni de clé.

Encodez le mot Chien étape par étape

Le mot « Dog » comporte trois octets ASCII, il remplit donc un groupe Base64 et est codé sans caractères de remplissage. La sortie du luminaire est « RG9n ». Parcourir les octets en bits, les regrouper en index de 6 bits et lire l'alphabet RFC 4648 montre pourquoi ces quatre caractères apparaissent et comment tout bloc de trois octets suit le même chemin.

1. Écrivez les octets. D = 0x44 = 01000100 o = 0x6F = 01101111 g = 0x67 = 01100111

2. Concaténez 24 bits. 01000100 01101111 01100111

3. Divisez-vous en groupes de 6 bits. 010001 000110 111101 100111

4. Convertissez chaque groupe en index décimal. 17, 6, 61, 39

5. Recherchez l'alphabet. Indice 17 = R, 6 = G, 61 = 9, 39 = n

Résultat : RG9n. Le décodage RG9n renvoie les trois octets d'origine et le texte Dog sous UTF-8 ou ASCII.

Comprendre le remplissage avec le signe égal

Le remplissage apparaît lorsque le nombre d'octets n'est pas un multiple de trois. Un octet restant produit deux caractères alphabétiques et deux signes =. Deux octets restants produisent trois caractères et un =. Les appareils Do → RG8= et Dogs → RG9ncw== affichent les deux cas restants à côté du mot de trois octets non complété Dog.

Input	Bytes	Encoded	Padding
Dog	3	RG9n	none
Do	2	RG8=	one =
Dogs	4	RG9ncw==	two =

Do fait deux octets : 01000100 01101111. Après un regroupement de 6 bits, il n'y a que suffisamment de bits pour trois caractères significatifs (RG8), et un remplissage = remplit le quatrième emplacement. « Dogs » fait quatre octets : un groupe complet de trois octets codé comme « RG9n », puis un reste d'un octet codé comme « cw== ». La suppression du remplissage à la main sans ajuster la longueur en bits interrompt le décodage ; laissez les caractères = en place lors du collage.

Lire l'alphabet Base64

La RFC 4648 définit 64 caractères plus la marque de remplissage =. Les index 0 à 25 vont de « A » à « Z », 26 à 51 vont de « a » à « z », 52 à 61 vont de « 0 » à « 9 », l'index 62 est « + » et l'index 63 est « / ».

L'index 0 est « A », pas « 0 », ce qui fait trébucher quiconque s'attend à ce que les chiffres soient en tête de l'alphabet.

Index range	Characters
0 to 25	A to Z
26 to 51	a to z
52 to 61	0 to 9
62	+
63	/
padding	=

Le panneau alphabétique de la calculatrice répertorie le même tableau que celui utilisé par l'encodeur, de sorte qu'un caractère suspect peut être comparé à l'ensemble standard. La chaîne complète est ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/.

Utilisez la variante Base64 sécurisée pour les URL

L'alphabet sécurisé pour les URL (base64url) remplace + par - et / par _. Le remplissage peut être omis dans certains protocoles. Les jetons Web JSON utilisent cette variante afin que les segments de jetons puissent figurer dans les URL et les en-têtes HTTP sans coder en pourcentage les caractères plus et barre oblique.

Les chaînes standard et sécurisées pour les URL ne sont pas interchangeables. Le décodage d'une charge utile JWT avec l'alphabet standard échoue sur les traits d'union. L'outil propose un mode explicite sécurisé pour les URL pour l'encodage et le décodage. Le codage en pourcentage d'une URL est un problème différent ; utilisez la page d'encodage et de décodage d'URL lorsque l'objectif est d'échapper à la RFC 3986 plutôt qu'à Base64.

Tenir compte de l'augmentation de la taille

Tous les trois octets deviennent quatre caractères, donc la longueur codée représente environ 4/3 de l'entrée, soit une augmentation de 33 % avant les sauts de ligne. Le remplissage peut ajouter un ou deux caractères supplémentaires au groupe final. Les URI de données et les pièces jointes aux e-mails ressentent rapidement ce coût : une image de 300 Ko devient environ 400 Ko de texte.

encoded_length ≈ 4 × ceil(byte_length / 3)

Le retour à la ligne à 76 caractères, courant dans MIME, ajoute des octets de nouvelle ligne en haut. Préférez les pièces jointes binaires ou les formats compressés lorsque la taille compte ; utilisez Base64 lorsque le canal ne peut réellement pas transporter d'octets bruts.

Choisissez un encodage de caractères

Base64 code des octets, pas des caractères abstraits. Les mêmes lettres produisent des octets différents sous UTF-8, UTF-16, Shift JIS ou Big5. Le décodage puis l'interprétation avec le mauvais jeu de caractères donnent du mojibake même lorsque la couche Base64 était parfaite, donc le jeu de caractères en mode texte doit correspondre au producteur lors de l'encodage et au consommateur lors du décodage.

Charset	Typical use
UTF-8	Default for modern text and APIs
Windows-1252	Legacy Western European text
UTF-16 LE / BE	Some Windows and Java payloads
Shift JIS	Older Japanese text
Big5	Older Traditional Chinese text

Pour le mot « Dog », ASCII et UTF-8 produisent les mêmes trois octets, donc « RG9n » est identique. Le texte non-ASCII diverge. Choisissez le jeu de caractères qui correspond au producteur avant l'encodage, et le même jeu de caractères après le décodage, sinon l'aller-retour ressemblera à un bug Base64 lorsque l'erreur est en amont.

Questions fréquemment posées

Le cryptage Base64 est-il ?

Non. Base64 est un codage que n'importe qui peut inverser avec l'alphabet public. Cela ne cache rien. Utiliser un véritable algorithme cryptographique lorsque la confidentialité est requise ; utilisez Base64 lorsqu'un canal a besoin d'octets sécurisés ASCII.

Pourquoi la sortie Base64 se termine-t-elle par des signes égal ?

Les caractères = sont un remplissage. Ils indiquent que le groupe d'entrée final comportait un ou deux octets au lieu de trois. Do code en RG8= et Dogs en RG9ncw==. Conservez le remplissage lors du décodage à moins que le protocole ne documente qu'il a été supprimé.

En quoi Dog code-t-il ?

Dog code en RG9n sans remplissage, car trois octets remplissent exactement un groupe Base64. Le regroupement de bits étape par étape est illustré dans l'exemple concret de cette page.

Quelle est la différence entre le Base64 standard et le Base64 sécurisé pour les URL ?

Base64 sécurisé pour les URL utilise - et _ au lieu de + et /. Les JWT et certaines intégrations de noms de fichiers utilisent l'alphabet sécurisé pour les URL. Le décodage avec le mauvais alphabet échoue sur ces caractères substitués.

Dans quelle mesure Base64 est-il plus grand que l'original ?

Environ un tiers plus grand. Trois octets deviennent quatre caractères, le rapport est donc de 4/3 avant le remplissage et les sauts de ligne. Une charge utile de 3 000 octets devient 4 000 caractères Base64.

Base64 peut-il encoder un fichier, pas seulement du texte ?

Oui. Le mode fichier lit le téléchargement dans le navigateur et encode ses octets bruts. Le chemin inverse décode en un blob téléchargeable. Les fichiers volumineux augmentent l'utilisation de la mémoire dans l'onglet ; gardez les téléchargements modestes.

Pourquoi le texte décodé semble-t-il faux après un décodage correct ?

La couche Base64 a restauré les octets, mais le codage de caractères utilisé pour interpréter ces octets ne correspond pas à celui du producteur. Essayez d'abord UTF-8, puis le jeu de caractères utilisé réellement par le système source.

Cet outil télécharge-t-il des secrets collés ?

Non. L’encodage et le décodage s’exécutent localement. Les clés API, les jetons et les fragments de certificat collés dans la boîte ne sont pas envoyés à un serveur. Cette promesse correspond à la règle de conception de toutes les pages de codage sur les calculatrices rapides.

Base64 est-il identique à l'encodage d'URL ?

Non. Base64 mappe le binaire sur un alphabet de 64 caractères pour le transport. Le codage d'URL (codage en pourcentage) échappe aux caractères réservés dans les URI conformément à la RFC 3986. Ils résolvent différents problèmes et ne se substituent pas les uns aux autres.

Quelle RFC définit l’alphabet ?

La RFC 4648 définit les alphabets Base64 standard et sécurisés pour les URL ainsi que les règles de remplissage utilisées ici. Des documents plus anciens tels que la RFC 2045 décrivent Base64 dans le contexte MIME avec des mécanismes similaires.

Résumé

Encoder et décoder Base64 mappe les octets à l'alphabet RFC 4648 en groupes de 6 bits et inverse le processus localement dans le navigateur. Dog devient RG9n, Do devient RG8= et Dogs devient RG9ncw==, illustrant le remplissage pour les restes d'un et deux octets.

L'alphabet sécurisé pour les URL remplace +// par -/_, la sortie augmente d'environ un tiers et le choix du jeu de caractères décide quels octets le mode texte alimente l'encodeur. Rien de collé n'est téléchargé.