加密货币地址校验工具

这个工具检查什么，又检查不了什么

「这个地址是否有效」这个问题背后其实藏着两个不同的问题。第一个是：这个字符串本身是否格式正确——长度对不对、字符集对不对、校验位是否完整。这个问题有确定的答案，本页会在你的浏览器本地完成检查，不会把地址发送到任何地方。第二个问题是：这个地址是否真实存在、是否持有余额、是否属于把它给你的那个人。任何离线检查工具都无法回答这个问题；任何声称能回答的工具，实际上是在查询区块链，而不是在检查字符串本身。

这个区别很关键，因为这两类失败的表现完全不同。格式错误的地址会被这里以及每一个钱包拦截，因此 TRON 地址的一次笔误只是个麻烦，不会造成损失。而一个格式正确、却属于错误对象的地址，对任何一个检查工具来说都是不可见的。

TRON：Base58Check，一路核对到校验位

一个 TRON 地址由 34 个字符组成，以 T 开头。这串字符背后是 25 个字节：1 个版本字节、20 个地址字节，以及 4 个字节的校验位。版本字节在主网上是 0x41，这也是为什么这 25 个字节经过 Base58 编码后，每个地址都以字母 T 开头。

校验位取自 SHA-256(SHA-256(payload)) 结果的前四个字节，其中 payload 是版本字节加上 20 个地址字节。本页会真正计算这个哈希——使用浏览器自带的 Web Crypto API，并将结果与地址中携带的那四个字节进行比对。哪怕只改动一个字符，都会产生不同的 payload、不同的哈希值，从而出现不匹配。这就是全部机制，也是为什么一个打错的 TRON 地址会被拒绝，而不是被无声无息地接受、石沉大海。

Base58 还刻意从字母表中去掉了四个字符：数字零、大写 O、大写 I 和小写 l。这四个字符正是人们在朗读或手抄地址时最容易混淆的一组，去掉它们意味着这类混淆不可能生成另一个同样有效的地址。如果检查结果提示某个字符不在字母表内，问题往往就出在这四个字符之一。

格式本身无法告诉你的一件事是：这个地址究竟是一个钱包，还是一个代币合约。在 TRON 上，两者使用完全相同的 T 开头形式。USDT 的合约地址 TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t，能通过本页的每一项检查，是一个完全有效的地址，但向它转账仍然是一个错误。TRC20 地址页面更详细地介绍了这一区别，以及对应的十六进制表示法。

Ethereum 与 BSC：同一种格式，两条链

一个 EVM 地址由 0x 加 40 个十六进制字符组成，一共 42 个字符。Ethereum、BNB Smart Chain、Polygon 和 Arbitrum 都使用这种格式，因为它们共享同一套执行层和同一套密钥推导方式。这带来一个值得明说的后果：单看字符串本身，根本无法把一个 ERC-20 地址和一个 BEP-20 地址区分开来。字符串是一样的。真正不同的是你把交易广播到哪条网络，以及每条链上分别存在哪些余额。

多数跨链损失正是由此产生。一个在 Ethereum 上完全有效的地址，在 BSC 上同样有效，因此钱包会毫无异议地把 BEP-20 代币发送到一个接收方只在 Ethereum 上监控的地址。资金并没有消失，只是停在了另一条链上，但要找回它们，需要私钥以及一个配置为该网络的钱包。ERC20 地址页面和BEP20 地址页面详细介绍了这方面的实际情况，包括 BEP-20 与更早的 BEP-2 格式有何不同——后者以 bnb1 开头，与本页涉及的任何格式都不能互换。

EIP-55：藏在大小写里的校验位

十六进制不区分大小写，因此 0xab… 和 0xAB… 指向的是同一个账户。EIP-55 把这份多余的表达空间利用了起来：对小写地址做 Keccak-256 哈希，用哈希结果的每一个十六进制位（nibble）来决定对应的十六进制字母该写大写还是小写。结果看起来就是一个普通的大小写混合地址，同时每个字母大约携带四比特的纠错检测能力。

因此，一个大小写混合的 EVM 地址是在做一种「声明」，而一个全小写或全大写的地址则没有做这种声明。对任何钱包和任何节点来说，两者都是合法输入。但只有大小写混合的那个能被校验。

本页会告诉你，你粘贴的地址属于这两种情况中的哪一种，仅此而已。要验证 EIP-55 校验位，需要一个 Keccak-256 实现，而浏览器的 Web Crypto API 并不提供 Keccak——它提供的是 SHA-256，也就是上面 TRON 检查所使用的算法。与其为一项关乎安全的检查自己手写一个哈希函数，这个工具选择如实告诉你它没有验证什么。如果你的地址来自某个钱包界面，它几乎肯定已经带有正确的校验位；如果它来自数据库或日志文件，那么在你自己的代码里跑一次完整的 EIP-55 验证是值得的，那里只需引入一个经过审计的库即可。

集成中地址从何而来

校验一个手动粘贴的地址，是最后一道防线。更早的一道防线，是从一开始就不需要手动粘贴地址。在支付或代付流程中，存款地址是按客户逐一生成并通过程序监控的，因此不会有人手动重新输入地址，格式问题也就无从出现。

TRON API 以及对应的 Ethereum、BSC 接口做的正是这件事：创建一个地址、为它注册一个 Webhook、在收到通知时确认入账。地址始终保持非托管，试用期为七天，无需信用卡，也无需 KYC。在此基础上开发之前，有两个运维细节值得了解：Webhook 没有自动重试机制，一次失败的投递需要通过 POST /<chain>/webhooks/notifications/failed 主动获取，而不是等待系统重新投递；此外，Solana 完全不支持 Webhook。

本站的其他计算器列在 工具总览页面。

常见问题

地址会离开我的浏览器吗？

不会。Base58 解码和 SHA-256 哈希运算都在本地进行，通过浏览器的 Web Crypto API 完成。整个过程不会向服务器发出任何请求，这也意味着即使断网，这个工具依然可以使用。

对于一个 TRON 地址，具体会校验哪些内容？

一共四项：字符串长度是否为 34 个字符，每个字符是否都属于 Base58 字符集，解码后是否为 25 字节且版本字节为 0x41，以及末尾四个字节是否与 SHA-256(SHA-256(payload)) 的前四个字节一致。校验和是实际计算出来的，而不是假定成立的。

能区分 ERC-20 地址和 BEP-20 地址吗？

不能，任何工具都做不到这一点。这两种标准使用完全相同的 0x 加 40 个十六进制字符的格式。任何声称能区分两者的工具，要么是在猜测，要么是在查询链上余额——而这是一个和地址有效性完全不同的问题。

为什么不校验 EIP-55 校验和？

校验它需要 Keccak-256，而浏览器内置的加密能力并不提供这个算法，本页面也没有为了这一项检查而自行内置哈希实现，让用户去依赖它。本页面会告诉你的是：这个地址是用大小写混合的形式书写（也就是带有 EIP-55 校验和），还是全部使用同一种大小写（也就是不带校验和）。

地址有效是否意味着资金一定能到账？

不是。有效性只是字符串本身的属性。这个地址是否被监控、是否属于你实际发送所在的链、是否真的属于预期的接收方，这些都是离线检查无法回答的独立问题。

为什么 Base58 会跳过某些字符？

0、大写 O、大写 I 和小写 l 被排除在外，是因为它们非常容易被彼此混淆。去掉这些字符，就能避免一次模糊的读取或抄写在不被察觉的情况下生成另一个同样有效的地址。

TRON 地址的十六进制形式是什么？

就是同样的 21 个字节以十六进制书写：41 后面跟着 40 个十六进制字符。TVM 在内部使用的就是这种形式，而钱包展示给用户的是 Base58Check 形式。十六进制形式不带校验和，所以没有什么可以验证的。

合约地址是有效地址吗？

是的，从格式检查的角度看完全有效。无论在 TRON 还是在 EVM 链上，合约地址和钱包地址在形式上都无法区分。向一个代币合约地址发送充值会通过校验，但资金依然会丢失，这正是为什么地址校验只是格式检查，而不是安全检查。