Bash での Base64 エンコード：完全ガイド

バイトを持っていて、文字列が必要だ。JSON ボディのなかに住まなければならないテキストファイル。設定の 1 行に載せてやらなければならない画像。URL、環境変数、HTTP ヘッダーを旅していくトークン。証明書ストアに収めるべき秘密鍵。これがシェルでの Base64 エンコーディングの日常の仕事で、シェルからの答えは、1 つの、小さな、驚くほどポータブルなコマンドです。

取引をひと呼吸で説明します：Base64 は、生のデータ 3 バイトごとに、64 文字のアルファベット（A-Z, a-z, 0-9、それに + と /）から 4 文字を取って書き換えます。バイト数が 3 の倍数でなかったときは、末尾に = を 1 つか 2 つのパディングとして足します。このサイトのホームページでは形式を完全に説明しています。ここでは、テキストを作り出すこと、行き先に合った方言を選ぶこと、そして目を開けてサイズ代を払うことに時間を割きます。ポケットにしまっておくべき数字が 1 つあります：エンコードされた形は、通常、元より約 1/3 大きく、3 バイトが 4 文字。そして、この法則は必ず帰って来ます。

登場人物は少ないです。coreutils の base64 コマンド（GNU、または新しい Rust uutils 系）、同じ系譜から URL 安全な方言のための basenc、coreutils のないマシン向けの openssl base64、組み込みシステムのための BusyBox アプレット、そして macOS の BSD フレーバー。5 つの道具、1 つの仕事、知る価値のあるフラッグがいくつか。

エンコーダーを選ぼう

これらはすべて、標準入力かファイルからバイトを読み、標準出力にテキストを書きます。だから、どの道具も同じパイプラインにそのまま組み込まれます。違いは、既定の行折り返しと利用可能な方言です：

その折り返しの列を 2 回読んでおいてください。それが系派ごとの静かな違いだからです。Coreutils と BusyBox は既定で 76 で折り返し、OpenSSL は 64 で折り返し、BSD ツールは折り返しを一切しません。どれも間違いではありません。ただ、引き継いだ慣習が違うだけです（MIME は 76、PEM は 64、そして BSD ツールは、折り返しの癖ができるより前のものです）。読み手が気にする場合は、幅を明示的に設定し、既定値に頼らないでください。

まずテキスト：見えない改行

シェルでのテキストエンコーディングは、1 つの罠から始まります：echo が改行を追加するのです。「hello」の 5 文字は、echo を通る瞬間に 6 バイトになり、6 バイト目の改行は出力に乗って、見えないまま、永久に付きまといます：

echo "hello" | base64

これなら aGVsbG8K が表示されますが、最後の文字がエンコードしているのは改行です。バイト数が大事なテキストに使うべき修正は、装飾なしのフォーマット付き printf です：

printf '%s' "hello" | base64

今度は出力が aGVsbG8= で、ちょうど 5 バイト分。最後の文字は生きたバイトではなくパディング文字です。同じ規則が here-string にも当てはまります。here-string も echo と同じく末尾に改行を足すので、base64 <<< "hello" はまた aGVsbG8K 版になります。迷ったら、エンコードする前に最後のバイトが何かを自問してください。

1 行にまとまりたいものは何でも、-w 0 を足します（あるいは下の -w 0 の親戚たちを）。これにより、コマンドが本来出すはずの最後の改行も消えます：

printf '%s' "hello world and more" | base64 -w 0

これで、末尾の改行なしの、きれいな 1 本の切れ目のない行が完成です。URL、JSON の値、設定ファイルに、それ以上の儀式なしでそのまま落ちます。

ファイルと折り返し幅

ファイルが通常のケースで、すべての実装が FILE 引数を受け取り、バイトをシェルの引用機構から完全に遠ざけてくれます：

base64 -w 0 report.pdf > report.b64

-w 0 を付けなければ、出力は 76 文字で折り返されて届きます。ちょうど MIME の読み手が望む形です：

base64 report.pdf > report.mime.b64

幅は、読み手ごとに調整できるダイヤルです。76 は RFC 2045 の MIME 慣習、64 は証明書と鍵が使う PEM 慣習、ゼロは URL と API のための 1 本の切れ目のない行です：

base64 -w 64 key.bin | head -2

読み手が Windows にいて CRLF 改行を期待するなら、変換は折り返しのあとにやって、前にやってはいけません：

base64 -w 76 attachment.bin | sed 's/$/\r/' > attachment.crlf.b64

OpenSSL の経路では、1 行モードに相当するのは -A フラッグで、末尾の改行も抑えます：

openssl base64 -A < report.pdf

折り返し済みのファイルを発送する前に、サイズの健全性チェックはコストゼロで、驚くほど多くのミスを拾ってくれます（2 回エンコードされたファイル、誤った入力でエンコードされたファイル）：

wc -c report.pdf
base64 report.pdf | wc -c

2 番目の数は、1 番目の数の約 4/3 倍になるはずです。加えて、折り返された行ごとに改行の 1 バイトが加わります。大きくずれていたら、立ち止まって、エンコーダーに実際に何を食わせたかを見てください。

URL 安全 Base64：やっかいな 2 文字の交換

標準アルファベットの中で問題児なのは、+ と / の 2 文字です。URL のクエリ文字列では + はスペースを意味し、/ はパスの区切りに見え、どちらも文字列が URL、クッキー、ファイル名に入る瞬間にパーセントエンコーディングを強いられる。RFC 4648 の 5 節は、ちょうどこの 2 文字を - と _ に置き換え、パディングを落とすことでこの問題を解決する方言を定義しています。URL が正確なバイト長を公言する必要があることはほとんどないからです。

シェルの手順は交換と切り詰め、アルファベット用に tr を 1 回、パディングを除去するために 1 回：

printf '\376\117\202' | base64 -w 0 | tr '+/' '-_' | tr -d '='

この 3 バイトは通常 /k+C にエンコードされますが、URL では見た目が悪いです。パイプラインはそれを _k-C に変え、どこへでも行ける 4 文字になります。交換は位置ベースなので、方向は混同しやすい：エンコードは tr '+/' '-_'（プラスがダッシュに、スラッシュがアンダースコアに）、デコードに属する逆方向は tr '_-' '/+'。方向を混ぜて間違ってもエラーにはならず、ただ違うバイトを生成するだけです。これは出荷するバグの中でも最悪の種別です。

文字列がシェルの管理を離れるたびに、この方言が重要になります：JWT のセグメント、クエリ文字列の中のトークン、クッキーやファイル名の中の値、そして別のシステムが URL の一部として読むあらゆる識別子。GNU の basenc はパディングをそのままでこの方言をネイティブに生成します：

printf '%s' "hello" | basenc --base64url

読み手がストリップされた形を望むなら（たいていの場合はそう）、tr -d '=' でパディングを取り除きます。

シェルで JWT を鋳造する

JSON Web Token は、API の世界で URL 安全 Base64 の最も目立つ読み手です。コンパクトな JWT は、RFC 7515 に従い、ドットで結ばれた base64url の 3 セグメント：ヘッダー、ペイロード、署名です。最初の 2 つはそのままの JSON。署名は、ドットで結ばれた最初の 2 セグメントのバイナリダイジェストで、まさに openssl が得意とする種類のものです。

key="supersecretkey"
h=$(printf '%s' '{"alg":"HS256","typ":"JWT"}' | base64 -w 0 | tr '+/' '-_' | tr -d '=')
p=$(printf '%s' '{"sub":"42","name":"homer"}' | base64 -w 0 | tr '+/' '-_' | tr -d '=')
s=$(printf '%s' "$h.$p" | openssl dgst -sha256 -hmac "$key" -binary | base64 -w 0 | tr '+/' '-_' | tr -d '=')
printf '%s.%s.%s\n' "$h" "$p" "$s"

これなら、どのプラットフォームのどの標準ライブラリも受け入れる、コンパクトな HS256 JWT が表示されます。仕事の分担に注意してください：Base64 の部分はアルファベット、openssl dgst -sha256 -hmac の部分は暗号学、ドット連結が形式です。頭の中でこの 3 つの仕事をはっきり分けておけば、パイプラインは常に明白なままです。

現場のための注意が 3 つ。1 つ目：MAC は最初の 2 セグメントとドットの ASCII テキストに対して計算されるので、署名する時点ではセグメントがすでに最終的な base64url の形である必要があります。署名後に折り返し直すことやパディングを足し直すと、トークンは壊れます。2 つ目：キーはトークンの外にいる：署名は誰が署名したかを証明し、キーが秘密を秘密のままに保ちます。3 つ目：シェルスクリプトでの鋳造は、テストと自動化の道具であり、実際にこれらのトークンを発行して検証するサーバーの代わりにはなりません。alg: none で鋳造したトークンは、何も証明しません。

Data URI：文字列に同乗するファイル

RFC 2397 が data: URL スキームを定義し、その Base64 形式はファイルを URL のなかに住まわせることを可能にします：data:、続いて任意のメディアタイプ、ペイロードが Base64 エンコードされている場合は ;base64、続いてカンマ、そしてデータ。メディアタイプを省略すると既定は text/plain;charset=US-ASCII になります。これは知っている価値のある足元の罠で、多くの人が想定しているのは画像や JSON ドキュメントであって、ASCII テキストではないからです。

printf 'data:text/plain;base64,%s\n' "$(printf '%s' "hi there" | base64 -w 0)"

これなら data:text/plain;base64,aGkgdGhlcmU= が表示されます。ブラウザが喜んで表示してくれる、完全で自己完結した URL です。画像の場合は、実際のメディアタイプを入れた同じ形です：

printf 'data:image/png;base64,%s\n' "$(base64 -w 0 icon.png)" > icon.uri

結果を HTML の img タグの src や CSS の background に貼り付けると、画像は文書と一緒に発送され、2 番目の HTTP リクエストは不要です。罠はすべてサイズにあります：RFC 自体がこのスキームは短い値にしか有用ではないと言っており、ブラウザは自前の URL 長制限を課し、インライン化した 1 バイトごとに画像自身のサイズの上に 33% のオーバーヘッドがかかり、データ URI だらけのページは、その画像に対してキャッシュのストーリーを持たないページです。小さなアイコンや使い捨ての埋め込みグラフィックには快調ですが、写真ライブラリには税金です。

シークレット、設定、環境変数

Base64 が設定とシークレットの世界に現れる理由が 1 つだけあります：スペース、クォート、改行を含むあらゆるバイトを、export、設定の 1 行、JSON フィールドを、クォートのアクロバットなしで生き延びさせる文字列に変えるからです。最も目立つ例が Kubernetes です：シークレットの .data 配下の全フィールドは Base64 なので、シェルでシークレットを作るのはエンコードするだけです：

kubectl create secret generic app --from-literal=password='s3cret'

API サーバーはパスワードを czNjcmV0 として .data 配下に保存し、シークレットへのアクセスを持つどのノードも 1 回のデコードで読み戻せます。同じ動きがあなたの設定ファイルにも効きます：

export API_TOKEN_B64=$(printf '%s' "$API_TOKEN" | base64 -w 0)

あるいは、アプリケーションが起動時に読むファイルのために：

printf 'token=%s\n' "$(printf '%s' "$API_TOKEN" | base64 -w 0)" >> app.conf

ここで、壁に掲げるべき警告が出てきます：Base64 はエンコーディングであって、暗号化ではありません。RFC 4648 のセキュリティ節はこれを率直に述べており、このエンコーディングは「パスワードのような、さもなければ簡単に認識できる情報を視覚的に隠すことができるが、計算上の秘匿性は何も提供しない」といい、しかもまさにこの誤解が、誰かが「保護された」プロトコル交換をバグ報告に貼り付けて認証情報を偶然露出させた実際のセキュリティ事故を引き起こしたと記録しています。値が秘密でなければならないなら、暗号化してください（そして保存のために暗号文を Base64 化してください）。Base64 しかないのであれば、エンコードされた値は、画面を離れた瞬間からプレーンテキストとして扱ってください。

Unicode、文字セット、そしてその下のバイト

エンコーダーが読むのはバイトで、文字ではありません。シェルは、ロケールとコマンドが生んだバイトをそのままエンコーダーに手渡します。UTF-8 テキストなら、たいていちょうどあなたが望んでいる通りです：héllo の é はすでに 2 バイトの c3 a9 で、エンコーディングはそれをただ運びます：

printf 'h\xc3\xa9llo' | base64

これなら aMOpbGxv が表示され、向こう側の UTF-8 の読み手が 1 バイト単位で héllo を取り戻します。問題が始まるのは、ソースが UTF-8 でないときです。同じ単語を含む Latin-1 ファイルは、é を 1 バイトの e9 で持ち、そのバイトをそのままエンコードすると、Latin-1 の読み手しか読み戻せないテキストが生まれます。まず変換して、それからエンコード：

iconv -f ISO-8859-1 -t UTF-8 note.txt | base64 -w 0

バイトレベルの事実がもう 2 つ。ファイル先頭の 3 バイトである UTF-8 BOM は 77u/ にエンコードされ、まず取り除かなければ、デコードされた出力の先頭に永遠に座り続けます：

sed '1s/^\xef\xbb\xbf//' file.txt | base64 -w 0

そして、ロケールはエンコーディング自体を変えることはありません。エンコーダーはバイト機械だからです。ロケールが変わるのは、あなたが入力したものだけです。出力が正しく見えなければ、実行したエンコーディングではなく、食わせたバイトを確認してください。

メール、API、アップロード

Base64 がマナーを身につけたのはメールであり、そのマナーが今も慣習です。SMTP は歴史的に 7 ビット ASCII しか運べなかったため、添付ファイルは RFC 2045 に従い、CRLF 改行で 76 文字ごとに折り返された Base64 として旅します。MIME 部のためにその正確な形を作るのは、折り返しと行末の変換です：

base64 -w 76 attachment.bin | sed 's/$/\r/' > attachment.mime

古参の道具は組み込みシステムでまだ現役です：BusyBox の uuencode に -m フラッグを付けると、お馴染みの begin-base64 フレームに包まれた MIME Base64 が生成され、その兄弟 uudecode が読み戻します：

busybox uuencode -m photo.jpg < photo.jpg > photo.uu

API とアップロードは、JSON の服を着た同じアイデアを使います：バイナリが JSON フィールドのなかに Base64 文字列になり、curl がそれを運びます。ボディをシェル変数で組み立てると、クォートが正直さを保ちます：

body="{\"file\":\"$(base64 -w 0 upload.bin)\"}"
curl -fsS -X POST https://httpbin.org/post -H "Content-Type: application/json" -d "$body"

ここに互換性の罠が 2 つ潜んでいます。1 つ目：API がどのアルファベットを望んでいるか確認してください。標準 Base64 を期待するものもあれば、URL 安全な方言を期待するものもあり、+ を含んだ文字列を URL 安全なエンドポイントに送ると（またはその逆に）、検証に失敗するか、最悪の場合は誤ったバイトにデコードされます。2 つ目：ダブルエンコーディングに注意してください。スクリプトが値をエンコードし、サーバーがまたエンコードする、という古典的なバグで、往復を解くには 2 回のデコードが必要です。

ペイロードが大きくなったとき

エンコーダーはデコーダーと同じく、ストリーミング機械です：チャンクで読み、チャンクで書き、だから 10 GB の tar アーカイブにも 13 GB の RAM は不要で、大きな入力を数分間まわしてもメモリ使用は一定のままです。計画に必要なツールは、サイズ計算ただひとつです：出力は入力 3 バイトごとに 4 文字、加えて折り返された行ごとに 1 バイト。300 MB のファイルはおよそ 400 MB のテキストになります。どんなファイルでも素早く現実確認するには：

base64 -w 0 big.bin | wc -c

テキスト自体を、サイズ制限のあるチャネル（メール添付の上限、チケットシステム、IM メッセージ）の中を通さなければならないときは、生バイナリではなくエンコードされた形を分割してください。どのチャンクも貼り付け、圧縮、転送ができるふつうのテキストのままになります：

base64 -w 0 big.bin | split -b 4000 - part_

これで 4000 文字のパーツの連が生まれます。受信者は正しい順に cat で再結合し、1 回だけデコードします。そしてペイロードが圧縮できるなら、エンコード前に圧縮してください。Base64 はデータがすでに持っているもののうえに冗長さを足すからです：プロジェクトディレクトリの tar アーカイブは、33% の Base64 追加料金が乗る前に、gzip で典型的に数倍縮みます：

tar czf - project/ | base64 -w 0 > project.b64

速度はあなたの制約になりません。これらのエンコーダーはモダンなマシンで、1 秒もかかる前にギガバイト単位を押し切ります。200 MB のファイルは coreutils と OpenSSL の実装でおよそ 0.1 秒で済み、共通の道具で最も遅い BusyBox でさえ数分の 1 秒で終わります（あるモダンなマシンで 200 MB に対しておよそ 0.25 秒を測定。coreutils の数倍遅いが、ボトルネックになるほどのものではない）。実パイプラインのボトルネックは、ほぼいつもネットワークであり、エンコーディングではありません。

噛みついてくる小さな文字たち

エンコーディング側の罠はデコーディング側よりも小さい、それももっともなことです：

あなたを守る癖たち

• バイト数に名前を付けろ。テキストには printf '%s'、ファイルには FILE 引数、サイズが大事なものを発送する前に wc -c の健全性チェック。
• 折り返しを明示的に設定しろ。URL と JSON には -w 0、MIME には -w 76、PEM には -w 64。幅は絶対にツールの既定値に任せない。
• 行き先のためにアルファベットを選べ。メールとファイルには標準、トークンと URL には URL 安全。エンコード前に読み手のドキュメントを確認する。
• エンコード前に圧縮しろ。圧縮できるペイロードなら、先に gzip か tar czf。33% の追加料金は、エンコーダーに渡すものすべてに乗る。
• バイナリではなくテキストを分割しろ。サイズ制限が邪魔をするなら、エンコードされた形を split で切り、どのチャンクも貼り付け安全のままにしておく。1 回のデコードの前に、順序どおり再結合する。
• JWT の 3 つの仕事は分けて保て。アルファベット、暗号学、形式：セグメントをエンコードし、連結したセグメントの ASCII テキストに署名し、それから出力する。順序を変えるとトークンは壊れる。
• Base64 を暗号化の代わりに立たせないこと。値が秘密なら、暗号化してから暗号文をエンコードする。秘密でなければ、そう明言して心配をやめる。

シェルでのエンコードの短い歴史

• 1980 年、バークレー。Mary Ann Horton がカリフォルニア大学バークレー校で uuencode と uudecode を書き、Unix システム間でメールを通じてバイナリファイルを運ぶようにしました。この形式の出生証明書である名前は「Unix to Unix エンコーディング」で、そのあとの 10 年ほど、シェルユーザーがエンコードするのはこれでした。
• ダイヤルアップ時代。UNIX の uuencode と TRS-80 と Apple II の BinHex（Macintosh はあと一歩）は、違うアルファベットで同じ問題を解決し、それぞれが自らのターミナルが出せる文字だけを信頼していました。
• 1993 年。MIME が RFC 1521（のちに RFC 2045）でメール用の Base64 を標準化。coreutils の既定が今日まで受け継いでいる 76 文字折り返しごとに入りました。
• 2006 年以前の Linux。base64 コマンドは存在しません。シェルスクリプトは openssl base64、uuencode -m、Perl、Python に手を伸ばし、OpenSSL への癖は根深すぎて、世の古い 1 行コマンドの半分は、今もそこから始まります。
• 2006 年 8 月 15 日。coreutils 6.0 が base64 コマンドを同梱し、NEWS ファイルはそれを「base64 エンコードとデコード（RFC 3548）機能」とクレジット。1 コマンド時代の始まりです。それから 2 か月後、2006 年 10 月、RFC 4648 がアルファベットの一族を公式化。この記事が何度も手を伸ばす URL 安全な方言も、その一部です。
• OS X 10.7。macOS が自前の base64 を同梱。既定の折り返しなしの BSD フレーバーで、だからこそポータブルなスクリプトでは「ただ base64 を実行する」だけではプラットフォームの確認が必要になるのです。
• 2024 年。coreutils 9.5 がデコーダーの扱い方を変えました。パディングのない入力や正規でない入力をどう扱うかが変わったのです。実務的には、エンコーダーが無償の通行手形を得ることを意味します：古い GNU バージョンは拒否したはずの出力が、今度はきれいにデコードされる。形式のエンコーダー側は安定している方です。動いたのはデコーダーの方です。
• 2025 年。coreutils の Rust 書き直し版（uutils）が現行 Ubuntu リリースの既定に。同じコマンド、同じフラッグ、新しいエンジン、そして C バージョンから受け継いだ 76 文字の既定も同じです。

小さな驚きたち

• 形式の名前はどのマシンでも本当。printf 'base64' | base64 は GNU、uutils、BusyBox、OpenSSL、macOS どれもで YmFzZTY0 を返します。2006 年から本当で、これからもずっと本当です。
• 何も入っていないファイルは、A の壁にエンコードされる。3 つの NUL バイトを食わせると出力は AAAA になります。値が 0 の 3 バイトは、アルファベットのインデックス 0 が 4 つに写り、それらはどれも A で表されます。先頭に長い A の列が続く .b64 ファイルは、たいてい元のファイルのゼロ埋め（NUL バイト）であり、神秘ではありません。
• 33% の税金に割引はない。3 バイトが 4 文字、圧縮なし、やり直しなし。唯一の脱出口は、先にデータを圧縮することです。だからこそ、大きなペイロードのパイプラインの真のヒーローは tar czf です。
• URL の騒動の犯人は 2 文字。+ と / は、代替の必要があった唯一のアルファベットの住人です。この 2 文字を退席させるために、形式の 1 つの方言まるごとが存在します。62 番と 63 番、アルファベットの最後の 2 つの席です。
• 11 文字、64 ビット。YouTube の動画 ID は 11 文字の base64url 文字列。URL の服を着た 64 ビットの数値で、だからこそパーセントサインを 1 つも使わずに URL を旅できます。
• Git の最も有名な偽物。git diff --binary のバイナリブロックは Base64 に見えますが、z 付きの行は自分たちの base85 スタイルの方言です。一瞥で「自分のアルファベットではない」と分かるのに、grep してデコードする寄り道 1 本で 20 分を失います。
• どのツールも意図的に違う幅で折り返す。MIME は 76、PEM は 64、BSD ツールはゼロ：3 つの既定値、3 つの引き継いだ慣習、1 つの形式。幅はいつもあなたの選択でした。ツールが違う既定値を覚えていただけなのです。
• エンコーダーはあなたのデータに対して失敗しない。デコーディングの従兄弟と違い、エンコーダーには不正な入力がなく、破損もなく、厳格モードもない。バイトを受け取り、いつも文字を返す。この記事のバグはすべて、あなたが食わせるバイトと、それを送り込む行き先の中にあります。

そして旅が反対の方向を向いたとき - 英字と数字、たまにダッシュやアンダースコアの長い文字列がターミナルに落ちてきて、バイトを取り戻す必要があるとき - 下記にリンクする関連記事の Base64 デコードが、同じ深さでその儀式を扱います。パディングのない JWT セグメントから、デコーダーが隠すあらゆる改行の罠まで。

最終更新： 2026-10-09

関連記事： Bash での Base64 デコード：完全ガイド