给键名加参数：ERC-8119 给 EVM 键值存储定的拼写规则

一个合约要为编号 1289 的藏品单独存一行元数据，最自然的写法是往 mapping(string => bytes) 里塞一个键。键名叫什么？有人写 registration-1289，有人写 registration1289，还有人各写各的分隔符。单看都合理，混在一起就是解析器的噩梦。ERC-8119 想把这些拼写统一起来。标准创建于 2025 年 1 月 6 日，仓库记录状态为 Draft，作者独立署名 Prem Makeig。

两种合法写法

第一种是单参数的斜杠冒号式：<key-label>/<key-parameter> 或 <key-label>:<key-parameter>，二者语义等价，解析时取首个出现的斜杠或冒号作分隔，其后所有字符都属于那唯一的参数——所以 website/http://website.com 合法，参数里再出现斜杠不碍事。第二种是方括号式：<key-label>[<param-1>][<param-2>]...，括号按序排列任意个数参数，像 resource[chain][1][token][42] 这样表达多级定位。规范给的正例覆盖多语言：name/María、description/说明、title/タイトル 都是合格键，因为参数部分允许任意 UTF-8；带百分号美元井号开头的标签也被明确认可。

字符规则里的讲究

标签部分的约束最严：只能是可见 ASCII，但还要剔除空格、斜杠、冒号、左方括号——控制字符与 DEL 同样出局，列出的允许码位写成 0x21-0x2E、0x30-0x39、0x3B-0x5A、0x5C-0x7E。这么做的理由在 Rationale 里：保留这三个字符给两种编码当骨架，标签里绝不让它们出现，解析才能不歧义。参数侧的坑在空格：斜杠或冒号后的第一个字符不许是空格；若数据本身以空格开头，规范给了引号技巧——写 quote/' space is the first character in the quote'，让空格成为引号内首字符。反例清单同样明确：连字符分隔、无分隔、标签内空格、缺右方括号、括号后拖尾巴，统统无效。

为什么值得读

规范给的反例清单其实比正例更能训练解析直觉。registration-1 用连字符，机器无法区分这是分隔符还是标签自身的字符；registration1 干脆没有分隔符，参数边界只能猜；标签里塞空格让键名在配置文件与 URL 两界都难处理；key/ value 里紧跟分隔符的空格，会在不同语言解析器里产生剥不剥离空白的分歧；括号少一个右半边、或 ] 之后还拖一串尾巴文本，都让键的形态不再可枚举。对照这些病例再看规则的用心：把最容易引发歧义的三类字符从标签里赶走，把自由全部留给参数，并用一个统一的首个分隔符解析律消灭双斜杠这类边角案例——键值存储没有 schema，标签就充当隐式的类型系统，这份标准的全部野心就是让这个隐式系统说得通。值得说明的是它不规定任何合约必须支持键参数，只约定带参数的键必须长这样，因此对既有合约零侵入，这也是它敢自称完全向后兼容的原因。

把规则浓缩成一条操作记忆：读任何 mapping(string => bytes) 型元数据前，先要一份键名样例。一个合规实现会给出 registration/1289 或 user[alice] 这样的形态，解析器据此就能判读其余键；一个给不出样例、键名风格大杂烩的实现，多参数语义一定已经各自漂移——这不代表项目有恶意，只代表你查不到某个键时，结论应当是格式不同，而非数据缺失。标准用一份极小的字符纪律换来的，正是把查无此键和查无此格式区分开的能力，这个区分在日常数据核查里价值远超它的篇幅。

标准自称完全向后兼容：不写参数化键的实现不受影响，用野格式的可以继续跑但建议迁移。它的野心不高——不碰 ABI、不定义类型，只治键名拼写这一件小事，也正因如此它示范了一条务实路径：与其发明复杂的数据系统，不如先把字符串的纪律立起来。对 NFT 读者的落点很实际：读任何合约的键值型元数据前，先确认实现按哪种约定拼键；同一份数据，registration/1 和 registration-1 是两个互不相通的存储位，查不到的键返回默认值，很容易被误读为项目方清空了数据。本文为机制说明，不构成任何投资建议。