Hex字符串里藏着什么?这是我在写Solana账户浏览器时遇到的真问题。当时控制台打印出一串7436346a506...,我知道那是数据,但完全读不懂。48字节的二进制blob,实际包含代币供应量、小数位数、铸造权限——只是全被编码成了机器语言。
这篇写我试过的三种解码方案,各自优缺点,以及什么场景该用哪个。
![]()
核心问题
你能拿到账户,能fetch到数据字段,但它长这样:
[2, 0, 0, 0, 39, 241, 144, 177, 211, 175, 152, 184, 206, 113, 76, 68, ...]
怎么变成人类可读的信息?这就是解码要做的事。Solana生态里主要有三条路。
背景:Borsh二进制格式
SPL账户用Borsh做序列化——确定性强、跨语言、紧凑。一个代币铸造账户固定82字节:
• 0-3字节:铸造标识符
• 4-35字节:铸造权限(32字节公钥)
• 36-43字节:总供应量(u64,小端序)
• 44字节:小数位数(u8)
• 45-76字节:冻结权限(32字节公钥)
原始字节毫无意义。解码=按偏移量读字节+按类型解析+小端序转数字。
方法一:Codec库(推荐生产环境)
最干净的做法:用@solana-program/token自带的解码器。
npm install @solana-program/token
代码逻辑:getMintDecoder()拿到解码器,直接decode(accountInfo.data)。输出supply、decimals、mintAuthority、freezeAuthority四个字段,开箱即用。
优点:类型安全、官方审计过、复杂类型自动处理、不用算偏移量。
缺点:只支持SPL标准类型、多一个依赖、黑箱——你看不到二进制底层。
方法二:手动字节解析(适合学习)
用DataView自己读原始字节。
关键步骤:跳过0-3字节的标识符,4-36字节切片取铸造权限,36偏移量getBigUint64读供应量(记得true参数指定小端序),44偏移量getUint8读小数位。
优点:零依赖、完全透明、理解每个字节的含义。
缺点:容易出错、偏移量算错就全错、维护成本高、每个账户类型都要重写。
方法三:IDL+Anchor(合约开发首选)
如果用Anchor框架写合约,IDL文件自带schema。anchor.account.mint.fetch(address)直接返回结构化数据,字段名和类型都定义在IDL里。
优点:与合约开发流一体、自动同步接口变更、类型生成到前端。
缺点:仅限Anchor项目、需要IDL文件、对原生SPL账户反而麻烦。
怎么选
查标准代币信息 → 方法一,最快最稳。
调试自定义合约或学习原理 → 方法二,看得懂每个字节。
在Anchor生态里做全栈开发 → 方法三,工具链最顺。
我最后在生产代码里用了方法一,但方法二的手动解析帮我真正理解了Borsh的内存布局。有时候慢下来读一遍十六进制,比调一百次库函数更有价值。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.