NFT 也能叫名字：ERC-7632 给代币编号加一层名称互转

一枚 NFT 在链上的身份证是一串数字：tokenId。可玩家之间交流从来不用编号——他们叫”那个城堡""3 号爵士”。名字好记却不可信：同名不同人、繁简混排、大小写陷阱都藏在其中。ERC-7632 尝试给这个问题定规矩：让带名字的代币提供编号与名称的官方互转通道。标准文档记录的状态为 Draft，创建于 2024 年 2 月 8 日，现状以标准仓库为准。

主接口：一对必须双向成立的函数

合规合约的核心是 IERC_NamedTokenCore 里的两个函数：idToName 把编号翻译成名称，nameToId 把名称翻译回编号。规范给它们定了硬约束：编号与名称必须是双向单射——一个编号只对应一个名称，一个名称也只对应一个编号，两个方向的连续换算必须还原：对任意编号，先转名字再转编号要回到原值；对任意名称也反过来成立。新名称引入时推荐发出 newName(tokenId, tokenName) 事件，让索引器能追上命名动作。合约若不想实现这对接口，也可以走规范给出的默认映射：tokenId 等于对 tokenName 求 keccak256 后当作整数——命名即编号，无需登记，但代价是名称本身必须严格规范化，因为差一个空格的哈希就是另一枚币。

ByName 伴生函数与扩展接口

规范还推荐一种工程习惯：凡是涉及 tokenId 的函数，配一个以 ByName 结尾的姊妹版本，把参数从编号换成名称，行为与原函数保持一致。对集成方，这意味着市场前端的搜索框可以直接把用户输入的名字喂给合约，不必自己维护一张随时可能过期的编号对照表。另有可选扩展接口处理名称质量：isValidTokenName 判断一个字符串是否是合法名称，normalizeTokenName 给出规范化形式——大小写折叠、去首尾空白之类的工作交给合约自己声明，而不是留给每个前端猜。

安全考量落在”像但不同”上

提案的安全部分直指视觉混淆：如果名称不做归一化，两个不同的名称可以长得几乎一样——全角半角、同形异码字符、末尾不可见空白，都能造出”看着一样其实不同”的名字对。规范的处理思路是：把合规前提设为”名称在全部代币中唯一”，若某合约确实允许非唯一名称，就必须通过扩展接口声明自己的归一化机制。这与 ENS 等命名系统多年沉淀的教训一致：人眼比对的可靠性远低于哈希比对，凡允许人眼比对的地方，就需要一个权威归一化函数来兜底。

对用户与开发者的实际意义

对开发者，接入命名代币的成本主要在两件事：给每个公开方法配 ByName 伴生版本；用事件把命名动作完整暴露给索引器。对用户，这份标准的价值在于把”你买的名字和链上登记的名字是同一个”变成可查询事实——购买前调用一次 nameToId 再 idToName 回环校验，或者看索引器是否已按 newName 事件建好对照表，都能把”同名仿冒”提前挡在交易之前。要留意的是，标准允许默认映射路径存在：若项目没有实现显式接口又声称”名字即编号”，你就要了解它的哈希函数与大小写约定，任何一个细节理解偏差都会把资产指向完全另一枚代币。正规做法依然是：以项目官方文档给出的合约地址为准，用已验证合约的返回值为最终答案。

名字之外不改变的事

命名层解决的是寻址与表达，不改变任何所有权语义：transferFrom、approve、balanceOf 这些 721 核心函数仍按编号工作，名称只是更好用的入口。也不要期待名称带来稀缺性——名字是否限量、谁有权铸造新名字，都是项目自己的规则，标准只保证”一个名字钉在一枚编号上”这件事可机器验证。把这两层分开，就不会被”命名资产更保值”这类话术带偏：值钱的是资产与规则，名字只是标签。

最后提醒：本文只做机制科普，不构成投资建议；购买任何”命名资产”前，请通过官方渠道核验合约地址与命名规则，勿以社群截图作为名称归属的证明。