很多铭文的市场页面下方有一小块“附加信息”：作者备注、铸造说明、版本号——这些文字就住在铭文信封里一个叫 Metadata 的字段中。Ordinal 理论手册为它写了专门一页，规则短但密度高：编码格式、体积限制、渲染方式各有一条硬规定。本文按手册原文逐条拆解，顺便回答“为什么有的 metadata 显示成一串十六进制”。
先讲存放。手册的定义是：铭文可以携带 CBOR 格式的元数据，存放在 tag 5 字段中，以数据推送（data push）的形式逐段排进信封结构。CBOR 是二进制压缩版“键值对语言”，能表达映射、数组、数字、字节串等类型。比特币脚本对单段数据推送有长度约束，手册据此写明：超过 520 字节的元数据必须拆进多个 tag 5 字段，解码端再按顺序拼接后整体解读。也就是说，一条长备注在链上可能是好几段碎片，任何只取第一段就下结论的工具都会读错。
渲染规则是这一页最有实用价值的部分。手册规定元数据对人类可读，应当连同铭文一起展示，并给出到 HTML 的映射：空值、布尔、数字、浮点与字符串直接按纯文本渲染；字节串渲染成大写十六进制——这正是“怎么显示成乱码”的官方答案，不是坏了，而是原始数据本来就是字节串；数组渲染成列表标签、每个元素各占一项；映射渲染成定义列表，键与值配对；标签（tag）则把标签号以角标形式放在值前。手册还特别提醒：CBOR 规范复杂，同一种数据可有多种编码路径，exotic 类型（标签、浮点、大数）与不定长编码可能显示不完整甚至无法显示，欢迎向 ord 提补丁。
对铸造者，这页文档的隐含守则有三条。第一，元数据会全部公开给用户看，写进去之前按“会被截图传播”的标准自查——手册原话就是鼓励铸造者考虑展示效果，把内容写得简洁。第二，想让人读得懂，就用字符串与映射这类基础类型；把文本伪装成字节串塞进去，得到的大概率是一屏十六进制。第三，长内容先估算分片：520 字节上限意味着几百字的备注会拆成多段，务必用能正确拼接的解码链验证一遍，别让索引器替你猜。
对阅读者，核对一条铭文的元数据有两条路径：市场页面的渲染层可能因实现差异漏显示 exotic 类型，稳妥做法是用解码工具直接从交易里抽出全部 tag 5 数据推送、拼接后按 CBOR 解读一遍；对显示成十六进制的字段，先把它还原成字节再看语义，很多“神秘代码”只是没被渲染的普通字符串。
一句话定位：Metadata 字段是铭文自带的公开附言栏——编码用 CBOR、体积有分片上限、显示按手册的渲染表。理解这三层，你在页面上看到的每一行附言，都能追回它在链上的原始字节。
把视角切到索引与工具生态，metadata 字段还牵出一个现实问题：谁来遵守渲染规范。手册给出的 HTML 映射约束的是 ord 的行为，第三方市场与钱包大多“参照实现”，于是同一枚铭文的 metadata 在不同界面可能有不同长相——一边列了整齐的键值表，另一边只给一坨原始串。遇到差异时，以 ord 官方实现的渲染为参照基准最稳妥，因为规范文本就是按它写的。另外值得留意 tag 5 与 Properties 字段的关系：两者都落在信封里、都用 CBOR，但语义分工不同，metadata 是自由附言，Properties 承载结构化属性，混淆两者会导致钱包解析时把备注当属性、或把属性藏进备注——写铸造脚本时按手册的字段定义各归各位，比事后指望解析器纠错省力得多。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。