Base64 とURLエンコード
どちらの欄に入力しても、もう一方が同時に変わります。 入力した内容はこの画面の中だけで処理します。
よくある質問
Base64 は暗号ですか？
暗号ではありません。誰でも元に戻せる変換なので、秘密を守る用途には使えません。目的は、任意のデータを ASCII の文字だけで表すことです。パスワードを Base64 にしただけで安全になったと考えるのは危険です。
日本語を変換すると文字化けするのはなぜですか？
Base64 は文字ではなくバイト列を扱う仕組みなので、日本語をどの文字コードでバイトに直すかが決まっていないと結果が食い違います。この計算機は UTF-8 で符号化しています。ブラウザの標準機能をそのまま使った実装では、日本語を渡した時点で処理が止まるものもあります。
末尾の = は何ですか？
詰め物です。Base64 は3バイトを4文字に変換するため、元のバイト数が3の倍数でないときに桁が余ります。その余りを = で埋めて、長さを4の倍数に揃えています。1〜2個つくことがあります。
Base64 にすると容量はどれくらい増えますか？
約1.33倍です。3バイトを4文字で表すためで、詰め物の分を含めるとわずかに増えます。画像を Base64 にして HTML に直接埋め込む手法では、この増加分と、別ファイルとして読み込む場合の通信の往復とを比べて判断します。
URLエンコードとの違いは何ですか？
目的が違います。URLエンコードは、URL の中で特別な意味を持つ文字（? & = / など）や日本語を、%E3%81%82 のような形に置き換えて誤解釈を防ぐものです。ASCII の英数字はそのまま残るため、元の文字が読める状態で残ります。Base64 はすべての文字を置き換えるので、元の内容は読めなくなります。
base64url とは何ですか？
URL とファイル名の中で使うための Base64 の変種です。RFC 4648 の第5節で、62番目の + を -（マイナス）に、63番目の / を _（下線）に置き換えた表として定められています。違いはこの2文字だけなので、base64url の文字列は - を + に、_ を / に戻せば同じ手順で読めます。詰め物の = は省かれていることがあります。
Base64 の文字列に改行が入っているのはなぜですか？
メールの添付で使う MIME（RFC 2045）が、Base64 の行を 76 文字以内にすると決めているためです。改行は運ぶ都合で入ったもので、読むときは取り除きます。この計算機も空白と改行を除いてから変換するので、改行入りのまま貼れます。
どちらの欄に入力しても同時に変換します。日本語と絵文字はそのまま扱えます。
Base64 が生まれた理由
電子メールの仕組みは、もともと ASCII の文字だけを運ぶ前提で作られました。 途中の中継サーバーが8ビット目を落としたり、特定のバイトを制御信号として解釈したりするため、 画像などのデータをそのまま流すと壊れます。
そこで、任意のバイト列を英数字と +/= だけで表す方法が必要になりました。 6ビットを1文字に 割り当てると 2 の6乗で64通りになり、これが「64」の由来です。 3バイト（24ビット）を 4文字（6ビット×4）に変換すると、ちょうど割り切れます。
いまでは添付ファイルのほか、HTML に画像を直接埋め込む data URL、 アクセストークンの受け渡しなど、テキストしか通らない経路にデータを乗せる場面で広く使われています。
読めない入力を空にしない理由
Base64 として形は正しくても、元に戻したバイト列が UTF-8 の文字列にならないことがあります。 別の文字コードで作られた場合や、途中で切れている場合です。
こうしたとき、結果を空欄にしたり、文字化けした記号を出したりする実装があります。 どちらも「変換に失敗した」のか「元がそういう内容だった」のかが利用者に分かりません。 この計算機では、戻せないことを理由とともに表示します。
= が付く決まりと、長さが 4/3 倍になる理由
RFC 4648 の第4節は、入力を 24 ビット（3バイト）ずつ区切って 4 文字にすると決めています。 だから n バイトの Base64 は「n を 3 で割って切り上げた数 × 4」文字になり、 最後の組が 3 バイトに足りないときだけ = で埋めます。足りない場合は 2 通りです。
| 入力 | Base64 | = の数 |
|---|---|---|
abc（3バイトちょうど） | YWJj | 0 |
ab（2バイト余る） | YWI= | 1 |
a（1バイト余る） | YQ== | 2 |
= は 64 文字の表に入っていない 65 文字目で、「特別な処理を示す」文字として定義されています。 余りが 1 バイトなら 2 文字と ==、2 バイトなら 3 文字と = です。 RFC 2045 も第6.8節で、符号化したデータは「一貫して約 33 パーセント大きくなる」と書いています。
改行が入る Base64 と、URL に貼れる base64url
メールの添付から取り出した Base64 は、76 文字ごとに改行されています。 これは MIME（RFC 2045 第6.8節）が「1 行 76 文字以内」と決めているためです。 RFC 4648 の第3.1節はこの長さが SMTP の制限に由来すること、それより前の PEM では 64 文字だったことを説明したうえで、参照する仕様が明示しない限り改行を加えないよう求めています。 この計算機は空白と改行を取り除いてから読むので、どちらの形も貼れます。
URL の中でそのまま使える文字は限られていて、Base64 の + と / はその外にあります。 そこで第5節は、62 番目を -（マイナス）、63 番目を _（下線）に置き換えた表を定め、base64url と呼んでいます。違いはこの 2 文字だけです。 = も URL では % 付きの形に置き換えられることが多いため、 長さが分かっていれば詰め物を省いてよいとあります。 ~ と . が候補から外れた理由（~ はファイルシステムで特別な意味を持ち、. は複数使えないことがある）も同じ節に書かれています。
出どころ: RFC 4648「The Base16, Base32, and Base64 Data Encodings」（新しいタブで開きます）（第3.1節・第4節・第5節）と RFC 2045「MIME Part One」（新しいタブで開きます）（第6.8節）の原文。