地址格式校验器

粘贴一个地址,看它属于哪条链、格式对不对。它拦不住"地址是真的但不是你要转的那个人",但能拦下粘贴出错、链搞混这两类最常见的事故。

把地址粘进来内容不会离开你的浏览器

判定

—

粘贴一个地址开始。

格式对,不等于转过去就没事这个工具能确认的是这串字符符合某条链的地址规范。它无法确认:这个地址是否真的存在、是否属于你要转账的那个人、对方平台是否支持这条链、以及是否需要额外填写 Memo。这几件事只能靠你自己去核对。第一次往一个新地址转账,永远先转一笔很小的金额。

它到底验了什么、没验什么(展开)

它解决什么问题

转账事故里最常见的两类,一是粘贴出错(少了几位、剪贴板被恶意软件替换),二是链搞混(拿着一个以太坊系地址去走波场链)。这两类都能靠格式和校验位当场发现,而且发现的成本是零。

不同地址类型,验的深度不一样

这一点必须说清楚,因为"验过了"这三个字的含金量在不同链上差很多:

波场(T 开头)——做完整的 Base58Check 验算:把地址解码成字节,检查版本字节,然后对前 21 字节做两次 SHA-256,比对末尾 4 个字节的校验位。少一位、错一位都会被发现。
比特币(1 或 3 开头)——同样做完整的 Base58Check 验算,方法和上面一致,只是版本字节不同。
以太坊系(0x 开头,含 ERC20 / BEP20)——只做格式判断:0x 前缀 + 40 位十六进制字符。这类地址的校验位标准(EIP-55)需要 Keccak-256,而浏览器内置的加密接口不提供它,本站也不打算为此引入外部库。所以这一类只能告诉你"长得对",不能告诉你"没打错"。
bech32 / bech32m(bc1 开头,含 Taproot 的 bc1p)——做完整的校验和验算:按 BIP 173 / BIP 350 算 polymod,再检查见证版本和程序长度是否匹配(版本 0 必须配 bech32 校验和且程序为 20 或 32 字节,版本 1 以上必须配 bech32m)。大小写混合的地址一律判为无效,这是规范的硬性要求,不是风格问题。

之所以把这件事写这么细,是因为"我验过了"和"我做了格式检查"是两回事,而工具如果含糊其辞,反而会让你放松警惕。这也是为什么以太坊系那一栏我们宁愿写"没验",也不把"长得对"包装成"验过了"。

bech32 这一栏原先是"只做格式判断"

早先这个工具对 bc1 开头的地址只看前缀、字符集和长度,校验和没算。这有一个具体的坏后果:BIP 173 把大小写混合的 bech32 串明确列为无效并给了测试向量,而只看字符集的做法会把它判成"格式正确"——一个规范说要拒绝的串,被工具说成没问题,这比不检查更糟。

现在这一栏改成了完整实现,并且拿 BIP 350 附带的那套官方测试向量逐条跑过:8 个合法地址解出的 scriptPubKey 与规范给的十六进制一致,15 个非法地址全部被拒,包括大小写混合、校验和类型用错(v0 配了 bech32m、v1 配了 bech32)、见证版本 17、程序长度 1 字节和 41 字节、以及 8 转 5 位填充不为零这几类。我们选择自己实现而不是引外部库,理由和这个站不引任何第三方脚本是同一条:算法本身两百行以内,不值得为它给页面加一个外部依赖。

关于 ERC20 和 BEP20 为什么分不开

因为它们的地址格式完全相同——都是以太坊系的 20 字节地址。光看地址无法判断对方要的是哪条链,必须问对方或者看对方的充值页面。这也是"同一个地址,链选错了还可能有救"的原因:两条链上的这个地址,通常由同一把私钥控制。

为什么要看首尾几位

有一类恶意软件会监视剪贴板,在你复制地址之后把它替换成攻击者的地址。你粘贴出来的东西看起来正常(格式完全合法,因为那也是一个真地址),所以格式校验发现不了。唯一的防法是粘贴之后和来源核对首尾各几位。本工具会把首尾片段单独列出来方便你比对。

数据来源说明

这个页面不连接任何区块链节点、不查询任何接口、不上传你输入的内容。Base58 解码、bech32 校验和、SHA-256 都在你的浏览器里完成。其中 SHA-256 用的是浏览器内置的 Web Crypto 接口;如果你的浏览器环境不提供它(例如直接用 file:// 打开本地文件),Base58Check 那一类会明确告诉你校验位没验,而不是假装验过了。bech32 的校验和不依赖任何加密接口,任何环境下都会真正算。