Aide-mémoire pour l'encodage et le décodage Base64 : exemples de commandes Windows, Linux et Mac

Cette fiche montre comment encoder et decoder en Base64 sur Windows, Linux et macOS à l’aide de certutil, PowerShell et base64, en incluant les options (flags) qui varient selon le système.

Ce guide fait partie de Outils de développement : Le guide complet des flux de travail de développement modernes. Base64 convertit chaque groupe de trois octets d’entrée en quatre caractères choisis parmi A–Z, a–z, 0–9, + et /. Le décodage ne nécessite aucune clé : l’alphabet et le caractère de bourrage = suffisent pour récupérer les octets d’origine.

Sur Linux, base64 insère un retour à la ligne tous les 76 caractères, sauf si l’option -w 0 est définie. Sur macOS, base64 écrit une seule ligne, sauf si -b définit un retour à la ligne. Sur Windows, certutil -encode ajoute des en-têtes de certificat autour des lignes coupées. Les commandes Linux ci-dessous ont été exécutées avec GNU coreutils 9.7, uutils coreutils 0.10.0, BusyBox 1.37.0 et OpenSSL 3.5.5. Les commandes macOS utilisent les options -i, -D et -b documentées pour ce binaire depuis OS X 10.7.

Encodage et décodage Base64 sur Windows

Windows n’inclut pas de commande base64. Certutil et PowerShell sont intégrés au système.

Utilisation de l’invite de commandes avec Certutil

1. Ouvrez l’invite de commandes (Command Prompt).

2. Encodez un fichier en Base64 :

   certutil -encode input.bin output.b64
   

   Remplacez input.bin par le chemin de votre fichier et output.b64 par le nom de fichier de sortie souhaité. Le fichier commence par -----BEGIN CERTIFICATE-----, suivi du Base64 coupé, puis par -----END CERTIFICATE-----.

3. Supprimez les lignes d’en-tête et affichez le contenu principal :

   certutil -encode input.bin tmp.b64 && findstr /v /c:- tmp.b64 && del tmp.b64
   

   findstr /v /c:- supprime chaque ligne contenant un -, ce qui élimine les deux en-têtes. Le contenu principal reste coupé par lignes. PowerShell [Convert]::ToBase64String est le résultat en une seule ligne.

Décodez Base64 sur Windows (Certutil)

certutil -decode encoded.b64 decoded.bin

certutil -decode accepte le fichier d’en-tête écrit par -encode. Il accepte également un fichier Base64 brut.

Utilisation de PowerShell pour encoder et décoder

PowerShell [Convert]::ToBase64String écrit une seule ligne et n’ajoute pas d’en-têtes. Pour plus d’automatisation de shell, consultez la Fiche de triche PowerShell.

Encodage d’un fichier :

[Convert]::ToBase64String([System.IO.File]::ReadAllBytes("C:\path\to\file.bin"))

Encodage d’une chaîne (UTF-8) :

[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes("Hello, World!"))
# Sortie : SGVsbG8sIFdvcmxkIQ==

Encoding.Unicode est UTF-16LE. Les mêmes caractères s’encodent alors comme SABlAGwAbABvACwAIABXAG8AcgBsAGQAIQA=. Linux base64 des octets UTF-8 produit SGVsbG8sIFdvcmxkIQ==.

Décodage Base64 vers chaîne :

[System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String("SGVsbG8sIFdvcmxkIQ=="))
# Sortie : Hello, World!

Décodage Base64 vers fichier :

[System.IO.File]::WriteAllBytes("decoded.bin", [Convert]::FromBase64String((Get-Content encoded.b64 -Raw)))

FromBase64String accepte les espaces, les tabulations et les retours à la ligne. Il lève une erreur sur l’en-tête BEGIN CERTIFICATE, il faut donc passer par certutil -decode pour un fichier certutil (ou supprimer les en-têtes d’abord).

Encodage et décodage Base64 sur Linux

base64 --version indique le nom du binaire sur le PATH. Une ligne qui commence par base64 (GNU coreutils) est GNU. Sur Ubuntu 25.10 et 26.04, /usr/bin/base64 est uutils provenant de rust-coreutils ; le paquet 26.04 vérifié ici était uutils coreutils 0.10.0. GNU coreutils 9.7 est gnubase64 provenant du paquet gnu-coreutils.

Les deux acceptent un fichier positionnel, -d / --decode, -i / --ignore-garbage et -w / --wrap. Le retour à la ligne par défaut est à 76 caractères. -w 0 le désactive. uutils 0.10.0 traite également -D comme un alias de -d. GNU coreutils 9.7 se termine avec invalid option -- 'D' sur -D.

Le redirigeement des flux et les guillemets pour ces commandes en une ligne sont couverts dans la Fiche de triche Bash.

Encoder un fichier en Base64

base64 input_file > output_file

Exemple :

base64 myfile.txt > encoded.txt

Pour afficher le contenu encodé dans le terminal :

base64 myfile.txt

Encoder une chaîne en Base64

printf '%s' 'Hello, World!' | base64 -w 0
# Sortie : SGVsbG8sIFdvcmxkIQ==

printf '%s' écrit les octets transmis et s’arrête. echo sans -n ajoute un retour à la ligne, donc le même texte s’encode comme SGVsbG8sIFdvcmxkIQo=. Dans bash, echo -n "Hello, World!" | base64 -w 0 correspond à la ligne printf. echo -n n’est pas portable sur tous les sh.

Désactiver le retour à la ligne (-w 0)

GNU et uutils insèrent un retour à la ligne tous les 76 caractères, y compris lorsque la sortie standard est un fichier ou un tube. JSON, les variables d’environnement, les URL et une valeur data Kubernetes ont besoin d’une seule ligne. base64encode() de Terraform retourne une seule ligne de Base64 standard, donc la sortie du CLI qui est comparée à celle-ci doit être produite avec le retour à la ligne désactivé :

base64 -w 0 input_file > output_file

Décodez Base64 sur Linux

base64 -d encoded_file > decoded_file
# ou
base64 --decode encoded_file > decoded_file

Exemple :

printf '%s' 'SGVsbG8sIFdvcmxkIQ==' | base64 -d
# Sortie : Hello, World!

GNU coreutils depuis la 9.5, et uutils 0.10.0, décodent le Base64 standard qui omet le bourrage =. printf '%s' 'SGVsbG8' | base64 -d affiche Hello. Les encodeurs émettent toujours le bourrage. Les anciennes versions de GNU base64 rejetaient l’entrée sans bourrage.

-i / --ignore-garbage ignore les caractères hors de l’alphabet lors du décodage. Les retours à la ligne sont déjà autorisés. Les espaces ne le sont pas, sauf si -i est défini :

printf '%s' 'SGVs bG8=' | base64 -di
# Sortie : Hello

Sur GNU et uutils, -i n’accepte pas de nom de fichier. base64 -i input_file encode input_file car le nom est un argument positionnel et -i ne modifie que le décodage. Sur macOS, -i est l’option de fichier d’entrée.

OpenSSL

OpenSSL 3.5.5 insère un retour à la ligne tous les 64 caractères. -A conserve la sortie sur une seule ligne :

printf '%s' 'data' | openssl base64 -e -A
# Sortie : ZGF0YQ==
printf '%s' 'ZGF0YQ==' | openssl base64 -d -A
# Sortie : data

Sans -A, un long tampon est coupé tous les 64 caractères, ce qui est une largeur différente de GNU base64.

BusyBox

BusyBox 1.37.0 accepte -d et -w COL (par défaut 76, 0 désactive le retour à la ligne). --decode échoue avec unrecognized option '--decode', et -D échoue avec invalid option -- 'D'. Le décodage ignore déjà les caractères hors de l’alphabet : printf '%s' 'SGVs!bG8=' | busybox base64 -d affiche Hello. -i est accepté et n’apparaît pas dans la ligne d’aide.

Encodage et décodage Base64 sur macOS

macOS fournit un base64 BSD. Un nom de fichier est passé avec -i. La redirection depuis l’entrée standard fonctionne sans -i : base64 < input_file.

Encoder un fichier en Base64

base64 -i input_file > output_file

Exemple :

base64 -i myfile.txt > encoded.txt

Pour afficher dans le terminal :

base64 -i myfile.txt

L’intervalle de coupure par défaut est 0, donc le texte encodé est sur une seule ligne. -b count insère un retour à la ligne tous les count caractères. base64 -w 0 est l’option Linux ; le binaire macOS ne l’utilise pas. base64 -b 0 -i input_file est la forme explicite en une seule ligne.

Encoder et copier dans le presse-papiers

base64 -i input_file | pbcopy

Décodez Base64 sur Mac

base64 -D -i encoded_file > decoded_file

-D est le décodage. Ces options -i et -D ont été l’interface macOS depuis OS X 10.7. Un script Linux qui appelle base64 -d devrait appeler base64 -D sur macOS.

Options par implémentation

RFC 4648 abolit RFC 3548. L’alphabet standard dans les deux documents est A–Z, a–z, 0–9, +, /.

base64 -i file encode sur Linux, car -i est booléen là-bas et file est l’opérande positionnel. La même commande sur macOS encode aussi, car -i consomme file comme chemin d’entrée. base64 -D -i file décode sur macOS et sur uutils 0.10.0.

Base64url pour JWT

Les segments d’en-tête et de charge utile JWT utilisent base64url (section 5 de la RFC 4648) : - et _ remplacent + et /, et le bourrage = est généralement omis. Le base64 -d standard échoue alors. Sur uutils 0.10.0, l’erreur est invalid input.

GNU basenc (et gnubasenc sur Ubuntu 26.04) accepte la forme sans bourrage :

printf '%s' 'aGVsbG8_Ky93b3JsZA' | gnubasenc --base64url -d
# Sortie : hello?+/world

uutils 0.10.0 basenc --base64url -d exige que le bourrage soit restauré pour être un multiple de 4. Le même segment avec == ajouté se décode. Encodez et supprimez le bourrage pour un jeton de type JWT :

printf '%s' 'hello?+/world' | basenc --base64url -w 0 | tr -d '='
# Sortie : aGVsbG8_Ky93b3JsZA

jq décode les segments JWT avec @base64d, ce qui est le chemin dans Décodez et affichez un jeton JWT.

PowerShell peut construire le même alphabet :

$b = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("hello?+/world"))
$b.TrimEnd("=").Replace("+","-").Replace("/","_")

Cas d’usage courants

kubectl create secret encode en base64 lui-même les valeurs de --from-literal et --from-file. Préfixer la valeur avec base64 -w 0, comme dans --from-literal=key=$(base64 -w 0 file.bin), stocke un second encodage, et un base64 -d ultérieur retourne toujours du Base64. La fiche de triche Kubernetes utilise la forme texte brut, --from-literal=username=admin.

Dans un manifeste, chaque valeur data est déjà une seule ligne de Base64 standard, et stringData contient la chaîne brute. Le serveur d’API fusionne stringData dans data. Kubernetes documente que stringData ne fonctionne pas bien avec l’application côté serveur. L’objet est du texte encodé ; etcd le stocke sans chiffrement à moins que le chiffrement au repos ne soit activé.

curl -u écrit l’en-tête Authorization: Basic. La construction de cet en-tête depuis user:pass est couverte dans la Fiche de triche cURL.

Quand le décodage échoue

base64 --version est le check à faire quand -D ou -w se comporte mal. La ligne GNU et la ligne uutils sont différentes, et -D sur Linux correspond à la ligne uutils.

Une valeur décodée qui se termine par une ligne vide contient un retour à la ligne provenant de echo. Ré-encodez cette entrée avec printf '%s'.

base64 file | wc -l affiche le nombre de lignes coupées émises par l’encodeur. Un compte supérieur à 1 sur Linux signifie que la commande a été exécutée sans -w 0.

invalid input sur un texte contenant - ou _ est un alphabet base64url, typique d’un segment JWT. Décodez-le avec basenc --base64url, et sur uutils 0.10.0, ajoutez = jusqu’à ce que la longueur soit un multiple de 4.