これら 3 つの名前は、関連するバイナリからテキストへのスキームを表していますが、異なる制約を果たします。 Base64 および Base64URL は 6 ビット グループを使用します。標準 Base32 は、5 ビット グループとより小さなアルファベットを使用します。正しい選択は、転送、保管、受信アプリケーションが正確に保存できるものです。
長さの前にアルファベットを比較する
標準 Base64 では、大文字と小文字、数字、プラス、スラッシュが使用されます。 Base64URL は、最後の 2 文字をダッシュとアンダースコアに置き換えます。どちらも大文字と小文字が区別されます。標準 RFC Base32 では、大文字の A ～ Z と数字 2 ～ 7 が使用されます。デコーダは便宜上小文字を受け入れることができますが、プロトコルはそれが許可されるかどうかを示し、正規の出力を定義する必要があります。
大文字と小文字を区別しないチャネルでは、適切に指定された Base32 値を保持しながら、Base64 値を破棄できます。 URL トークンには、電話で読み上げられるコードとは異なる制約があります。サンプルがいかに短いかだけで選択しないでください。
サイズのトレードオフを理解する
最後の部分グループを無視すると、Base64 には 1 バイトあたり約 1.33 文字が必要で、Base32 には 1.6 文字が必要です。標準の埋め込み Base32 は、5 バイトの 8 文字グループを出力します。文字 f を含む 1 バイトの場合、共通ベクトルは次のとおりです。 Zg== Base64 および MY====== Base32 で。入力が小さいとパディングのオーバーヘッドが大きくなるため、現実的なペイロード長を比較してください。
Payload bytes: 66 (ASCII f)
Base64: Zg==
Base64URL: Zg== (or Zg when the protocol omits padding)
RFC Base32: MY======Base32 のバリアントを混合しないでください
Crockford Base32 は人間が判読できる識別子を中心に設計されており、RFC Base32 とは異なるアルファベットと曖昧さのルールを使用しています。 Base32hex も異なります。あるバリアントによって生成された値を、やみくもに別のデコーダに渡すことはできません。ドキュメント内のバリアント、アルファベット、パディング ポリシー、およびチェックサム動作に名前を付けます。
エンコーディングも認証を提供しません。タイプを間違えた値が構文的に有効であり、別のバイトにデコードされる可能性があります。ユーザーがコードを転写する場合は、アルファベットがすべてのエラーをキャッチすると仮定するのではなく、プロトコルで定義されたチェックサムまたは検証手順を考慮してください。
契約書を完全に書き留めます
関連する場合、入力バイト順序、空入力の動作、先行ゼロの保持、最大長、空白の受け入れ、および無効な文字の処理を指定します。値の高いバイトと部分的なグループを含むテスト ベクトルを含めます。選択したエンコーダーとデコーダーを相互に使用するだけでなく、それらのベクトルに対して独立して使用します。そうしないと、一致するバグがラウンドトリップを通過するように見える可能性があります。標準形式と参照ベクトルは次のとおりです。 RFC 4648。