在浏览器地址栏、二维码、签名信息里，我们习惯用一串 URL 指向一个东西；铭文也需要类似的通用写法：不依赖某个网站的域名，而是直接指向链上那一条记录。ord 官方手册的 URIs 一节给出了答案——ord: 模式，但要特别提醒：文档自己标注这是草案，“应视为临时性、随时可能改变”，而且 ord: 尚未在 IANA 注册。它解决的是书写规范问题，不是又一条链上共识规则。
格式本身很短。铭文 URI 由 ord: 加铭文 ID 组成，例如创世铭文写作 ord: 后接 64 位十六进制交易哈希、字母 i、十进制序号。值得注意的细节是 ord: 后面没有双斜线：URI 规范里 // 引导的是带层级结构的”权威部分”（比如域名路径），而铭文 URI 在协议专有段里只有一个不带层级结构的目标 ID，于是直接省略。手册同时给出一条区分大小写的正则结构：ord: 前缀、64 位十六进制的交易 ID、i 分隔符、不允许前导零的十进制序号。铭文 URI 是不区分大小写的，所以生成二维码时可以启用更紧凑的字母数字模式——同样的数据能塞进更小的码图；显示风格上，手册仍建议优先使用小写形式，保持跨界面一致。
语义部分才是这节文档的核心约定。一个铭文 URI 所指的对象，是一个 HTTP 资源，其内容、内容类型、内容编码与长度都必须对应于该 ID 的铭文。手册还写死了一条容易被忽视的规则：URI 的指称永远是目标铭文自己的原始内容，而不是它委托（delegate）的铭文内容——无论目标有没有委托字段。这个决定看似苛刻，实际保护了”按 ID 引用”的可预期性：引用的是链上那条身份记录本身，展示端要不要跟随委托去渲染另一段内容，是使用方的展示策略，不改变 URI 指向的事实。
对使用者来说，ord: 写法的现实用途有三类：跨索引器复制粘贴铭文身份（比抄一长串 txid 加序号更不容易抄错格式）；物理载体（卡片、海报、周边）上的二维码编码；以及外部程序解析时的标准输入。风险同样清楚：它是草案，不同站点可能同时支持 ord: 与站内路径两种写法；引用前最好确认接收方工具是否认识这个前缀，关键场合保留原始铭文 ID 文本作为兜底。把 URI 当成”链上字段”是误区——链上记录里没有这串前缀，它只是社区正在统一的一种寻址语言。
工程上使用铭文 URI，还有几条草案边界要提前知道。第一，ord: 与内容 URL 是两码事：内容 URL（形如某站点的 /content/<ID> 路径）依赖具体服务器在线与否，ord: URI 试图做的是与站点无关的身份写法，任何工具都可以自行解析、拼接或渲染它，链上并不会因为某种写法流行而多出字段。第二，草案文档只规范语法与指称，没有规范解析方式——用哪个索引器把 ord: 变成可点击页面，仍由工具方决定；同一串 URI 在不同钱包里可能一个可点一个只显示文本。第三，QR 码的紧凑字母数字模式确实能显著缩小码图，但扫描端的兼容性要实测，礼物卡上印得再优雅，扫不出来就是零。稳妥的打印做法是 URI 与裸铭文 ID 同时在场，外加一小段”该地址不托管任何私钥”的说明，让拿到卡片的人知道被寻址的只是一条链上记录。
把语法细节再压缩成三句话：前缀后不带双斜线，因为目标 ID 没有层级结构；交易 ID 必须 64 位十六进制，i 后的序号不许有前导零，所以 i007 是非法写法，正规形态是 i7，唯独零本身写作 i0；整条 URI 不区分大小写，显示用小写。正因为序号文法是严格正则，任何工具在解析失败时都应该直接报错，而不是”尽力猜测”——猜出来的 ID 一旦指错，指向的是另一枚真实存在的铭文，错误比解析失败更难被发现，这是所有处理 ord: 前缀的程序都该记住的一条。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。