基礎知識 · テキスト・データ・セキュリティ
Base64 エンコードとは？
結論
Base64 は、印字可能な 64 種類の文字（A–Z、a–z、0–9、+、/）と、パディング用の = だけでバイナリデータを表す方法です。3 バイトごとに 6 ビットずつ4つのグループに分け、各グループを1文字に対応させるため、「Man」は「TWFu」になります。メール、JSON、URL のようにテキストしか通せない経路でもバイナリデータを安全に送れますが、サイズは約 33% 増えます。これはエンコードであって暗号化ではありません。
Base64を開くBase64 の仕組みを順番に見る
Base64 は RFC 4648 で定義されています。64 = 2⁶ なので出力の1文字はちょうど 6 ビットを表し、3 バイト（24 ビット）がぴったり4文字に対応します。
| 手順 | M | a | n |
|---|---|---|---|
| ASCII コード | 77 | 97 | 110 |
| 2進数（各 8 ビット） | 01001101 | 01100001 | 01101110 |
- 24 ビットをつなげます：
010011010110000101101110。 - 6 ビットずつ4つに分けます：
010011010110000101101110。 - 数値に変換します：19、22、5、46。
- それぞれを変換表で引きます（0 = A、25 = Z、26 = a、51 = z、52 = 0、61 = 9、62 = +、63 = /）：T、W、F、u。
- 結果：
TWFu。
= によるパディング
入力の長さが 3 の倍数でないときは、最後のグループをゼロのビットで埋め、足りないバイトを = で示します。そのため出力の長さは必ず 4 の倍数になります。
| 入力 | バイト数 | Base64 |
|---|---|---|
M | 1 | TQ== |
Ma | 2 | TWE= |
Man | 3 | TWFu |
Hello | 5 | SGVsbG8= |
é（UTF-8 のバイト列 C3 A9） | 2 | w6k= |
n バイトをエンコードした長さは 4 × ceil(n ÷ 3) 文字です。1 MB のファイルは約 1.33 MB のテキストになり、MIME のメールでは 76 文字ごとに改行が入るため、増加分はさらに少し大きくなります。
Base64 が使われている場所
- メールの添付ファイル：初期のメールシステムは 7 ビットのテキストしか運べなかったため、MIME はファイルを Base64 でエンコードします。
- データ URL：HTML や CSS に埋め込む小さな画像で、
data:image/png;base64,iVBORw0KGgo...のように書きます。 - 画像、鍵、証明書などのバイナリデータを運ぶ必要がある JSON や XML の API。
- JSON Web Token（JWT）：ヘッダーとペイロードは Base64url でエンコードした JSON です。
- TLS 証明書や鍵の PEM ファイル：
-----BEGIN CERTIFICATE-----などの行の間に Base64 を挟んでいます。 - HTTP Basic 認証：
username:passwordを Base64 でエンコードして送ります。
画像をデータ URL として埋め込むとネットワークリクエストが1回減りますが、サイズが 33% 増え、個別にキャッシュできなくなります。そのため、効果があるのはふつうごく小さな画像だけです。
Base64 と Base64url、その他のエンコード
標準の Base64 は + と / を使いますが、これらは URL やファイル名で特別な意味を持ちます。同じ RFC にある URL セーフ版は、これらを - と _ に置き換え、= のパディングを省略することもよくあります。
| エンコード | 使う文字 | サイズの増加 | 用途の例 |
|---|---|---|---|
| Base16（16進数） | 0–9、A–F | 100% | ハッシュ、カラーコード |
| Base32 | A–Z、2–7 | 60% | 二要素認証のシークレット |
| Base64 | A–Z、a–z、0–9、+、/ | 33% | メール、データ URL、PEM |
| Base64url | A–Z、a–z、0–9、-、_ | 33% | JWT、URL パラメーター |
よくある間違い
- テキストはまずバイト列に変換する必要があり、通常は UTF-8 を使います。JavaScript の
btoa()は、文字列を先に UTF-8 でエンコードしておかないと、絵文字や漢字など Latin-1 の範囲外の文字でエラーを投げます。 - 標準の文字セットと URL セーフの文字セットを混ぜるとデコードエラーになります。標準のデコーダーを使う前に
-と_を+と/に置き換えましょう。 - パディングがないと、厳密なデコーダーでは失敗することがあります。長さが 4 の倍数になるまで
=を追加しましょう。 - メール形式のエンコードで入った改行は、取り除かないと受け付けないデコーダーもあります。
よくある質問
Base64 でデータが大きくなるのはなぜですか？
3 バイトが4文字になり、各文字が丸ごと 1 バイトとして保存されるため、出力は入力より約 33% 大きくなります。
Base64 は安全ですか？
いいえ。何も隠しておらず、デコードに鍵は要りません。データを守るには AES などの本物の暗号化を使い、Base64 はその結果をテキストとして運ぶためだけに使いましょう。
Base64 の末尾の = は何を意味しますか？
パディングです。= が1つなら最後のグループは 2 バイト、== なら 1 バイトしかなかったことを示します。
Base64 の文字列はどう見分けますか？
英字、数字、+ と /（または - と _）だけでできていて、長さはたいてい 4 の倍数で、末尾に = が1つか2つ付くことがあります。eyJ で始まる文字列は Base64 でエンコードした JSON であることが多く、これは {" で始まる JSON テキストをエンコードすると eyJ で始まる文字列になるためです。