Base64の末尾の=は、消してもいい？

同じような長い文字列なのに、あるものは+や/を含み、別のものは-や_を含む。末尾に=があるものとないものもあります。Base64の仲間には使う場所に合わせた違いがあり、デコードで失敗したときは、その違いから見直すと近道です。

Base64urlは二つの文字を置き換えた表記

Base64はバイト列を限られたASCII文字で表す符号化です。Base64urlは、通常のBase64で使う+と/を、それぞれ-と_へ替えます。URLやファイル名で扱いやすい文字にしたもので、暗号化の強さが変わるわけではありません。

同じ2バイトを表すと

このFB FFは文字ではなくバイトの例です。UTF-8の文章としてデコードできるとは限りません。文字列向けの変換画面でエラーになっても、Base64の対応関係そのものが誤っているとは限りません。

元のバイト（16進）	Base64	Base64url（パディング付き）
FB FF	+/8=	-_8=

=は3バイト単位の最後をそろえる目印

Base64は3バイトを4文字に対応させます。最後が1バイトなら==、2バイトなら=を付けます。入力が3バイトの倍数なら付けません。だから=がないだけでBase64urlだと判別することもできません。

ASCIIの短い文字列で見比べる

=は、元の文章にイコール記号が入っているという意味ではありません。元の文字列が「=」一文字なら、そのBase64はPQ==です。文字数とバイト数が違う日本語でも、数える単位はバイトです。

元の文字列	UTF-8でも同じバイト数	Base64
A	1	QQ==
AB	2	QUI=
ABC	3	QUJD
ABCD	4	QUJDRA==

省略してよいかは、Base64を使う側の仕様で決まる

RFC 4648 §3.2では、参照元の仕様が明示的に別の扱いを定めない限り、適切なパディングを付けることをMUSTとしています。「URL向けだから全部削除する」という決め方はできません。一方、JWTで使うJWSのBase64url表記は、RFC 7515 §2で末尾の=を省略するよう定義されています。

デコードできたことと仕様に合うことは別

寛容なデコーダーが省略形を読めても、受け渡すAPIが同じ形を認めるとは限りません。保存・送信する側ではAPIの仕様へ合わせ、受け取る側ではその形式に必要な文字種・長さ・パディングを検証します。Base64urlという名前だけでは、個別のパディング方針まで決めつけないようにします。

省略形の長さから足す個数はわかるが、正しさまではわからない

パディングなしのBase64urlを、パディングが必要なデコーダーへ渡すときは、文字を置き換えたうえで長さを4の倍数にそろえます。これは形式がBase64urlだとわかっている場合の変換手順です。未知の文字列を直す万能な方法ではありません。

末尾の=を除いた長さで考える

この条件だけで正しい符号化だとは判定できません。許されない文字、ゼロでない未使用ビットなども問題になります。署名を検証するデータは、見やすく再エンコードしてから検証するのではなく、署名方式が定める元の入力を使います。

長さを4で割った余り	補う文字	例
0	なし	QUJD
2	==	QQ → QQ==
3	=	QUI → QUI=
1	正常な省略形にならない	A

文字を戻すには、Base64の次に文字コードの読み取りがある

Base64を戻して得られるのはバイト列です。そのバイトをUTF-8の文章として読む処理は次の段階です。画像や圧縮データを文章向けデコーダーへ入れても、読める文章にはなりません。また、Base64は秘密にする仕組みではなく、読める人を制限しません。

Online Toolsで試せる範囲

エンコード・デコードツールのBase64モードは、入力文字列をUTF-8として符号化し、復号したバイトもUTF-8の文字列として読みます。Base64urlを直接選ぶモードやバイナリファイルの復元機能はありません。JWTの中身を読むなら、区分とBase64urlを扱うJWTデコーダーが対応します。

短い文字を変換して、元に戻してみる

エンコード・デコードツールでA・AB・ABCをそれぞれBase64へ変換し、表と比べられます。JWTの区分はJWTデコーダーへ。実際の認証情報を例に使わず、JWTのデコードと検証の違いにある学習用データで試せます。