实用教程
用 Claude Opus 5.5 排查素材文件名的 Unicode 冲突
让 Claude Opus 5.5 先比较原始素材名与规范化比较键，再提出重命名方案。两个看起来一样的名字，内部 Unicode 序列可能不同。必须保留原始路径和稳定素材 ID；规范化名称相同，只说明需要排查冲突，不代表可以删除文件。
让 Claude Opus 5.5 先比较原始素材名与规范化比较键，再提出重命名方案。两个看起来一样的名字，内部 Unicode 序列可能不同。必须保留原始路径和稳定素材 ID；规范化名称相同，只说明需要排查冲突，不代表可以删除文件。
这是字符问题，不只是命名模板问题
一则 2017 年的开发者报告描述了云端文件系统中的 NFC/NFD 文件名行为。这是特定历史环境的自述，不能推广成“所有 Mac 都会改写名称”，也不能假定 ZIP 接收方与你的文件系统行为一致。
Unicode 规范化常见问题区分了规范等价与兼容等价。NFC 和 NFD 可以用不同序列表示规范等价的文本；NFKC 还可能合并兼容字符差异，不能作为品牌标识的无害默认处理。JavaScript 的 String.normalize 文档提供了明确的比较操作。
| 字段 | 保留或计算 | 用途 |
|---|---|---|
| 素材 ID 与原始相对路径 | 原样保留 | 找到准确源文件 |
| NFC 比较键 | 单独计算 | 归组规范等价名称 |
| 真实内容哈希 | 从文件字节计算 | 区分内容，不看外观猜 |
| 目标目录规则 | 单独记录 | 检查大小写与文件系统限制 |
算清两个视觉相同的名字
下面第一个名字使用单个预组合 é，第二个使用 e 加组合重音。它们分别有 8、9 个 Unicode 码点，占 9、10 个 UTF-8 字节。这只是示例字符串的计算，不是通用文件名长度规则。
const names = ['caf\u00e9.png', 'cafe\u0301.png'];
const rows = names.map(raw => ({
raw,
codePoints: [...raw].length,
utf8Bytes: new TextEncoder().encode(raw).length,
nfcKey: raw.normalize('NFC')
}));
console.table(rows);两者的 NFC 键相同。如果真实文件哈希不同，保留两份素材，查清各自对应哪个批准版本。即使哈希相同，也只证明字节一致，不同广告记录可能本来就引用同一图片。比较键不能悄悄替换存储键、公开 URL 或显示名称。目标目录是否忽略大小写，是另一项独立规则。
完整的只读审计提示词
审计提供的素材清单，不重命名、不删除、不覆盖、不上传。输入必须包含稳定素材ID、原始相对路径，以及可获得时从真实字节计算的哈希；不得编造哈希。
保留原始字符串，另加NFC比较键。分别报告规范等价组、大小写规则冲突和完全重复路径。不要用NFKC或转小写直接改写品牌名与标识符。
每个冲突列出ID、带转义码点的原始字符串、已有哈希、批准记录和待决事项。规范化名称相同不代表内容相同；哈希相同也不授权删除广告引用。
冲突解决后才输出建议目标清单。没有单独批准迁移，不改已有公开URL。获批复制到新目录后，比对源与目标数量及字节哈希，并在实际接收环境解压测试包。明确报告未测试的环境。这是按官方提示指南限定范围的 Opus 使用方案。示例字符串已在本地计算，但没有执行真实素材重命名、接收方解压测试或 Opus 实测。
把比较与迁移分开
报告中始终保留两个源文件的两行记录，即使它们只属于一个 NFC 分组。复制前解决批准状态和目标冲突。测试压缩包要包含这些具体问题名称；自己的文件管理器显示正常，不证明接收流程也能保留它们。如果确实要改现有网页 URL，重定向、引用和缓存应作为独立迁移处理。
**是不是去掉所有重音最省事？** 这样会改名，还可能产生新冲突。交付系统限制字符时，可使用稳定 ID。
**NFC 能解决所有文件名冲突吗？** 不能。大小写、保留名称、路径长度和权限仍需按目标环境检查。
从 Panelly Studio导出批准的图片，再绑定到素材清单。广告素材命名流程解释可读的广告字段，本篇检查底层字符序列。两种流程都不假定 Panelly 已集成 Opus。
