TON 地址转换与校验器

写同一个地址的三种方式

从底层看，每个 TON 地址都是两个数字：一个工作链（basechain 为 0，masterchain 为 -1）和合约初始状态的 256 位哈希。raw 形式写的正是这两个数字：0:83dfd552…0f31a8。它没有歧义，也是 get 方法和底层工具所期望的格式，但它没有校验和：改错一个字符，就是另一个看起来完全合法的地址。

user-friendly 形式把同样的两个数字打包成 36 字节——一个标志字节、工作链、哈希和 2 字节的 CRC16 校验和——写成 48 个 base64 字符。有了校验和，打错字会直接校验失败，而不是把币发进虚空；而标志字节决定了字符串以 EQ、UQ、kQ 还是 0Q 开头：

同样的 36 字节可以用两套 base64 字符表书写：标准表（+ 和 /）和 URL 安全表（- 和 _）。钱包和区块浏览器使用 URL 安全表。工具两种都接受，也两种都输出。

bounceable 与否：这个标志做什么

EQ 和 UQ 不是两个地址。它们指向同一个合约和同一个余额；标志只是告诉发送方的钱包该在出站消息的 bounce 位里放什么。

bounceable 转账的意思是：如果目标无法处理这条消息——合约未部署、抛出异常、gas 耗尽——就把币扣除手续费后退回给我。这是向智能合约转账的正确默认值，所以区块浏览器和 DEX 界面显示 EQ 地址。

non-bounceable 转账即使目标账户没有任何代码来处理它，也会留在那里。这是钱包的正确形式，也是向新钱包首次充值时唯一正确的形式：新钱包合约由它自己的第一笔出站交易部署，在那之前地址上没有任何东西能接受 bounceable 消息，币会直接退回。地址格式文章用示例讲完了整个故事。

校验器检查什么

对于 user-friendly 地址：长度（48 个字符）、字符集、前 34 字节的 CRC16 校验和，以及标志字节。对于 raw 地址：工作链范围和恰好 64 个十六进制字符。每项检查都有自己的提示，所以被截断的粘贴和打错字看起来是不同的。

它无法检查的是链上状态：该地址的账户是否已部署、是否有余额、是否是你以为的那个合约。这些需要节点——通过 liteserver 调用 getAccountState——或者区块浏览器。

批量模式

切换到批量模式，每行粘贴一个地址，每一行都会被独立转换和校验。无效的行会原地保留并附上错误，所以一千个充值地址的列表可以一次粘贴完成检查，并按行号找出有问题的那些。一切都在你的浏览器中进行；列表从不会被上传。