铭文的 metadata 字段：CBOR、520 字节上限与必须全部展示给用户的约定

链上藏品常被说成”元数据也在链上”，但铭文里不同的信息其实走不同的字段：属性写在 properties，另一类附加说明写在 tag 5 的 metadata。这两个字段各有编码规则，混用是最常见的铸错来源之一。

必须是 CBOR，不是随手一段 JSON

手册的说法是：铭文可以包含 CBOR 元数据，存放在 tag 5 的字段中作为数据推送。它同时提醒，文档里的示例为了可读性用 JSON 表示 CBOR，但这只适用于示例，写成 JSON 的元数据并不会被正确显示。也就是说，把 {"foo":"bar"} 原样塞进 tag 5，索引器读到的是字节串，不是你以为的键值对。

520 字节与拆包再拼接

taproot 有少数几条硬限制之一，是单个数据推送不能超过 520 字节。手册据此给出规则：超过 520 字节的元数据必须拆成多个 tag 5 字段，解码前再拼接。文档的例子把一段长内容写成两条推送，先推开头，再推剩余部分，最终按顺序拼回一段完整 CBOR。这里有两个容易踩的点：拆分必须在字节边界上做，拼接后仍然是合法编码；以及在字段区与正文之间，还需要那个空数据推送作为分隔。

全部都会显示给用户

手册对 metadata 的定位很明确：元数据是人类可读的，所有元数据都会连同铭文一起展示给用户，因此铸造者被建议考虑展示效果，把元数据写得简洁。换句话说，这个字段不是内部便签。任何你希望”只有链上分析的人才会看到”的内容放在这里，都会直接出现在浏览页面中。

渲染规则决定你能看到什么

按手册列出的对应关系：null、true、false、数字、浮点数和字符串渲染为纯文本；字节串渲染成大写十六进制；数组渲染成 ul 列表标签，每个元素再套一层 li；映射渲染成 dl，键套 dt、值套 dd；标签（tag）则渲染成上标 sup 加值。手册也承认 CBOR 规范复杂，标签、浮点数、大数这类少见类型以及不定长编码形式可能显示不正确甚至完全不显示。

可读性自查
- 类型：只打算放字符串、整数、布尔？
- 体积：CBOR 编码后是否超过 520 字节？超过就要多字段拆分
- 展示：所有内容都愿意公开出现在页面上？
- 分工：属性类信息是否应该走 properties 而不是 metadata？

买家视角的两条提醒

第一，看到元数据里出现大片十六进制，通常不代表数据损坏，而是字节串按规则被这样渲染。第二，页面上少显示某一段，也不代表链上没有——手册已经说明部分 CBOR 类型可能显示不出来，需要自行解码原始推送再核对。至于内容是否值得付溢价、价格如何走，都不是这些编码规则能回答的问题。

关于拆分还有两条边界值得写进操作手册。第一，拼接发生在解码之前，所以顺序不能颠倒：拆出来的多个 tag 5 字段会先被按出现顺序连成一段完整字节流，再交给 CBOR 解码器。如果拆分正好切在某个数据结构的中间，颠倒顺序后得到的就是坏编码。第二，每一段本身必须是一条合法的数据推送，不能为了压体积而把两条推送并成一条超过上限的推送。手册把 520 字节写成 taproot 少数几条硬限制之一，这类限制不会因为工具方便而放宽。

如果你是在浏览器里读别人的铭文，还有一条判断方法：看到大片大写十六进制时，先怀疑那是被渲染成十六进制的字节串；看到某个键完全没出现在页面上时，先怀疑那是文档已经点明的少见类型（标签、浮点数、大数、不定长编码）显示失败，而不是链上缺数据。两种情况下，正确的下一步都是把原始推送取回本地，用 CBOR 解码器自己读一遍，而不是让发行方“帮忙解释”。至于这类编码差异是否该折算进价格，属于判断问题，规则本身给不出答案。

把两条容易混的信息放在一起对照会更清楚：属性类内容走 properties 字段，其编码与压缩规则是另一套约定；而 tag 5 只承担这份文档所述的 CBOR 元数据，并且按规则被完整展示在铭文页面里。前者偏作品属性，后者偏附加说明，铸错字段的结果往往不是报错，而是页面上出现一个不该出现的位置。检查方法也很简单：把原始交易的字段序列导出来，逐条看标签号与推送内容，再确认字段区与正文之间那个空推送是否存在，就能判断哪一段被放错了地方。

本文为机制说明，不构成任何投资建议。