是否将文件名标准化为 NFC（Unicode）答案

【问题标题】：Normalize filenames to NFC or not (Unicode)是否将文件名标准化为 NFC（Unicode）
【发布时间】：2015-10-31 23:20:15
【问题描述】：

我编写了一个更喜欢 NFC 的应用程序。当我从 OSX 获得文件名时，它被归一化为 NFD。据我所知，我不应该像这里提到的那样转换数据：

[...]（不是因为 NFD 或这个版本的 NFD 有问题，但因为永远不应该更改数据。文件名不得标准化。）[...]

当我将文件名与用户输入（在 NFC 中）进行比较时，我必须实现一个相应的比较函数来处理 Unicode 等效性。但这可能比需要的慢得多。如果我将文件名规范化为 NFC 不是更好吗？当只涉及内存比较时，它会大大提高速度。

【问题讨论】：

【解决方案1】：

您链接到的建议的准确性取决于相关文件系统。

“标准”Linux 文件系统没有规定文件名的编码（它们被视为原始字节），因此假设它们是 UTF-8 并对其进行规范化是错误的，并且可能会导致问题。

另一方面，Mac OS X (HFS+) 上的默认文件系统强制所有文件名在 NFD 变体中都是有效的 UTF-16。如果您需要比较文件路径，您应该使用类似的格式 - 最好使用系统提供的 API，因为它的 NFD 格式与旧版本的 Unicode 相关联。

【讨论】：

您说 HFS+ 强制所有文件名都是有效的 NFD UTF-16。为什么下面的代码会保留原始代码点？正如您从我的另一个问题 (stackoverflow.com/questions/31899371/…) 中看到的那样，从欧姆到任何其他范式的任何转换都会导致 U+03a9。 os.mkdir(u"\u2126"); for i in os.listdir("."): print(repr(i), repr(i.decode(sys.getfilesystemencoding()))) 输出：("'\\xe2\\x84\\xa6'", "u'\\u2126'")
所以我真的应该将其他字符串转换为目标规范化形式，而不是将文件名转换为 NFC 吗？假设文件名的用户输入字段应转换为 UTF-16 (NFD) 以确保正确比较？
HFS+ 使用 NFD 的变体，在 this table 中进行了描述。请注意，U+2126 没有出现在该表中；但是如果你用U+037E 来尝试你的例子，你会发现它被U+003B 取代了。