Base32が存在する理由はひとつ——コードを人が読み上げたり、電話で伝えたり、手で書き写したりする場面では、Base64の64文字よりも32文字だけのアルファベットのほうが誤りが起きにくいからだ。
QRコードが読めないときに現れるBase32
Google AuthenticatorなどのTOTPアプリでQRコードをスキャンできない場合、代わりに手入力用の「セットアップキー」が表示される——このキーはBase64ではなくBase32でエンコードされている。日本ではQRコード自体がデンソーウェーブによって発明された技術であり、2段階認証の設定はほぼQRコード読み取りだけで完結するため、手入力用のBase32キーが表に出る場面はあまり多くないが、カメラが使えない環境やPC間の移行では必ず登場する。
読み上げても誤解されにくいアルファベット
Base32は0、1、8、9と、文字のO、I、Lを完全に除外している——これらは電話越しや解像度の低い画面で最も混同されやすい文字だ。ローマ字入力に慣れた日本語話者にとっても、数字の0とアルファベットのOを声だけで区別するのは難しく、Base32はこの曖昧さをアルファベットの設計そのもので解消している。
実際に使われている場面
- Torネットワークの.onionアドレス——56文字のサブドメイン部分はEd25519公開鍵をBase32でエンコードしたもの。
- DNSラベルやサブドメイン——仕様上、大文字と小文字を区別しない。
- 紙のレシートやクーポンに印刷された紹介コード——顧客がウェブサイトに手入力する場面で使われる。
読みやすさの代償——文字列が長くなる
アルファベットの文字数が少ない分、1バイトを表すのに必要な文字数が増える——結果としてBase64よりも約60%長くなる。20バイト程度の秘密鍵ならこの差はわずかだが、数メガバイトのファイルにBase32を使うのは現実的ではない。
Base32とBase32hexは互換性がない
RFC 4648はBase32hexも定義しており、こちらはA–Z2–7の代わりに0–9A–Vというアルファベットを使い、エンコード後の文字列のソート順を元のバイト列の順序と一致させる——一部のデータベースにとって重要な性質だ。一方でエンコードした文字列をもう一方でデコードすると正しい結果が得られないため、デコード前にどちらの方式が使われているかを確認しておく必要がある。