受け手が指定する文字種を選ぶ
最も短そうな名前ではなく、受け手のシステムが要求する形式から選びます。標準の Base64 は英字、数字、プラス記号、スラッシュを使いますが、URL セーフな Base64 を指定する場面もあります。Base32 は大文字の英字と 2～7 の数字を使います。Bitcoin 型の Base58 では、手で写すと紛らわしい数字のゼロ、大文字の O と I、小文字の l などを除きます。異なる文字種でも同じバイト列を表せますが、ある方式を期待する受け手が別方式を自動認識するとは限りません。どの方式もメッセージを暗号化しません。目的は表現の変換であり、適切なデコーダーがあれば誰でも元のバイト列を復元できます。
同じ入力を三方式で試す
ASCII 文字列 Man を例にします。UTF-8 のバイト列は16進数で 4D 61 6E です。標準の Base64 では TWFu、RFC 4648 の Base32 では8文字のブロックを満たすパディングを含めて JVQW4=== と表します。リンク先の Base58 ツールは、等号によるパディングなしで、Bitcoin の文字種を使って同じバイト列を表します。出力が異なって見えるのは、各方式がビット列や整数値を異なる方法で分割するためで、元の文字列が変わったわけではありません。埋め込み Base32 エンコーダーに Man を入れ、対応するデコーダーで戻してください。同じ入力を Base64 と Base58 のツールでも試し、バイト列に戻してから結果を比較しましょう。
- UTF-8：Man → 4D 61 6E
- Base64：TWFu／Base32：JVQW4===
- Base58：別の文字種で表す → Man に復号できる
パディング、変種、チェックサム
Base64 と Base32 の仕様では等号によるパディングが扱われます。パディングを意図的に省くアプリケーションもあり、受け手があり・なしのどちらを要求するかは契約どおりに合わせる必要があります。この実装の Base58 には等号のパディングがありません。また、単純な Base58 エンコーディングと Bitcoin の Base58Check は別です。Bitcoin アドレスには、Base58 表記の前にバージョン情報とチェックサムが含まれます。MultiVerto の Base58 変換ツールは UTF-8 テキストをエンコードするもので、Bitcoin アドレスの生成も Base58Check チェックサムの検証もしません。同様に、標準の Base64 から Base64URL に替えると、URL で重要となる文字種が変わります。元のバイト列が正しくても、変種が違えばトークンは拒否され得ます。
文字列を比べる前にバイト列を確認する
テキストはまず文字コードに従ってバイト列になります。MultiVerto の Base32 と Base58 のテキストツールは UTF-8 を使うため、アクセント付きの文字は複数バイトになることがあります。サイズを見積もるときは目に見える文字数ではなくバイト数を数えてください。コピーした元テキストに空白が混じると結果も変わる場合があります。不一致を調べるには、元のテキスト、UTF-8 バイト列、方式の名前、パディング方針、想定するデコーダーを記録します。出力をデコードして再現されたテキストと比較してください。実際の処理で UTF-8 テキストではなく任意のバイナリーファイルを転送するなら、受け手のツールが生のバイト列を保つことを確認しましょう。テキスト専用の変換ツールは汎用のバイナリーファイル用プロトコルではありません。
受け取り側の仕様で指定された表現を使う
MIME フィールド、API トークン、QR コードの内容、手書きで写す識別子のどれに使う場合も、文字種を選ぶ前に該当する仕様を読んでください。Base64 は機械同士のデータ交換で一般的です。Base32 は大文字・小文字を区別しない場面や文字種が制限された場面に向き、Base58 は一部のシステムで人が転記する用途と結び付いています。ただし、これは傾向であって保証ではありません。エンコードしただけで整合性や真正性が得られると思わないでください。周囲の形式にチェックサム、署名、認証付き保護がなければ文字列は改変され得ます。Man のような短いテスト用データを統合テストに残し、データがアプリケーションを出る境界でエンコードとデコードの両方を確認しましょう。決め手は、受け手が出力の文字と規則を正確に受け入れるかです。