铭文怎么知道自己是谁：内容路径约定与自展示页

一件刻进比特币的 HTML 铭文，怎么在画面里显示“我自己的编号”？这在直觉上说不通：编号是由那笔刻写交易的位置算出来的，作品出厂时并不知道自己会排第几。答案不在链上，而在一条渲染约定里——内容路径。

手册给所有提供铭文内容的程序定了一条硬规矩：编号为某值的铭文，其内容必须能从“内容路径加该编号”这一地址上取到。这条规矩原本的用途是让递归引用有稳定的互取地址：铭文之间互相引用素材时，需要一个双方都认可的寻址方式。规矩一旦普及，副作用就出现了——铭文的代码可以反过来利用它认识自己。

机制非常朴素。浏览器打开一件 HTML 铭文时，访问地址的末尾就是这件铭文的编号。页面里的脚本把当前网址路径拆开、取最后一段，就拿到了“我是谁”。拿到自己的编号能干什么？可以把它显示在画面上；可以向索引器请求与这个编号相关的接口数据；可以再按编号去取其他铭文的素材。于是，一段出厂时不含任何具体编号信息的代码，在运行时把自己装配成了一个独一无二、且知道自身身份的页面。这类“自展示”的做法，是不少链上生成作品把展示逻辑整体刻进链上的关键一环。

看清机制，也就看清了依赖。第一，它依赖“内容挂在固定路径”这条约定被渲染方遵守。官方索引器遵守它；第三方市场如果用自己的路径、或者把内容转存到代理域名下，页面脚本拆出来的字符串就不再是真正的铭文编号，自引用当场失灵，画面可能空白或错乱。第二，它依赖接口策略。自展示页常顺手请求数据接口，不同环境对这类请求的放行程度不同，有的环境会把它拦下来，作品就停在半成品状态。第三，它依赖沙箱规则——HTML 与 SVG 是在受限环境里渲染的，能执行什么由渲染方的安全策略决定。

买家侧的核验因此很具体。遇到“会自己装配自己”的 HTML 铭文，先在浏览器里直接按内容路径打开它：地址应当是干净的铭文编号，而不是某个市场的代理子域。同一个编号，在官方索引器、钱包内嵌页、交易市场可能给出三种表现——完整、残缺、空白。三种里只有地址末尾直接是铭文编号的那一种，算真正验证了自引用机制，其余两种是经过转译的结果，不该被当成链上事实。

还有一个必须拆开的混淆：页面读到的“自己”是编号这一层信息，不是所有权状态。能显示“我是第几号”，不代表它知道“现在归谁”；持有人、转让次数这些信息在页面可见性之外，由索引层的另一组数据回答。宣传图把两者并排放在一起讲时，记得它们是两条不同的数据链。

顺带补一个与委托互锁的细节：索引器为“原件与委托件”准备了分开的取回路径——手册的递归端点清单里有专门返回未委托内容的接口，用于跳过委托路由、直接取这件铭文自己刻的字节。这个通道的存在本身就说明：渲染时“按说明书取件”是被默认执行的策略，而策略是可以绕过的。核验委托类藏品时，绕开路由取一次原件，能看到这件链上资产真正自己拥有的内容是什么——多数时候那只是几十字节的指向记录，这个画面感对理解你买了什么很有帮助。

把视角再放宽一点：内容路径是铭文生态的一个微型基础设施协议。它不在比特币共识里，任何软件理论上都能不遵守，但主流实现都遵守，于是上面长出了递归艺术、自展示、链上小商店这些玩法。基础设施协议的脆弱性也在这里：它靠实现者的自觉维持。理解了一件作品对它的依赖程度，你就能预判它在不同店面里的表现差异——这不是艺术问题，是软件问题。本文为机制说明，不构成任何投资建议。