Base64：暗号でも圧縮でもない

Base64 がすることは一つだけです。任意のバイト列を 64 種の可読文字へ写像する。内容を隠さず、容量を減らさず、完全性も検証しません。

なぜ必要か

テキストしか通らない経路があります。メール本文、JSON のフィールド、URL、HTTP ヘッダ。生のバイナリは切り詰められたり壊れたりします。Base64 は 8 ビットのバイトを 6 ビットずつに分け、それぞれを文字に写像します。

入力 "Man"  →  4D 61 6E  →  010011 010110 000101 101110  →  "TWFu"

3 バイトが 4 文字になり、約 33 パーセント増えます。

よくある誤解

誤解	事実
暗号である	誰でもデコードして原文を読める
圧縮である	必ず三分の一ほど大きくなる
安全な転送方法	文字集合を解決するだけで、秘匿も改竄防止もしない
ハッシュの代わり	完全に可逆で、指紋にはならない

機微な情報を Base64 にして URL パラメータや cookie に入れるのは平文と同じです。「トークン漏洩」の多くはここから始まります。

変種と落とし穴

互換性のない変種があります。

変種	違い	使われる場所
標準	+ /、末尾 =	メール、JSON
URL 安全	- _、通常は詰め物なし	URL、ファイル名、JWT
詰め物なし	= を省く	長さに敏感な場所

標準変種の文字列を URL に入れると壊れます。 + はクエリ文字列で空白に復号され、/ はパス区切りとして飲み込まれ得ます。JWT が URL 安全変種を詰め物なしで使うのはこのためです。

詰め物 = の規則

入力長が 3 の倍数でないとき = を足します。

1 バイト → 2 文字 + "=="
2 バイト → 3 文字 + "="
3 バイト → 4 文字

復号側は詰め物あり・なしの両方を受け付ける必要があります。でなければ連携が理由もなく失敗します。

使うべきでない場面

• 秘匿したい → 暗号化（AES-GCM など）であり、Base64 ではない
• 容量を減らしたい → 圧縮、またはバイナリ列をそのまま使う
• 検証したい → ハッシュ、または検査値を伴う符号化

適するのは、データがテキスト専用の経路を通り、受信側が確実に復号できる場合だけです。

A-Za-z0-9+/ の長い並びが = で終わっていたら、まず平文だと考えてください。