铭文信封里的两张标签：content_type 与 content_encoding 各管什么

一枚铭文在链上其实带着两张”标签”：content_type 告诉看它的人这是什么类型的内容，content_encoding 告诉看它的人这段内容有没有被压缩过。钱包里同一张图，有人显示正常、有人显示成一堆乱码或者干脆空白，很多情况下问题就出在这两张标签和文件实际格式对不对得上。

铭文信封的字段结构

按 ord 的铭文文档，铭文内容被封在一个”信封”结构里：在正文之前可以携带若干字段，每个字段由两个数据推送组成，一个是编号（tag），一个是值；字段区结束、正文开始，由一个空的数据推送来标记。字段表里目前有明确定义内容的包括 tag 1 的 content_type（正文的 MIME 类型）、tag 2 的 pointer、tag 9 的 content_encoding（正文的编码方式）、tag 66 的解绑字段等。对普通藏家来说，这两张标签的地位类似快递面单上的”物品类别”和”包装方式”：内容本体在包裹里，但别人拆开之前只能先按面单的说法来处理。

content_type：声明”我是什么”

content_type 字段登记的是正文的 MIME 类型，也就是 image/png、image/svg+xml、text/html、video/mp4 这一类标准标签。它决定了索引器和浏览器在展示这份内容时按什么方式解读字节流：同样是 PNG 编码的图片，如果声明成了错误的类型，展示端可能按错误方式解析，出现空白、乱码甚至整页异常。要强调的一点是，这个字段只是声明，不是检验——协议不会因为文件实际格式和声明不一致而拒绝铭文上链，声明错了，铭文照样存在，只是显示环节可能出问题。这就是为什么铭文圈有”刻完先自查显示”的习惯：刻上去之前无法保证声明正确，刻上去之后链上内容改不了。

content_encoding：声明”我压过没有”

tag 9 的 content_encoding 记录正文的编码方式，思路与网页传输里常用的内容压缩声明一致：如果正文在刻写前做了压缩，就用这个字段说明压缩方式，链上存储的是压缩后的字节。这样做的好处是刻进脚本的字节数变少、对应的刻写成本下降；代价是查看端需要认识这种编码并正确解开，遇到不处理的客户端，显示就可能异常。规范文档对这个字段本身的表述只有一句”正文的编码”，具体怎么解开由各家客户端决定，因此它比 content_type 更容易踩到”有的平台能看、有的平台不能看”的差异。

渲染端还有一套配套约定

ord 的渲染规范对展示端另有一组要求：铭文内容按正方形比例展示，非正方形的原图不裁切、居中缩放放进容器；ord 官方浏览器给预览图的上限是 576 像素乘 576 像素；缩小显示时用自动重采样，放大时除 AVIF 之外的图片一律用像素风格放大，AVIF 与 JPEG XL 放大时用自动重采样，而在 JPEG XL 被浏览器广泛支持之前，它并不被推荐作为刻写格式。把这几段连起来读会得到一个实用结论：显示效果是”标签声明、客户端能力、渲染约定”三者共同作用的结果，任何一环没对齐，看到的效果就和刻写者的预期不一样。

新手常见的三个误区

第一个误区是把”标签写对了”当成”内容没问题”。标签只是类型声明，与作品质量、出处真伪无关，诈骗内容也可以声明成规规矩矩的 image/png。第二个误区是刻完不验证就挂出去。正确的顺序是先看声明与实际文件是否一致，再在主流展示端实测一次显示，确认无误再谈流转。第三个误区是看到某个钱包不显示就断定铭文有问题。同一个铭文在不同客户端的表现差异，很可能只是那个客户端不认识 content_encoding 里声明的编码，换一个规范实现的展示端往往就正常了——这时出问题的是”看”的工具，不是链上的数据。

标签字段能说明的内容到此为止：它们管的是”这份字节应该被怎么读”，管不了”这份字节值不值”。把它理解为文件格式的元数据，而不是某种品质认证，基本就不会用错它。

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