Base32 エンコードとデコード

機能

• 双方向の変換：テキスト ⇄ Base32
• 2つのアルファベット：標準 Base32（A–Z、2–7）と base32hex（0–9、A–V）
• = パディングを付ける／付けないを選べる（デコードはどちらも受け付けます）
• 日本語や emoji は UTF-8 バイトで処理し、各言語の標準実装と一致します
• デコードは小文字・空白・改行・欠けたパディングを許容します
• アルファベット外の文字は、どの文字かを示してエラーにします（黙って捨てません）

使い方

1. 方向を選びます：エンコードまたはデコード
2. アルファベットを選びます：標準 Base32 または base32hex
3. 入力欄に内容を貼り付けると、結果がリアルタイムで表示されます
4. 「コピー」で結果を取り出せます

よくある質問

Base32 と Base64 は何が違いますか？

同じバイト列を符号化するもので、違いは「6ビットではなく5ビットを何文字で表すか」とアルファベットの選び方だけです。Base64 は 64 文字を使い、3 バイトを 4 文字にします。Base32 は 32 文字を使い、5 バイトを 8 文字にします。Base32 の結果は 60% 長くなりますが、その代わりに文字種が少なく、紛らわしい文字を含まず、大文字小文字も区別しません。URL やデータベースには Base64 を、人が書き写したり読み上げたりする場合や機器のラベルには Base32 を選んでください。

なぜ Base32 の結果はこんなに長くなるのですか？

Base32 の1文字が運べるのは 5 ビットで、1 バイトは 8 ビットだからです。8 ÷ 5 = 1.6 なので、結果は必ず元の 1.6 倍（＋パディング）になります。Base64 は 8 ÷ 6 ≈ 1.33 倍です。これは実装の問題ではなく、「文字種が少ないほど長くなる」という避けられない代償です。

base32hex と標準 Base32 のどちらを使うべきですか？

ほとんどの場合は標準 Base32 です —— 既定であり、他の実装も特に指定がなければこちらを想定しています。base32hex の価値は「並べ替え」にあります。アルファベットが 0–9、A–V の順なので、符号化された文字列を辞書順に比べた結果が、元のバイト列を比較した順序と完全に一致します。符号化結果をデータベースの主キーにする場合や、DNS で順序付きの二分探索（NSEC3）を行う場合に必要です。両者は互換性がなく、同じデータでもまったく別の文字列になります。

デコードで「アルファベットに含まれません」と出ます

多くの場合、アルファベットの取り違えです。標準 Base32 には 0・1・8・9 がないため、0 を含む文字列は標準の表では必ず失敗します —— base32hex に切り替えればデコードできます。逆に W・X・Y・Z を含む文字列は標準 Base32 しかありえません（hex の表は V で終わります）。もう一つは途中で切れている場合で、末尾の半端なグループが別の文字として見えているケースです。

「有効な UTF-8 テキストではありません」と出るのはなぜですか？

その Base32 が文字ではなくバイナリを運んでいるためです —— 画像・鍵・アーカイブはすべてそうなります。Base32 自体はバイト列を運ぶだけで、中身が何かは関知しません。本ツールの出力はテキスト欄なのでバイナリは表示できません。置換文字の羅列に置き換えて「デコードできた」と誤解させるより、明確にエラーを出すほうが親切だと考えています。