Base62 では通常、数字と大文字と小文字が使用されます。そのため、句読点のないコンパクトな識別子にとっては魅力的です。 Base64 は 64 個のシンボルを使用し、ビットのグループを直接パックします。名前は似ていますが、Base62 実装では入力を数値としてモデル化することが多く、相互運用性については別の疑問が生じます。
アルファベット順は形式の一部です
2 つの Base62 ライブラリでは、数字、大文字、小文字の異なる順序を選択できます。同じ表示文字列が異なる数値を表します。を使用したシステム 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz 小文字を最初に置くものとは一致しません。プロトコルにアルファベットとテスト ベクトルを記録します。 「Base62」だけでは不十分です。
大文字と小文字の区別も重要です。小文字のプロキシ、大文字と小文字を区別しないデータベース照合順序、または手動で正規化された識別子により、その値が変更される可能性があります。ストレージ層が大文字と小文字を区別しない場合、追加の設計上の決定がなければ、通常の Base62 も Base64 も安全な表現ではありません。
バイトをエンコードするときに長さを維持する
16 進数を含む 2 つのファイルを考えてみましょう。 01 そして 0001。符号なし整数として解釈され、どちらも値 1 を持ちます。単純な整数から Base62 への変換では区別が失われます。バイト指向の Base62 形式には、明示的な先行ゼロ処理または長さフィールドが必要です。これは、ランダム トークンと固定長の暗号値に特に関係します。
const a = BigInt('0x01');
const b = BigInt('0x0001');
console.log(a === b); // true: numeric equality loses byte length値の意味に基づいて選択してください
1 つのアプリケーションの制御下でデータベース整数を短縮する場合は、文書化された Base62 アルファベットが便利です。独立したシステム間で任意のバイトを転送する場合、通常、Base64URL はより明確な標準化されたコントラクトを提供します。同じ 6 ビットのグループ化を維持しながら、標準の Base64 句読点をダッシュとアンダースコアに置き換えます。
エンコーディングはランダム化ではありません。連続した整数は、Base62 変換後も予測可能です。識別子が推測に抵抗する必要がある場合は、暗号化ランダム ソースを使用して十分な予測不可能なエントロピーを生成し、結果として得られるバイトを長さを失わずにエンコードします。コンパクトに見えるトークンを、その生成が安全であることの証拠として扱わないでください。
出力サイズを比較する場合は、プレフィックス、パディング ルール、および任意の長さのメタデータを含めます。少なくとも空の入力、ゼロ バイト、先行するいくつかのゼロ、および高値バイトをラウンドトリップします。 Base64URL アルファベットは次のように標準化されています。 RFC 4648; Base62 アプリケーション自体で追加の詳細を指定する必要があります。