Base64 とは何か？
Base64 はバイトを 64 個の読める文字で書き直し、テキスト用に作られた経路 — メール本文、JSON 文字列、XML 属性、URL — をデータが生き延びられるようにします。3 バイトごとに 4 文字になります。名前の由来です — アルファベットは 64 記号を持ち、各記号がちょうど 6 ビットを運びます。
これはトランスポートエンコーディングであって、セキュリティ対策でも圧縮でもありません。出力は入力より約 3 分の 1 大きくなり、文字列を持つ誰でもそれをそのまま戻せます。データが改変されたかを知りたいならそれはハッシュ（ハッシュ生成）であり、秘密にしておきたいならそれは暗号化です。Base64 はどちらでもありません。
覚えておくべきただ一つの数字：入力 3 バイトが出力 4 文字になります。このページの他のすべてはここから導かれます。4 文字が 24 ビットを運び、24 ビットはちょうど 3 バイトなので、データが失われたり捏造されたりすることは決してありません — ただし最後の、入力が 3 バイト組の最終グループを満たさない場合を除いて。
このページが使える 5 つのアルファベット
最初の 2 行は標準で、残りの 3 行は Unix の周りで育った慣習です。5 つすべてが 1 文字あたり同じ 6 ビットを運び、どの 64 文字が運ぶかだけが違うため、同じバイトが 5 つの異なる文字列になります。文字列の内部にはどのアルファベットがそれを生成したかの情報はなく、だからこそアルファベットセレクターは標準がデフォルトで、URL セーフのチェックボックスが 2 行目へのショートカットになっています。
このページが候補を選ぶ方法：セレクターは両方向のデフォルトです。デコード時、右のパネルは文字列そのものも読みます — - と _ は URL セーフアルファベットからしか来られず、+ や / は標準からしか来られず、先頭付近の / や . は 2 つの Unix アルファベットを指します。現在の入力を読めるすべてのアルファベットが、候補である/ない理由とともにそこに列挙されます。
折り返し：76 文字と 64 文字
MIME は、どの行も不当に長くならないメールに収まる Base64 を求め、CRLF 区切りの 1 行 76 文字に落ち着きました。証明書と鍵を包む PEM ファイルは 64 文字を使います。改行はデータの一部ではありません：デコーダーは何をするよりも先に改行を取り除いて行を結合し戻すため、折り返した文字列とそうでない文字列はまったく同じバイトにデコードされます。最終行以外の各行は 4 文字組の整数倍を保持し、これが結合し戻す際の安全性を保証します。
このページは幅を選ばない限り出力を 1 行に保ち、デコーダーは改行の有無どちらの入力も受け付けます。このページが書く改行はテキストボックスが保持できる素の改行（LF）です。MIME メール本文は伝統的に各改行の前に復帰（CR）を置き、現行のどのデコーダーも両方を受け付けます。
パディングと、それを省略できる理由
入力が 3 バイトの倍数でないとき、最後の 4 文字組は不完全で、1 個または 2 個の = がそれを埋めます。これらはデータをまったく運びません：4 文字のうち何個が本物かを示すだけです。デコーダーは長さからそれを導けるため、URL セーフ Base64 は伝統的にパディングを省きます — = は URL やファイル名で扱いにくく、一部のシステムはこれをパーセントエンコードします。
オプション行のチェックボックスは、URL セーフアルファベット選択時にパディングを保持します。他は何も変わりません。データを運ぶ文字はどちらの場合も同一です。
よくある誤解
- 「Base64 はデータを隠す」 違います。鍵のない置換であり、要点はどの読者も元に戻せることです。パスワードやトークンを Base64 で包んでも、誰が読めるかは一切変わりません。
- 「Base64 は圧縮する」 逆です。入力 3 バイトごとに出力 4 文字になるため、テキストは運ぶデータより 3 分の 1 大きくなります。
- 「改行は値の一部」 改行は表示の問題です。足しても除いても、戻ってくるバイトは決して変わりません。
- 「URL セーフは別のエンコーディング」 2 文字を入れ替えた同じエンコーディングです：
+ が - に、/ が _ になり、文字列が URL パスやクエリ値にエスケープなしで置けるようになるだけです。
- 「デコードできる文字列は有効な Base64 に違いない」 アルファベット文字の任意の文字列は有効な Base64 です。6 ビット値のあらゆる組み合わせが有効なバイト列だからです。文字列が間違っていると判明するのは次の段階、そのバイトが想定された形式と照合されるときです。
- 「パディングが使われたアルファベットを教える」 教えません。多くの場合、文字も教えません：標準と URL セーフのアルファベットは 64 記号のうち 62 個で一致するため、短い文字列はしばしば両方で同じに読めます。
よく出る質問
Base64 文字列が 1 個の = で終わるときと 2 個のときがあるのはなぜ？ 1 個は最終グループが本物 3 文字（入力 2 バイト）を運ぶ意味、2 個は 2 文字（入力 1 バイト）を運ぶ意味です。= なしは入力長が 3 の倍数だったことを意味します。
Base64 は任意のバイナリファイルを表せる？ はい、それが主用途です。このページは入力を UTF-8 テキストとして扱います。テキストでないものをエンコードしたいときは、専用のファイル → Base64 ツールが生バイトを読み取ります。
API ではどのアルファベットを使うべき？ 受け側が文書化しているものなら何でも。URL セーフと言われたらそれを使い、何も言われず値が URL 内を移動するなら、パディング省略の URL セーフが安全な選択です。
出力は大文字小文字を区別する？ 完全に区別します。a と A は異なる値であり、Base64 が打ち間違いに対して Base32 や Crockford Base32 ほど優雅に耐えられない理由です。
