Base58 编码解码

普通文本会先按 UTF-8 转成字节，再编码为 Base58 或 Base58Check。

0 输入字符

在浏览器里完成 Base58 与 Base58Check 编码解码，支持文本、文件、自定义字符表和十六进制结果查看。

相关推荐

十六进制编码解码

Base32 编码解码

Base64 编码

URL Safe Base64

Base85 编码解码

文件哈希校验

什么是 Base58 与 Base58Check？

Base58 是一种面向人类阅读和复制粘贴的文本编码。它会去掉 0、O、I、l 这类容易看错的字符，因此常被用在短标识、邀请码、钱包地址、离线分享码等场景。

标准 Bitcoin Base58 字符表为 `123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz`。本页同时支持 Flickr 版字母表，以及你自己定义的 58 字符字符表。

Base58Check 是在原始字节后追加 4 字节校验和，再整体做 Base58 编码的方案。它常用于比特币旧地址、WIF 私钥导出、邀请码或需要人工抄写的字符串，目标是更早发现输错、漏字或顺序错乱。

如果你拿到的是二进制负载、地址载荷或哈希片段，解码后的内容不一定是可读文本。这时更适合切到十六进制查看，而不是把乱码误判为解码失败。

IPFS CIDv0 使用的是标准 Base58btc，而不是 Base58Check；`bc1...` 这类比特币地址属于 Bech32，也不在本页 Base58 范围内。

适用场景

  • 校验旧版比特币地址、WIF 私钥导出串或自定义 Base58Check 分享码是否被输错。
  • 把小文件、二进制片段或测试载荷编码成 Base58，方便在日志、聊天或工单里传递。
  • 把 Base58 字符串先解码成十六进制，继续分析其中的版本字节、哈希或原始负载。
  • 在 Bitcoin Base58 与 Flickr Base58 之间比对输出，排查同一套字节为什么在不同系统里结果不同。
  • 为内部邀请码、短标识或离线 token 设计自己的 58 字符字符表，并验证双端是否一致。

使用方法

  1. 选择编码或解码模式；如需处理人工输入容易出错的字符串，再打开 Base58Check 选项。
  2. 选择 Bitcoin、Flickr 或自定义字符表；如果是私有协议，先确保双方用的是同一套 58 字符顺序。
  3. 编码时输入文本或上传文件；解码时粘贴 Base58 字符串，必要时切换到十六进制结果查看原始字节。
  4. 查看输出后直接复制或下载；若是 Base58Check，页面会同步提示校验是否通过。

功能特点

  • 标准 Base58 与 Base58Check 双模式：可直接做普通编码，也可自动追加或校验 4 字节校验和。
  • 文本与文件都能编码：普通文本会按 UTF-8 处理，文件则会按原始字节编码，适合离线传递二进制内容。
  • 解码结果可切换文本或十六进制：遇到地址载荷、哈希片段或非 UTF-8 数据时，不会被乱码卡住。
  • 支持 Bitcoin、Flickr 和自定义 58 字符字符表：适合兼容已有系统，或调试私有短码方案。
  • 浏览器本地处理与结果下载：编码、解码、校验都在本机完成，输出可直接复制或下载。

Base58、Base58Check、Base64 该怎么选？

它们都能把字节转成可传递的文本，但侧重点完全不同。关键不是“哪个更高级”，而是你是更重视人工抄写、防输错，还是更重视紧凑和通用兼容。

方案更适合优势注意点
标准 Base58短标识、手动输入、复制分享去掉易混淆字符，肉眼更好辨认，适合邀请码、离线码、CIDv0 这类字符串。没有内建校验和；如果需要自动验错，应改用 Base58Check。
Base58Check地址、导出串、人工抄写后的再次校验在 Base58 上再加 4 字节校验和，更容易发现漏字、错字和顺序错误。输出会比标准 Base58 略长；它只负责验错，不负责解析地址类型或网络。
Base64 / Base64URL接口传输、前后端交换、需要更短输出时同样的数据通常比 Base58 更短，生态更通用，适合程序之间直接传输。字符里可能包含 +、/、=；如果要放进 URL，应改用 URL-safe 变体。Base64 编码Base64 URL Safe
Base32不区分大小写、口头传递或某些兼容场景字符集更保守，一些系统里输入容错更高。输出通常比 Base58 更长；如果主要诉求是更短、更适合短码，Base58 往往更合适。Base32 编码

最佳实践

人工抄写或客服转述时优先开 Base58Check

只要字符串会经过口述、截图、聊天转发或人工重输，校验和几乎总是值得开。它不会阻止所有错误，但能明显减少“看起来像对，其实少了一个字符”的情况。

解码出来不是文本时先看十六进制

地址载荷、哈希、图片头、压缩片段这类内容本来就不保证是 UTF-8。先切到十六进制确认原始字节，再决定后续是转文件、继续哈希还是交给别的工具处理。

十六进制工具

大文件不要把 Base58 当长期存储格式

Base58 更适合短字符串和中小载荷。文件越大，输出越长、复制越不方便，也更容易在富文本、聊天工具或日志中被截断。

自定义字符表时一定同步到所有生产端

只要有一个服务端、脚本或客户端用了不同顺序，编码和解码结果就会全部错位。先固定 58 字符顺序，再把它写进协议或测试样例里。

需要更短、更通用的接口传输时优先比较 Base64URL

Base58 的优势是易读和防混淆，不是体积最省。如果字符串主要在程序间传递，且不会人工抄写，Base64URL 通常更紧凑也更常见。

Base64 URL Safe

常见问题

Base58 和 Base64 应该选哪个？

如果字符串要给人看、给人抄、给人输，优先 Base58；如果主要是在程序、接口、JSON 或 URL 参数里传输，通常 Base64 或 Base64URL 更紧凑。Base58 的重点是可读性和防混淆，不是最短输出。

Base58Check 到底解决什么问题？

它会在原始负载后追加 4 字节校验和，再整体做 Base58 编码。这样当用户漏字、错字或顺序写错时，工具更容易及时报错，而不是静悄悄地得到一串无意义结果。

这个页面能校验比特币地址吗？

可以校验 Base58Check 这一层是否正确，因此适合检查旧版 Base58 地址或 WIF 导出串有没有明显输入错误。但它不会进一步判断地址用途、网络类型、脚本类型，也不支持 `bc1...` 这类 Bech32 地址。

为什么解码后是乱码，或者提示不是 UTF-8？

因为 Base58 解出来的是原始字节，不一定是可读文本。地址载荷、哈希、图片头或任意二进制数据都可能出现这种情况。切到十六进制查看原始字节，通常就能继续分析。

支持文件 Base58 编码和解码吗？

支持。编码时可以上传文件，页面会按原始字节转成 Base58；解码后也可以把原始结果下载回来。文件越大，输出字符串越长，因此更适合中小型负载或调试场景。

支持哪些字符表？

当前支持标准 Bitcoin Base58、Flickr Base58，以及你自定义的 58 字符字符表。只要编码端和解码端使用完全相同的字符顺序，就可以互通。

能处理 IPFS CID 或别的链上字符串吗？

CIDv0 这类标准 Base58btc 字符串可以直接编码或解码；但页面不会继续解析 multibase、multicodec 或具体链上语义。像 `bc1...` 这种 Bech32 字符串，也不属于 Base58 范围。

上传的内容会发到服务器吗？

不会。文本、文件、Base58Check 校验和结果都在浏览器本地处理，适合调试敏感负载、离线测试数据或不方便上传的文件片段。

故障排查

提示包含非法 Base58 字符

当前字符表不接受 0、O、I、l 这类被排除字符，也可能是你切错了 Bitcoin / Flickr / 自定义字符表。先确认字符串来源，再检查字符表是否和对方一致。

Base58Check 校验失败

通常说明字符串被少复制了、字符写错了，或者它本身就不是 Base58Check。先确认是否真的需要打开 Base58Check，再回头检查原始内容是否完整。

自定义字符表无法保存

自定义字符表必须正好 58 个字符，而且每个字符都只能出现一次。建议先从标准 Bitcoin 字符表开始修改，避免少字符或重复字符。

解码结果不是文本

这不一定是错误。很多 Base58 字符串本来承载的就是二进制负载。切到十六进制查看，或把解码结果下载为文件，再决定下一步处理方式。

术语表

Base58
去掉 0、O、I、l 等易混淆字符的 58 进制文本编码，适合人工输入和复制分享。
Base58Check
在原始负载后追加 4 字节校验和，再整体做 Base58 编码的方案，用来更早发现输错。
Payload
做 Base58 或 Base58Check 编码前的原始字节内容，可以是文本、文件字节、地址载荷或任意二进制数据。
Checksum
用于快速验错的短指纹。Base58Check 会对负载做双 SHA-256，并取前 4 字节作为校验和。
Bitcoin Base58 字符表
最常见的 Base58 字符表：123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz。
Flickr Base58
Flickr 使用过的另一套 Base58 排序，大小写顺序与 Bitcoin 版不同，因此同样的字节会得到不同输出。

当前页支持的字符表

同样一组字节，只要字符表顺序不同，最终 Base58 输出就会不同。

字符表常见用途说明
Bitcoin Base58钱包地址、CIDv0、常见 Base58 工具默认字符表，兼容绝大多数 Base58 场景。
Flickr Base58旧 Flickr 短 ID 场景大小写顺序和 Bitcoin 版不同，不能混用。
自定义 58 字符表内部协议、短码系统、私有兼容层必须保证 58 个字符唯一且双端顺序一致。

什么时候该切到十六进制查看

Base58 解码的结果不是总能直接读成文本。

遇到的内容更适合的查看方式原因
地址载荷 / 版本字节十六进制更容易看出前缀、校验和和固定字节结构。
哈希片段 / 二进制测试数据十六进制这些内容本来就不是 UTF-8 文本。
普通短文本 / UTF-8 字符串UTF-8 文本可以直接看到原始内容，复制也更方便。
文件或压缩片段十六进制或下载结果更容易判断文件头、魔数或后续处理路径。

Authoritative References