有些地址格式会通过前缀、长度或校验和标出网络；另一些不会，EVM 地址尤其如此。这个工具识别格式族，核验格式允许核验的部分，并在无法从地址还原目标网络时明确说明。
或者试试这几个
这一页实际上做了什么
这里值得说准确，因为一个夸大自己核过什么的工具，比没有工具更糟。
- 比特币，传统格式。解码 base58，通过对载荷做两次 SHA-256 来校验那四个字节的校验和，并读取版本字节以区分公钥哈希与脚本哈希。
- 比特币，原生隔离见证与 Taproot。解码 bech32 与 bech32m，校验 BCH 校验和，提取见证版本与程序长度，并检查编码是否与见证版本相符——因为版本 0 必须用 bech32，而更高的版本必须用 bech32m。
- EVM 地址。检查形状；当地址是大小写混排时，通过计算小写形式的 Keccak-256 来校验 EIP-55 校验和。一个混排却校验不过的地址会被标出来。
- 波场。解码 base58check，确认 0x41 版本字节与二十一字节的长度。
- Solana。确认这串字符能以 base58 解码成正好三十二字节。这个格式里没有校验和，所以没有更多可核的——而这一页会直说，不去暗示自己校验过什么。
- XRP。只识别形状。XRP Ledger 用的 base58 字母表与比特币的不同，而这一页没有实现它，所以它报告形状，并明确说明校验和没有被核过。
一切都在你的浏览器里运行。哈希函数是在这一页自己的 JavaScript 里实现的，不是调用某个服务，所以你粘贴的地址不会离开你的机器，而且断网也照样能用。
地址为什么长成那样
每一种地址格式都是对同样三个问题的回答，而答案各不相同。
怎么让一个错字不至于变成一笔损失？
比特币最初的答案是 base58check：把载荷哈希两次，取四个字节，粘在末尾。改掉任何一个字符，重新算出的哈希就对不上。四个字节强到足以让随机错误基本不可能蒙混过关。
bech32 的答案更好：一个 BCH 纠错码，它被选成能保证检出最多四个字符的错误，而更多的错误也以压倒性的概率被检出。它同时还被设计成对人们朗读字符或手抄时具体会犯的那些错误足够健壮。
以太坊最初的答案是：完全没有。这个格式定义时不带校验和，这就是为什么 EIP-55 不得不用大小写来事后补上一个——那是当时唯一不会弄坏既有软件的通道。Solana 的答案也是没有，而且和以太坊不同，它没有事后补丁。
怎么让字符不至于被互相认错？
base58 就是把含混字符拿掉的 base64：没有数字零、没有大写 O、没有大写 I、没有小写 l。这个决定来自一个人们会把地址念出来、写在纸上的世界。
bech32 走得更远，它用一套 32 个字符的字母表，选法是让人们真正会搞混的那些成对字符不会同时出现在里面。按惯例它还全部小写，这意味着地址可以为了二维码而写成大写，因为大写在二维码里占的比特更少。
怎么说明这是哪条网络？
base58check 用一个版本字节，这就是为什么比特币地址以 1 或 3 开头、而波场地址以 T 开头。bech32 用一个显式的人可读前缀——比特币主网是 bc，每条链自己挑一个。
EVM 格式什么都没说。它没有网络标记，所以同样那四十个十六进制字符在以太坊上、在每一条 EVM Layer 2 上、以及在一长串其他链上都是有效地址。这很方便，同时也是一种常见的转账错误来源：地址到处都有效，所以没有任何东西会警告你选错了网络。Solana 有同样的缺口，但理由不同——它的地址就是一把公钥，外面什么都没包。
格式告诉不了你的事
一个有效的地址不等于一个安全的地址。校验和确认的是这串字符没被打错。它没说这个地址是不是属于你以为的那个人，没说这个账户存不存在，也没说收款方是不是真的能收到你正要发的东西。
有三处具体的缺口值得点名：
- 对方指的是哪条网络。对 EVM 地址来说，这根本无法从地址本身还原。那是发送方在提币页面上做的一个决定。
- 需不需要 memo 或 tag。有些网络会给地址配一个第二字段，而交易所常常用一个地址接很多客户。光看地址是看不出来的。
- 它到底是不是一个钱包。在 Solana 上，钱包、代币铸造帐户和程序用的是同一套编码。在 EVM 链上，合约和外部帐户看起来一模一样。
如果你正在网络之间搬资产，想知道更完整的「哪里会出错」，讲 Layer 1 与 Layer 2 的那篇指南里有那份实操清单。
格式细节于 2026 年 8 月对照 bech32 与 bech32m 的 BIP-173 与 BIP-350、以太坊校验和的 EIP-55，以及波场自己的帐户文档核过。这一页里的 SHA-256 与 Keccak-256 实现在发布前对照公开测试向量做过测试；测试与站点源码放在一起，不属于对外提供的内容。