Base64エンコードを徹底解説：仕組み、使われる場面、よくある誤解

Base64はなぜ必要なのか

コンピューターのデータはすべて最終的にはバイトです。ところが、メール本文、HTTPヘッダー、JSON、URLなど、テキストしか安全に通せない経路は意外に多くあります。こうした経路に画像のバイト列や暗号文をそのまま流すと、制御文字や改行が混ざってデータが壊れたり、途中のシステムが内容を書き換えたりすることがあります。

Base64は、任意のバイト列を英大文字・小文字、数字、そして + と / の64文字だけで表すことでこの問題を解決します。これらの文字はほぼすべてのシステムで安全な文字として扱われるため、バイナリデータをテキスト専用の経路でも壊さずに運べます。仕様はRFC 4648で標準化されています。

3バイトが4文字になる仕組み

考え方はシンプルです。入力を3バイト(24ビット)ずつ区切り、その24ビットを6ビットずつ4つに分けます。6ビットで表せる値は0から63までの64通りなので、それぞれを1文字に対応させます。0〜25がA〜Z、26〜51がa〜z、52〜61が0〜9、62が +、63が / です。

たとえば英単語 Man のバイト値は77、97、110です。この24ビットを6ビットずつに分けると19、22、5、46となり、対応する文字は TWFu です。英語以外の文字も、バイトに変換すれば同じように扱えます。韓国語の「한」はUTF-8で3バイト(ED 95 9C)なので、ちょうど4文字の 7ZWc になります。

Man   → TWFu
Hi    → SGk=
한    → 7ZWc
안녕  → 7JWI64WV

3バイトが必ず4文字になるため、Base64の出力は入力より約33%大きくなります。1,000バイトのファイルは1,336文字になります。大きな画像をdata URIとして埋め込むとページが目に見えて重くなるのはこのためです。

末尾の = の正体

入力の長さが3の倍数でない場合、最後のグループには1バイトか2バイトしか残りません。足りないビットを0で埋めてエンコードし、出力の長さが4の倍数になるように = を付けます。1バイト残れば ==、2バイト残れば = が1つ付きます。Hi(2バイト)が SGk= になるのはこのためです。

パディングはデコーダーが元の長さを正確に復元するための目印にすぎず、データではありません。パディングを省略するシステムもあり、そうした文字列を厳密なデコーダーに渡すと「長さが不正」というエラーになることがあります。長さが4の倍数になるまで = を補えば、たいていは解決します。

URLやファイル名に使うBase64URL

+ と / はURLの中で特別な意味を持ちます。+ は空白として解釈されることがあり、/ はパスの区切りです。そこでBase64URLという変形では、+ を - に、/ を _ に置き換えます。同じ2バイト FB FF は、標準のBase64では +/8=、Base64URLでは -_8= になります。

JSON Web Token(JWT)の3つの部分はすべてBase64URLでエンコードされており、通常はパディングも省略されます。JWTの真ん中の部分をデコードすると、ユーザーIDや有効期限などがそのまま読めます。これが、Base64について最も重要なポイントにつながります。

最大の誤解：Base64は暗号化ではない

Base64の出力はランダムに見えるため、暗号化と誤解されがちです。しかし鍵は存在せず、誰でも公開されたルールで即座に元に戻せます。パスワードやAPIキーをBase64にして保存・送信しても、平文のままと安全性は変わりません。

HTTPのBasic認証がよい例です。ユーザー名とパスワードをコロンでつなぎ、Base64でエンコードして送りますが、これは送信形式にすぎず、実際の保護はHTTPSが担っています。データを隠したいならAESなどの暗号化を、改ざんを検出したいならハッシュや署名を使いましょう。

実務でBase64に出会う場面

Base64がどこで使われているかを知っておくと、見慣れない文字列の正体をすばやく見抜けます。

• メールの添付ファイル：MIMEはバイナリの添付をBase64でエンコードして本文に含めます。
• data URI：小さなアイコンを data:image/png;base64,... の形でCSSやHTMLに直接埋め込めます。数KB程度の画像にとどめましょう。
• JWTとOAuth：トークンのヘッダーとペイロードはBase64URLです。
• APIのリクエスト本文：JSONは生のバイトを扱えないため、ファイルや署名はBase64文字列として送られます。
• 証明書と鍵ファイル：-----BEGIN CERTIFICATE----- で始まるPEMファイルの本文はBase64です。

デコードできないときの確認ポイント

デコードエラーの原因はほとんどが数パターンに絞られます。まず、改行や空白が混ざっていないか確認しましょう。メールやPEMファイルは76文字ごとに改行していることがよくあります。次に、- や _ があればBase64URLなので、その方式でデコードする必要があります。最後に、長さが4の倍数でなければパディングが欠けています。

デコードは成功したのに文字化けする場合は、元の文字コードの問題です。たとえば日本語はUTF-8とShift_JISでまったく異なるバイトになるため、エンコードしたときと同じ文字コードで解釈する必要があります。AIBIZAPのBase64ツールはUTF-8で処理するため、日本語や韓国語、絵文字も正しく往復変換できます。