铭文的 URI 长什么样：ord: 模式与“取原件而非委托件”的规则

一句话理解

ord: 是一种给铭文内容“写地址”的方案：ord: 后面接一个铭文 ID，比如创世铭文写作：

ord:6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0

结构就是铭文 ID 本身：64 位十六进制的揭示交易 txid，加字母 i，再加这笔交易内第几个铭文的序号（从 0 起）。整串不区分大小写，文档建议以全小写呈现。它和你在钱包、浏览器里看到的“txid 加 i 索引”其实是同一个标识，只是加了协议前缀，方便放进 URI 语境——比如二维码、链接解析器或应用间跳转。

也要如实交代这份文档的定位：ord 项目把它标注为草稿，ord: 前缀也尚未在 IANA 注册。它是项目层面的约定格式，不是互联网标准组织认可的正式 scheme。

一条重要语义：永远取原件

铭文可以带委托（delegate）字段，让“展示时返回另一个铭文的内容”。ord 的 URI 文档为这种情况写了明确规则：ord: URI 指向的内容，永远是目标铭文的原始内容——内容、内容类型、编码、长度都按目标铭文本身算，即使它带委托也不切换。

换句话说，同一枚铭文有两种“取内容”的通道：按内容端点访问时可能走委托解析；按 ord: URI 访问时拿的是本体。写工具、做核验、拼二维码的人要知道这个分叉，否则会出现“同一个铭文在两个入口看到两种画面”的错觉，误判成资产被改。

语法细节怎么读

文档给出的正则说明了三件事：前缀 ord: 不区分大小写；txid 必须正好 64 位十六进制；i 后的序号允许 0 或以非零开头的数字，即任意非负整数。序号部分允许极大取值而格式不变，编号是否存在由链上索引决定，URI 语法本身不做存在性检查。

因为整串不区分大小写，编码成二维码时可以用更紧凑的字母数字模式；日常展示推荐小写，避免视觉混淆。

这东西能说明什么、不能说明什么

能说明的：你想引用哪枚铭文的链上原始内容，用一个纯文本就能跨工具传递，不依赖某个市场的网页链接。它是“铭文即比特币 UTXO 上内容”这一定位的自然延伸——寻址用比特币交易标识，不需要域名或服务器。

不能说明的：它不保证你当前访问得到内容。ord: 只是寻址格式，真正把字节流给出来的是某个运行 ord 服务的节点；节点下线、限速或分叉显示，都不影响 URI 的指向性，只影响可用性。委托与重刻带来的“画面会变”问题，它也不解决，只是把两种通道明确分开。

实用场景与核对清单

• 想把藏品引用写进作品说明、文章或签名资料时，优先写 ord: 加铭文 ID 而不是某个网站的网页地址，网站会迁移，交易 ID 不会。
• 做核验脚本时：解析出 txid 与序号，去区块浏览器确认揭示交易确实存在，再比对返回内容的哈希。
• 排查“两处显示不一致”：先确认两个入口是否一个走委托解析、一个走 ord: 原语义，再看内容哈希是否相同。

三个高频问题

问：ord: 和浏览器里的铭文链接有什么区别？ 浏览器链接是某个网站对某枚铭文的服务页面；ord: 描述的是铭文内容与资源之间的映射关系本身。文档写明它指向的是一个 HTTP 资源，其内容、内容类型、内容编码与内容长度都对应那枚铭文——所以它更像“规范的引用写法”，网页地址只是它的一种实现。

问：大写能行吗？ 语法规则是整串大小写不敏感，大写可用；文档同时建议日常展示用小写。大写的主要价值在二维码：大小写不敏感意味着可以用更紧凑的字母数字模式编码，图案更简洁。

问：序号写一个不存在的大数会怎样？ URI 语法照样合法，能否解析出内容取决于索引器里有没有这枚铭文。语法管形状，存在性归链上索引管——分开理解，很多“链接失效”的误判可以避免。

风险提示：本文为铭文协议机制科普，不构成任何投资建议。铭文状态与内容以比特币链上数据和 ord 参考实现的索引结果为准。