base32/

Base32 は 5 バイトを 8 文字で表す方式で、文字表は 32 文字だけ（標準では A-Z と 2-7）です。そのため出力は元のデータより約 60% 長くなります（Base64 は約 3 分の 1 増）。その代わり、大文字と小文字を区別せず、数字の 0、1、8、9 も使わないので、文字の O、I、B と見間違えにくくなります。手書きで写す場合、口頭で伝える場合、2FA の鍵やファイル名のように大文字小文字を区別しない場面に向いています。

2FA の鍵や、ほとんどのライブラリの既定の出力など、ふだん目にする Base32 は標準バリアント（RFC 4648 第 6 節、文字表は A-Z と 2-7）です。Base32Hex（第 7 節、文字表は 0-9 と A-V）は、エンコード後の文字列の並び順が元のバイト列の並び順と一致するという特徴があり、DNSSEC の NSEC3 のように並べ替えが必要な場面で使われます。両者は互いにデコードできません。選び間違えると「Base32 の文字ではありません」というエラーになることが多く、文字化けした結果が出る場合もあります。

はい。TOTP のシークレット（QR コード内の otpauth:// リンクの secret パラメータ、または手入力する鍵）は通常は標準 Base32 で、多くは大文字で = なしですが、4 文字ごとにスペースで区切って表示されることもあります。このツールのデコードはそのすべてに対応しています。デコード結果は文字ではなくランダムなバイト列なので、「結果を hex で表示」にチェックを入れないと確認できません。たとえば JBSWY3DPEHPK3PXP は 48 65 6c 6c 6f 21 de ad be ef です。ワンタイムコードを生成したい場合は、このサイトの 2FA ツールを使ってください。

「長さが不正です」は、= を除いた文字数を 8 で割った余りが 1、3、6 になっているという意味です。正しい Base32 の余りは 0、2、4、5、7 のいずれかしかないので、コピー時に文字が欠けた可能性が高いです。「Base32 の文字ではありません」は何文字目かを示します。標準バリアントには 0、1、8、9 がなく、句読点や全角文字も使えません。内容に 0-9 と A-V が含まれているなら Base32Hex かもしれないので、バリアントを切り替えてみてください。「= は末尾にしか置けません」は、= の後ろに内容が続いているという意味で、複数の文字列がつながっている可能性があります。その場合は分けてデコードしてください。スペース、改行、小文字、省略された = はエラーになりません。

= は長さを 8 の倍数にそろえるための詰め物で、データの一部ではありません。デコードでは、あってもなくても処理できます。エンコード時は「= でパディングする」が既定でオンなので、不要ならチェックを外してください。省略してよいかどうかは受け取る側次第です。Google Authenticator の otpauth リンク形式では secret にパディングは不要とされていて、通常は省略されます。一方、Python の base64.b32decode はパディングが必須で、ないと Incorrect padding エラーになります。

デコードしたバイト列が UTF-8 のテキストではないという意味です。2FA の鍵、ハッシュ値、暗号化データは最初からバイナリです。「結果を hex で表示」にチェックを入れると元のバイト列を確認できます。このツールは UTF-8 のテキストだけを表示します。元のテキストが GBK など別の文字コードだった場合は、先に hex 表示にしてから、このサイトのテキスト / 16 進数ツールで GBK を選び、バイト列をテキストに戻してください。

次の 3 点を確認してください。1 つ目は、入力の末尾に余分な改行やスペースがないかどうかです。このツールは入力を UTF-8 のままエンコードし、前後の空白を削りません。2 つ目は、バリアントが同じかどうかです。Python では標準形式が base64.b32encode、Base32Hex が base64.b32hexencode（3.10 以降）です。3 つ目は、= のパディングの有無です。Crockford や z-base-32 のように別の文字表を使うバリアントには対応しておらず、結果は一致しません。

いいえ。エンコードもデコードもブラウザ内で完結し、通信は行わず、保存もしません。2FA の鍵がブラウザの外に出ることはありません。