北京
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.
