文件名看着一样却匹配不到，怎样找出Unicode归一差异

文件名看着一样却匹配不到，应检查原始Unicode码点序列及规范等价形式，而不是直接再输一次名字。一个带重音字符可以用预组合码点，也可用基础字母加组合符；显示近似不代表字节相同。归一化能用于建立匹配规则，但改名之前必须检查是否产生冲突。

先确定文件与环境

附件用café.png的NFC与NFD两种字符串演示，没有在文件系统创建两份同名冲突图片。不同系统、文件系统和工具如何保存与比较Unicode名称并不统一，不能一句“Mac都这样”或“Windows一定自动处理”代替实测。本文只讨论文件引用身份，不判断字体能否显示这些字符。

操作与判断

1. 从包内清单和引用源分别读取原始名称，输出码点与UTF-8字节。不要仅靠截图比对，也不要在编辑器里手工重打后丢掉原序列；先保留可追溯输入。

2. 对副本字符串分别计算NFC和NFD，比较原始是否不同、规范等价是否相同。不同的标点、大小写或兼容字符不能一律当作规范等价，NFKC处理还有不同边界，不要混用。

3. 在改名计划中先检测归一后的重名。如果两个现有条目会归到同一键，必须停止自动覆盖，由内容方确认保留者或明确新ID；不以“看起来相同”为由删除其中一个。

4. 按约定统一名称与全部引用，再在实际接收链复验解压、导入和重新保存。只改文件名没改工程中的引用，会把一个匹配问题变成新的缺资源问题。

输入对照与结果边界

输入	关键码点	NFC后
café.png	U+00E9	预组合形式
café.png	U+0065 U+0301	与第一项相同
原始字节比较	不同	不能仅凭外观断言同一名称

verify.py实际确认两个输入原字符串不同，而NFC结果相同。它不模拟特定文件系统，也不证明真实包中的两项指向相同内容；即使名称等价，内容也可能不同。归一规则应该用于可解释匹配与冲突报告，而不是直接重写摘要清单或接受未知文件。

下载并复核

不同归一形式名称、真实UTF-8对照文本、码点与归一只读检测、实际结果。

下载names.json、equivalent-names.txt与verify.py。运行会列出码点及两种归一结果，输出使用转义以避免终端字体掩盖差异。正式扫描可以先只读生成冲突候选，不修改客户目录。将原名、归一键、引用位置和处理决定并列保留，确保迁移后仍可追溯原件。

已实际比较NFC/NFD字符串及码点，确认规范等价碰撞。未创建冲突名称文件，未测试真实跨平台文件系统。

失败时怎样继续

归一后仍匹配不到，检查大小写、空白、全角符号、转义及路径分隔符；它们不是同一种问题，不能靠反复归一化解决。若原文件名已经乱码，先查解压编码，归一不会恢复被错误解码的字节。禁止全局删除所有非ASCII字符，那会丢掉有意义名称并造成更多碰撞。

交付应约定名称规范形式和冲突处理策略，并对实际接收系统测试。需要重新命名时保留映射表且同步引用，发布前检查没有一对多或多对一覆盖。没有目标文件系统证据时，结论仅为发现字符串差异，不能写成跨机兼容已经完成。

相关背景可看展厅更换供应商时，怎样核对工程文件能否继续维护，继续从多媒体播放专题查找相关流程；需要结合项目确认时可查看工程对接咨询。

一级出处

• 规范等价字符串可以有不同码点序列，NFC/NFD是不同归一形式。

来源核对日期：2026-10-24。来源支持所述机制；本文合成输入与本地计算只证明所列文件及算法，不代表目标软件或现场设备已验收。