Base64 エンコード/デコード チートシート：Windows、Linux、Mac のコマンド例

このチートシートでは、Windows、Linux、macOS 上で certutil、PowerShell、base64 を使用して Base64 でエンコードおよびデコードする方法、そしてシステムによって異なるフラグを紹介します。

このガイドは 開発者ツール: 現代的な開発ワークフローの完全ガイド の一部です。Base64 は、入力バイト3つごとに、A〜Z、a〜z、0〜9、+、/ からなる4文字への変換を行います。デコードには鍵は不要です。アルファベットとパディング文字 = があるだけで、元のバイトを復元できます。

Linux の base64 は -w 0 が設定されていない限り 76 文字で改行します。macOS の base64 は -b で改行位置を設定しない限り1行だけ出力します。Windows の certutil -encode は、改行された行の前後に証明書バナーを追加します。以下の Linux コマンドは、GNU coreutils 9.7、uutils coreutils 0.10.0、BusyBox 1.37.0、OpenSSL 3.5.5 を使用して実行されました。macOS コマンドは、OS X 10.7 以降でそのバイナリに対して文書化されている -i、-D、-b フラグを使用しています。

Windows での Base64 エンコードとデコード

Windows に base64 コマンドは同梱されていません。Certutil と PowerShell は組み込まれています。

コマンドプロンプトと Certutil の使用

1. コマンドプロンプトを開く。

2. ファイルを Base64 にエンコードする:

   certutil -encode input.bin output.b64
   

   input.bin をファイルパスに、output.b64 を出力ファイル名に置き換えてください。ファイルは -----BEGIN CERTIFICATE----- で始まり、続いて改行された Base64、最後に -----END CERTIFICATE----- が続きます。

3. バナー行を削除してボディを表示する:

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

   findstr /v /c:- は - を含む行をすべて削除するため、2つのバナーが除去されます。ボディは改行されたままです。PowerShell の [Convert]::ToBase64String は1行の結果を生成します。

Windows での Base64 デコード (Certutil)

certutil -decode encoded.b64 decoded.bin

certutil -decode は、-encode が書き出したバナー付きファイルを受け入れます。生の Base64 ファイルも受け入れます。

PowerShell によるエンコードとデコード

PowerShell の [Convert]::ToBase64String は1行を書き出し、バナーは追加しません。より詳細なシェル自動化については、PowerShell チートシート を参照してください。

ファイルのエンコード:

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

文字列のエンコード (UTF-8):

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

Encoding.Unicode は UTF-16LE です。同じ文字列は SABlAGwAbABvACwAIABXAG8AcgBsAGQAIQA= にエンコードされます。UTF-8 バイトに対する Linux の base64 は SGVsbG8sIFdvcmxkIQ== を生成します。

Base64 を文字列にデコード:

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

Base64 をファイルにデコード:

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

FromBase64String はスペース、タブ、改行を受け入れます。BEGIN CERTIFICATE バナーでは例外を投げるため、certutil ファイルは certutil -decode 経由で処理する必要があります（または事前にバナーを削除する必要があります）。

Linux での Base64 エンコードとデコード

base64 --version は PATH 上のバイナリ名を表示します。base64 (GNU coreutils) で始まる行は GNU のものです。Ubuntu 25.10 と 26.04 では、/usr/bin/base64 は rust-coreutils パッケージの uutils です。ここで確認した 26.04 パッケージは uutils coreutils 0.10.0 でした。GNU coreutils 9.7 は gnu-coreutils パッケージの gnubase64 です。

両者は位置指定引数としてのファイル、-d / --decode、-i / --ignore-garbage、-w / --wrap を受け入れます。デフォルトの改行幅は 76 です。-w 0 で無効になります。uutils 0.10.0 は -D も -d のエイリアスとして扱います。GNU coreutils 9.7 は -D に対して invalid option -- 'D' で終了します。

これらのワンライナーのパイプと引用符の扱いは、Bash チートシート で扱われています。

ファイルを Base64 にエンコード

base64 input_file > output_file

例:

base64 myfile.txt > encoded.txt

エンコードされたコンテンツをターミナルに表示するには:

base64 myfile.txt

文字列を Base64 にエンコード

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

printf '%s' は渡されたバイトを書き出して停止します。-n 付きでない echo は改行を追加するため、同じテキストは SGVsbG8sIFdvcmxkIQo= にエンコードされます。bash では、echo -n "Hello, World!" | base64 -w 0 は printf 行と一致します。echo -n はすべての sh に移植可能ではありません。

改行の無効化 (-w 0)

GNU と uutils は 76 文字で改行します。stdout がファイルやパイプであってもです。JSON、環境変数、URL、Kubernetes の data 値は1行必要です。Terraform の base64encode() は標準 Base64 の1行を返すため、それと比較される CLI 出力は改行無効化で生成する必要があります:

base64 -w 0 input_file > output_file

Linux での Base64 デコード

base64 -d encoded_file > decoded_file
# または
base64 --decode encoded_file > decoded_file

例:

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

GNU coreutils 9.5 以降、および uutils 0.10.0 は、= パディングを省略した標準 Base64 をデコードします。printf '%s' 'SGVsbG8' | base64 -d は Hello を出力します。エンコーダーは依然としてパディングを出力します。古い GNU base64 はパディングなしの入力を拒否していました。

-i / --ignore-garbage はデコード中にアルファベット外の文字をスキップします。改行は既に許可されています。スペースは、-i が設定されていない限り許可されません:

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

GNU と uutils では、-i はファイル名を受け取りません。base64 -i input_file は input_file をエンコードします。なぜなら名前が位置指定引数であり、-i はデコード動作のみを変更するからです。macOS では、-i は入力ファイルのフラグです。

OpenSSL

OpenSSL 3.5.5 は 64 文字で改行します。-A は出力を1行に保ちます:

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

-A なしでは、長いバッファは 64 文字ごとに分割されます。これは GNU base64 とは異なる幅です。

BusyBox

BusyBox 1.37.0 は -d と -w COL (デフォルト 76、0 で改行無効) を受け入れます。--decode は unrecognized option '--decode' で失敗し、-D は invalid option -- 'D' で失敗します。デコードはすでにアルファベット外の文字をスキップします: printf '%s' 'SGVs!bG8=' | busybox base64 -d は Hello を出力します。-i は受け入れられますが、ヘルプ行には表示されません。

macOS での Base64 エンコードとデコード

macOS には BSD の base64 が同梱されています。ファイル名は -i で渡します。-i なしの stdin リダイレクトも動作します: base64 < input_file。

ファイルを Base64 にエンコード

base64 -i input_file > output_file

例:

base64 -i myfile.txt > encoded.txt

ターミナルに表示するには:

base64 -i myfile.txt

デフォルトの改行間隔は 0 なので、エンコードされたテキストは1行です。-b count は count 文字ごとに改行を挿入します。base64 -w 0 は Linux オプションであり、macOS バイナリでは使用されません。base64 -b 0 -i input_file が明示的な1行形式です。

エンコードしてクリップボードにコピー

base64 -i input_file | pbcopy

Mac での Base64 デコード

base64 -D -i encoded_file > decoded_file

-D はデコードです。これらの -i と -D フラグは、OS X 10.7 以降の macOS インターフェースです。Linux のスクリプトが base64 -d を呼び出している場合、macOS 上では base64 -D を呼び出す必要があります。

実装ごとのフラグ

RFC 4648 は RFC 3548 を廃止しました。両文書の標準アルファベットは A〜Z、a〜z、0〜9、+、/ です。

base64 -i file は Linux ではエンコードします。-i が布尔値 (boolean) であり、file が位置指定オペランドだからです。同じコマンドは macOS でもエンコードします。-i が file を入力パスとして消費するからです。base64 -D -i file は macOS と uutils 0.10.0 でデコードします。

JWT 用の Base64url

JWT ヘッダーとペイロードのセグメントは base64url (RFC 4648 セクション 5) を使用します: - と _ が + と / に置き換えられ、= パディングは通常省略されます。標準の base64 -d はその場合失敗します。uutils 0.10.0 ではエラーは invalid input です。

GNU basenc (Ubuntu 26.04 では gnubasenc) はパディングなしの形式を受け入れます:

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

uutils 0.10.0 の basenc --base64url -d は、4 の倍数にパディングを復元することを要求します。== を追加した同じセグメントはデコードされます。JWT ストールークーのエンコードとパディング除去:

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

jq は @base64d で JWT セグメントをデコードします。これは JWT トークンをデコードして表示 のパスです。

PowerShell でも同じアルファベットを構築できます:

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

よくあるユースケース

kubectl create secret は --from-literal と --from-file の値を自身で Base64 エンコードします。--from-literal=key=$(base64 -w 0 file.bin) のように値の前に base64 -w 0 を付けることで、2重のエンコードが保存され、後からの base64 -d でも Base64 が返ってきます。Kubernetes チートシート では、プレーンテキスト形式の --from-literal=username=admin が使用されています。

マニフェストでは、各 data 値はすでに標準 Base64 の1行であり、stringData が生の文字列を保持します。API サーバーは stringData を data にマージします。Kubernetes のドキュメントでは、stringData がサーバーサイドアプライと相性が良くないことが記載されています。オブジェクトはエンコードされたテキストであり、etcd は静止時暗号化が有効にならない限り平文で保存します。

curl -u は Authorization: Basic ヘッダーを書き出します。user:pass からそのヘッダーを構築する方法は、cURL チートシート で扱われています。

デコードが失敗する場合

-D や -w が意図通りに動作しない場合のチェックは base64 --version です。GNU の行と uutils の行は異なり、Linux の -D は uutils の行と一致します。

空行で終わるデコードされた値には、echo からの改行が含まれています。その入力を printf '%s' で再エンコードしてください。

base64 file | wc -l は、エンコーダーが出力した改行行の数を出力します。Linux で 1 より大きいカウントは、コマンドが -w 0 なしで実行されたことを意味します。

- または _ を含むテキストでの invalid input は、base64url アルファベットであり、JWT セグメントに典型的です。basenc --base64url でデコードし、uutils 0.10.0 では長さが 4 の倍数になるまで = を追加してください。