Base64 は日常的に使われています。たとえば Data URL、JSON 内のバイナリ、JWT の各セグメント、メール添付の MIME 形式などです。しかし「Base64 は安全化の手段」という誤解も非常に多く見られます。Base64 はエンコードであり、暗号化ではありません。
1. Base64 とは何か
Base64 はバイナリデータを、テキスト通信に適した ASCII 文字列へ変換する方式です。テキスト前提の経路でも壊れにくく扱えるようにすることが主目的です。
標準 Base64 の文字集合は A-Z、a-z、0-9、+、/ の 64 文字で、必要に応じて = でパディングします。
2. なぜ約 33% サイズが増えるのか
Base64 は 3 バイト（24 bit）を 4 つの 6 bit グループに分割して文字へ対応付けます。
- 入力 3 バイトが出力 4 文字になります。
- 比率はおおよそ 4:3 で、サイズは約 33% 増加します。
- 入力長が 3 の倍数でない場合、末尾に
=が付きます。
そのため大きなファイルを Base64 化して JSON に直接入れると、転送量とパース負荷が目立って増えます。
3. Base64・暗号化・ハッシュの違い
| 方式 | 目的 | 可逆性 | 主な用途 |
|---|---|---|---|
| Base64 | データを文字列表現にする | 可逆 | バイナリ転送、Data URL、JWT セグメント |
| 暗号化 | 機密性の確保 | 鍵があれば可逆 | AES/RSA による秘匿 |
| ハッシュ | 要約値の生成 | 不可逆 | 整合性確認、パスワード保存 |
パスワードを Base64 化して保存しても保護にはなりません。パスワード保存は Argon2 や bcrypt などを使ってください。
4. Base64 が適している場面
1. API で小さなバイナリを扱う
署名断片や小さなサムネイルなど、限定的なサイズなら JSON でも扱えます。大容量ファイルは multipart やオブジェクトストレージ URL を使う方が適切です。
2. Data URL で小さなアセットを埋め込む
data:image/png;base64,... は小さなアイコンなら有効です。ただし大きい画像では HTML/CSS が膨らみ、キャッシュ効率が下がります。
3. JWT における Base64URL
JWT は URL 安全な Base64URL を使います。+ と / を - と _ に置き換え、通常は = を省略します。
5. Base64URL とは
Base64URL は別アルゴリズムではなく、URL で扱いやすくした Base64 の変種です。
+→-/→_=は省略されることが多い
6. よくあるエラーと対処
- 文字集合の不一致: Base64URL を標準 Base64 として復号して失敗。
- パディング不足: ライブラリによっては
=が必要。 - 二重エンコード: encode が重複し、decode 1 回では戻らない。
- 文字コード混在: UTF-8/UTF-16 の扱い違いで文字化け。
まず入力形式を特定し、次にパディングと文字集合を確認し、最後に往復テストで検証するのが確実です。
7. 性能とセキュリティの実務ポイント
- 大容量バイナリを Base64 で JSON に直接入れない。
- サービス間で Base64 か Base64URL かを明確に合意する。
- Base64 を秘匿化手段として扱わない。
- decode エラー率を監視し、連携不整合を早期検知する。
まとめ
Base64 は「互換性のための表現形式」です。暗号化ではありません。サイズ増加と URL 変種の違いを理解して使い分けることで、API 設計とフロントエンド連携の品質が大きく向上します。