Base64 アルファベット表

64 の文字

Base64 は入力を 3 バイト（24 ビット）ずつ読み取り、4 つの 6 ビット値に分割します。0〜63 の各値が、この表のインデックスになります。順序は RFC 4648 で決まっており、0〜25 が大文字、26〜51 が小文字、52〜61 が数字、その後に + と / が続きます。最後の列はその文字の ASCII コードで、実際に保存・送信されるのはこの値です。

覚えておくと便利な範囲が 2 つあります。A〜P（0〜15）の文字はすべてビット 00 で始まり、w〜/（48〜63）の文字はすべて 11 で始まります。手作業で接頭辞を確認するときは、これだけ知っていれば頭の中で 1 文字をデコードできます。ビット分割の具体例は Base64 の仕組み にあります。

アルファベットの順序は ASCII の順序とは異なります。ASCII では + と / が先頭で、次に数字、大文字、小文字の順です。そのため Base64 文字列をソートしても、元のバイト列の順にはなりません。+A==（バイト F8）は AA==（バイト 00）より前に並びます。エンコード後の値を元のバイト列と同じ順に並べたい場合は、RFC 4648 の base32hex か、普通の 16進数を使ってください。

URLセーフなアルファベット

+ と / はどちらも URL の中で特別な意味を持ちます。+ はクエリ文字列やフォームデータでスペースとしてデコードされ、/ はパスの区切りです。RFC 4648 の 5 章で定義されている Base64URL は、インデックス 0〜61 はそのままで、最後の 2 つを入れ替えます。

ビット配置を含めてそれ以外はすべて同じなので、両者の変換は文字の置き換えと、パディングの追加・削除だけで済みます。JWT、多くの API トークン、ファイル名に使える識別子は Base64URL を使い、たいていは = を付けません。Base64URL エンコーダー なら直接生成できます。詳しい比較は Base64 と Base64URL の違い をご覧ください。

パディング文字

=（ASCII 0x3D）は 64 文字のアルファベットに含まれず、データを表すことはありません。入力の長さが 3 の倍数でないときに、最後の 4 文字のグループを埋めるためだけに使われます。

• 1 バイト余る場合：データ文字 2 つと ==
• 2 バイト余る場合：データ文字 3 つと =
• 余りがない場合：パディングなし

そのため、パディング付きの文字列の長さは必ず 4 の倍数になり、=== が現れることはありません。パディングなしの場合、長さを 4 で割った余りは 0、2、3 のいずれかで、1 になることはありません。= を省略してよい場面と、元に戻す方法は パディングの解説 で説明しています。

どの文字がどこに現れるか

ビット配置から直接導かれるパターンがいくつかあります。いずれも、関係するすべてのバイト値を総当たりして確認しました。

== の直前には A、Q、g、w しか現れません。 1 バイト余る場合、2 文字目はデータ 2 ビットの後に 0 が 4 ビット続くので、インデックスは 0、16、32、48 のいずれかになります。= が 1 つの場合、3 文字目は末尾の 2 ビットが 0 なので、A E I M Q U Y c g k o s w 0 4 8 の 16 文字のどれかです。この位置にそれ以外の文字があれば正規形でないエンコードであり、厳格なデコーダーはエラーにします。

ランダムなバイト列では 64 文字すべてが均等に使われます。 ランダムなデータの 6 ビットグループは一様に分布するため、暗号化されたデータ、鍵、圧縮ファイルでは文字の分布が平坦になります。分布に偏りがあれば、テキストか何らかの構造を持つデータである手がかりです。

ASCII テキストでは、小文字の g〜z、数字、+、/ が先頭に来ることはありません。 4 文字グループの 1 文字目は、バイトの上位 6 ビットを表します。7 ビット ASCII では最上位ビットが 0 なので、この文字は必ず A〜f（インデックス 0〜31）の範囲に収まります。SGVsbG8gd29ybGQh（Hello world!）では、各グループの先頭は S、b、d、b です。

ASCII テキストの Base64 では、+ と / はまれです。 0x80 未満のバイトでは、+ が現れるのはグループの 4 文字目で、3 バイト目が > か ~ の場合に限られます。/ がその位置に現れるのは、そのバイトが ? か DEL 制御文字の場合だけです。Hi?> が SGk/Pg== に、<b> が PGI+ にエンコードされるのはこのためです。

A の連続はゼロバイト、/ の連続は 0xFF です。 AAAA は 00 バイト 3 つ、//// は FF バイト 3 つです。A が長く続くのは、疎なバイナリ形式、UTF-16 テキスト（Hello は SABlAGwAbABvAA==）、SSH 鍵の先頭にある長さフィールドによく見られます。見分けやすいパターンは よくある Base64 の接頭辞 にもまとめています。

その他の Base64 アルファベット

6 ビットあたり 64 文字という考え方はそのままに、異なる文字を選んだシステムもいくつかあります。

• IMAP は、/ がメールボックス名の階層区切りとしてよく使われるため、/ を , に置き換えます。Entwürfe というフォルダは Entw&APw-rfe として保存されます。
• bcrypt は . と / を先頭に移し、文字を数字より前に置きます。ソルトとハッシュはこのアルファベットによるパディングなしの Base64 なので、標準のデコーダーでは正しいバイト列が得られません。
• crypt(3) は ASCII 順の ./0-9A-Za-z を使います。さらに最下位ビット側からビットを詰めるため、アルファベットを置き換えても、標準のデコーダーではハッシュのバイト列を再現できません。
• uuencode と xxencode は MIME 以前の方式です。uuencode と xxencode のツールで、どちらも読み書きできます。

Base32、Base58、Base85 のようにアルファベットの文字数が異なるエンコード方式については、Base64 と 16進数・Base32・Base58・Base85 の比較 をご覧ください。ここで使った用語の定義は 用語集 にあります。

よくある質問