Base32 エンコーダー デコーダー

通常のテキストはまず UTF-8 としてエンコードされ、その後 Base32 に変換されます。
0 入力文字

4 種類の Base32、ファイル変換、padding 制御、hex 出力、ローカルダウンロードで TOTP シークレットや読みやすい ID を扱えます。

関連おすすめ

Base32 とは?

Base32 は、バイト列を 32 個の印字可能文字で表す binary-to-text エンコードです。標準形式は RFC 4648 に由来し、A-Z と 2-7 を使います。5 bit ごとに 1 文字へ変換するため、結果は元のバイト列より約 60% 長くなります。

Base32 は最も短い形式ではありませんが、特殊文字を減らしたい場合、大文字小文字を区別しない環境、人が読んだり入力したりする文字列に向いています。TOTP シークレット、DNS や設定値、アクティベーションコード、読みやすい ID でよく使われます。

このページは RFC 4648 Base32、Base32hex、Crockford Base32、z-base-32 に対応し、厳密検証、padding 制御、行折り返し、テキスト/ファイル変換、hex 表示を提供します。

ユースケース

  • TOTP/OTP シークレットが標準 Base32 か確認し、必要に応じて Crockford や z-base-32 など読みやすい形式へ変換します。
  • バイナリ設定、証明書の断片、オフライン有効化コード、リソース fingerprint を、特殊記号の少ない読みやすい文字列に変換します。
  • padding の欠落、誤った variant、長さの異常で失敗する第三者の Base32 値を調査します。
  • 正体不明の Base32 payload をまず UTF-8 または hex で確認し、必要ならバイナリファイルとしてダウンロードします。

使い方

  1. 最初に正しい variant を選びます: RFC 4648、Base32hex、Crockford、z-base-32。
  2. エンコード時はテキストまたはファイルを選び、padding、小文字化、改行幅を設定します。
  3. デコード時は Base32 文字列を貼り付け、必要なら厳密検証で長さと padding を確認します。
  4. payload の種類に応じて、結果をテキスト、hex、またはダウンロード可能なバイナリとして確認します。

特徴

  • 4 種類の Base32 を切り替え: RFC 4648、Base32hex、Crockford、z-base-32。
  • テキストとファイルに対応: UTF-8 テキストやローカルファイルを Base32 に変換できます。
  • デコード結果を UTF-8 テキスト、hex、またはダウンロード可能なバイナリとして確認できます。
  • padding、小文字出力、64/76/カスタム幅の行折り返しを制御できます。
  • 長さと padding をブラウザ内で厳密に検証し、データはアップロードされません。

Base32、Base64、Base58 のどれを使うべき?

いずれもバイナリデータを印字可能な文字列に変換しますが、互換性、文字の安全性、出力長で向き不向きが変わります。

形式向いている用途トレードオフ
Base32TOTP シークレット、読みやすい ID、大文字小文字を区別しない環境人が扱いやすい文字集合ですが、Base64 より出力が長くなります。
Base64一般的なテキスト/ファイル転送、Data URL、API payloadより短くできますが、+、/、= が含まれることがあり、URL やファイル名では URL-safe 変体が必要です。Base64 エンコードBase64 URL Safe
Base58手入力するアドレス、短い QR payload、ブロックチェーン風 ID0/O/I/l の混同を避けられますが、RFC 4648 系ではありません。Base58 エンコード/デコード

Best Practices

まず相手が求める variant を確認する

Base32 でよくある原因は計算ミスではなく、alphabet や variant の不一致です。Base32hex、Crockford、z-base-32 が指定されている場合、標準 Base32 の結果は見た目が正しくても受け付けられません。

テキストだと決めつける前に hex を見る

Base32 のデコード結果は必ずしも UTF-8 テキストではありません。hex 表示なら、証明書、画像ヘッダー、圧縮ファイル、ランダムキー、平文のどれかを素早く切り分けられます。

手入力させる値には Crockford または z-base-32 を優先する

厳密な RFC 4648 互換より入力ミスの削減が重要なら、これらの variant は O/0 や I/1 の視覚的な混同を減らせます。

すべてを Base32 に閉じ込めない

実務では次の工程が Base64、hex、元ファイルの処理になることがよくあります。作業の流れに合わせて形式を切り替える方が楽です。

Base64 エンコードHex 変換

よくある質問

Base32 と Base64 はどう選ぶべきですか?

短い一般的な形式が必要なら Base64、人が読んだり入力したりする TOTP シークレットなどには Base32 が向いています。

RFC 4648、Base32hex、Crockford、z-base-32 の違いは?

主な違いはアルファベットと許容ルールです。RFC 4648 は一般標準、Base32hex は数字優先、Crockford は手入力向け、z-base-32 は読みやすい小文字を重視します。

Tại sao một số chuỗi Base32 kết thúc bằng =?

RFC 4648 Base32 と Base32hex は padding として = を使うことがあります。Crockford と z-base-32 は通常省略します。

Decoded output looks wrong

Dữ liệu gốc có thể không phải UTF-8. Hãy xem hex hoặc tải tệp nhị phân.

File conversion supported?

はい。ファイルを Base32 に変換し、後でバイナリとして復元できます。

Data upload?

Không. Việc xử lý diễn ra cục bộ trong trình duyệt.

トラブルシューティング

第三者ツールの結果と一致しないのはなぜ?

まず variant を確認してください。標準 Base32、Base32hex、Crockford、z-base-32 は alphabet が異なるため、わずかな違いでも結果全体が変わります。

厳密モードで長さエラーになるのはなぜ?

padding が不足している、無効な文字が混ざっている、または別の variant で生成された値の可能性があります。いったん緩いモードで内容を確認し、元の文字列を修正してください。

デコード後のテキストが空白または文字化けするのはなぜ?

元データが UTF-8 テキストではなく、バイナリファイルやランダムバイトの可能性があります。hex 表示に切り替えるか、デコード後のバイナリをダウンロードしてください。

用語集

RFC 4648 Base32
最も一般的な標準 Base32。A-Z と 2-7 を使い、= padding を含むことがあります。
Base32hex
RFC 4648 の 16 進順バリアント。アルファベットは 0-9 と A-V です。
Crockford Base32
I、L、O、U を除き、デコード時に O/0 と I/1/L/1 を許容する人間向けのバリアント。
z-base-32
人の入力を意識したバリアントで、通常は小文字かつ padding なしです。
padding
標準 Base32 の長さを補うため末尾に付く = 文字。

4 つの Base32 variant 早見表

どの variant を選ぶべきか迷う場合は、alphabet と典型的な用途から確認します。

VariantAlphabet= をよく使うか典型的な用途
RFC 4648A-Z + 2-7通常使うTOTP、標準 Base32 互換
Base32hex0-9 + A-V通常使う数値順比較や特定プロトコルのフィールド
Crockford0-9 + A-Z (without I/L/O/U)通常使わない手入力、短いコード、入力ミスへの耐性
z-base-32ybndrfg8ejkmcpqxot1uwisza345h769通常使わない読みやすい小文字の短い文字列

標準 Base32 の長さと padding

RFC 4648 / Base32hex では、末尾の = の数は元のバイト長で決まります。

入力バイト数有効な Base32 文字数必要な = padding
126
244
353
471
580

Authoritative References