Base32 / Base58 编码器

1. 怎么用

1. 把文本粘进输入区（编码）或粘贴编码串（解码）。
2. 选 Base32 或 Base58，再选字母表变体：RFC 4648 / Crockford，或裸 Base58 / Base58Check。
3. 点编码或解码；非法字符会标出位置，Base58Check 校验失败会明确报错。编码成功后下方显示与 Base64 的长度对照。

2. 字母表变体与校验

• TOTP / Google Authenticator 用 RFC 4648 Base32（A–Z 与 2–7）；本工具编码会按 RFC 补 =，解码忽略空格与大小写。
• Crockford Base32 剔除 I/L/O/U，解码时 O→0、I/L→1，适合电话口述；与 TOTP 字母表不要混用。
• 裸 Base58 没有校验和。Base58Check 在载荷前加版本字节、后加双重 SHA-256 前 4 字节，再 Base58——改错一位即失败。
• 编码后的体积对照用同一 UTF-8 输入比较 Base32 / Base58 / Base64；大流量传输仍应优先 Base64 工具。

3. 典型场景与安全边界

• Authenticator 密钥、部分 DNS 标签 → Base32（RFC）。
• ULID / 口述核对码 → Base32（Crockford）。
• 演示或核对加密货币风格地址串 → Base58Check；只要去混淆字母表、不要校验 → 裸 Base58。
• 编码不是加密：结果可原样还原。真实密钥放环境变量或密钥管理服务，本工具只做展示与交换场景的编解码。

4. 常见错误提示怎么读

Invalid Base32 character … at position N：当前位置字符不在所选字母表（RFC 不含 0/1/8/9；Crockford 另有别名规则）。Invalid Base58 … excludes 0, O, I, l：串里出现了 Bitcoin 字母表禁止的字符，有时其实是 Base32。Base58Check checksum mismatch：串被改过，或本来就是裸 Base58——先确认变体再解。

5. 什么时候用 Base32 / Base58，什么时候仍用 Base64

Base64 密度更高（每字符约 6 bit），适合机器管道、HTTP 与 JSON；Base32 每字符 5 bit，字母表更适合人口述与避免 0/O 混淆（尤其 Crockford）；Base58 再去掉更多易混字符，并常配 Base58Check 做传输防呆。传输体积敏感、接收方是程序时，继续用 Base64；密钥要给人读、写进 Authenticator、或做区块链风格地址校验时，才切换到本页。编码成功后的长度对照面板，就是为了让你看见「可读性换体积」的具体代价。

6. 和 TOTP / 哈希工具的衔接

• TOTP 密钥：字母表选 RFC 4648，解码确认无非法字符后，再粘到 TOTP 生成器——不要用 Crockford 去解 Authenticator 密钥。
• Base58Check 依赖双重 SHA-256；校验失败先怀疑拷贝截断，而不是「哈希算法坏了」。
• 需要对照同一输入的 Base64 形态时，用本页对照或旁边的 Base64 工具，保持 UTF-8 输入一致。

7. Padding、大小写与口述场景的实操细节

RFC 4648 Base32 编码长度应为 8 的倍数，不足用 = 补齐；许多 Authenticator 展示时会去掉 padding 并插入空格分组——本工具解码阶段会忽略空白并容忍缺 =。Crockford 解码还有 O→0、I/L→1 的别名，电话里听错字形时反而能解通；但也正因为别名，它与 TOTP 字母表不能互换。Base58 无 padding 概念，长度随字节变化；Check 变体多出来的校验字节会让串更长一点——对照面板上的长度差，有助于判断你手里的到底是裸 Base58 还是 Check。复制密钥时优先「复制原文」而不是重新打字：人工抄写 Base32 的 8/B、S/5 混淆，是 TOTP「永远差一位」的常见来源。