Open1
Base64について📝
まさぴょん🐱Base64について📝
定義と仕様
- RFC 4648 で標準化された binary-to-text エンコーディング — 任意のバイナリデータを ASCII 文字列に写像する 。
- アルファベットは
A-Z a-z 0-9 + /（計 64 字）とパディング用=。 - 3 バイト ⇒ 4 文字の変換で、33 % のサイズ増が生じる 。
- MIME では 76 文字ごとに改行を入れる運用が推奨される 。
処理の流れ
- 入力を 24 bit（3 byte）ブロックに分割。
- 各 6 bit を 0–63 の整数と見なし、対応する文字へ置換。
- データ長が 3 の倍数でない場合は
=で埋めて長さを揃える 。
主な用途
| 代表例 | なぜ Base64? |
|---|---|
| 電子メール添付 (MIME) | SMTP は 7-bit ASCII 想定のため |
HTTP data: URL |
画像やフォントを CSS/HTML にインライン埋め込み |
| Basic 認証ヘッダー |
user:pass を ASCII で送るため |
| JSON/Web API でのバイナリ転送 | 文字列にしてレスポンスに含める |
Base64 のバリエーション
Base64URL
-
+ /を- _に置換、=パディング省略可 。 - URL パスやクエリに安全に埋め込める（
+や/は予約字）ため JWT などで採用。
ラインラップ・改行
- MIME 版は 76 文字ごとに CRLF を入れる が、Web API では通常改行を入れない実装が多い。
Base64 の利点と注意点
| 項目 | 内容 |
|---|---|
| 利点 | どのテキストチャネルでも文字化けせず転送／保管できる。ブラウザ実装 (btoa/atob) や主要言語ライブラリが標準搭載 |
| 欠点 | サイズ 1.33 倍、CPU コスト増。暗号ではなく 可逆エンコード なので秘匿効果は無い。誤って「暗号化」と混同しないよう注意。 |
Base64 に“近い”エンコーディング方式
| 方式 | 基数 | 文字集合の例 | 膨張率* | パディング | 主な用途・特徴 |
|---|---|---|---|---|---|
| Base64 | 64 | A–Z a–z 0–9 + / | 約 1.33× | = | MIME 添付、JWT、画像 data URI |
| Base64URL | 64 | A–Z a–z 0–9 - _ | 同上 | (省略可) | URL/JWT 対応版 |
| Base32 | 32 | A–Z 2–7 | 約 1.6× | = | QR コード、TOTP (Google Authenticator) |
| Base16 (Hex) | 16 | 0–9 A–F | 2× | なし | デバッグ表示・チェックサム |
| Base58 / Base58Check | 58 | 0–9 A–Z a–z (除外字あり) | 約 1.37× | なし | Bitcoin アドレス・秘密鍵 — 視認性と誤読防止 |
| Base62 | 62 | 0–9 A–Z a–z | 約 1.34× | 実装依存 | URL 短縮 ID、ユニークキー |
| Ascii85 (Base85) | 85 |
!〜u など 85 字 |
約 1.25× | なし | PDF/PostScript、Git バイナリパッチ — 効率最優先 |
*膨張率は「エンコード後サイズ / 元バイト数」。理論値で実際は改行やメタ情報分が加わる場合あり。
それぞれの特徴をひと言で
- Base32 — 大文字だけで人が読み書きしやすく、QR/OTP 向き。
-
Base58 —
0 O I lなど紛らわしい字を排除し、コピー時の誤認を低減。 - Base62 — 英数字のみで URL・ファイル名に安全、短縮 URL サービスが多用。
- Ascii85/Base85 — 4 byte→5 字で Base64 より 10 % 以上小さくでき、PDF 内部表現に採用。
まとめ
- Base64 は 「テキストしか通れない経路でバイナリを壊さず運ぶための可逆エンコード」 であり、暗号化手段ではない。
- 6 bit 単位のマッピングと
=パディングという単純構造で、主要言語・ブラウザが標準関数を備える。 - 「URL に埋め込む」「人が読み書きする」「容量をさらに削りたい」など目的ごとに Base32/58/62/85 など多彩な派生・類似方式が選択される。
- 要件（可搬性・省サイズ・判読性）を見極め、最適な方式を選ぶのが実装・運用のポイントである。