我在另一个关于 Unicode 的 SO 问题下找到了这个声明，我想进一步详细说明这个相当令人惊讶的事实。
- 相信一旦您成功创建了一个给定名称的文件，当您在其封闭目录上运行 ls 或 readdir 时，您实际上会发现使用您创建它的名称的文件是错误的、损坏的和错误的代码。不要对此感到惊讶！
这种情况什么时候发生，该怎么办？
问问题
36 次
1 回答
1
我想到的第一个例子：如果你在 OSX 下创建一个名为é（单个代码点）的文件U+00E9，操作系统会将它实际存储为U+0065 U+0301（Unicode 分解）。该文件仍可使用原始名称访问，但列为已分解。
如何避免：除非您确定它们的名称是纯 ASCII，否则不要手动查找文件。
第二：在 Windows 上，如果您有一个名为 的文件e，请尝试创建（启用覆盖）一个名为 的文件E，操作系统仍会列出一个名为e. 如果e事先不存在，E则会创建一个名为的文件。
如何避免：除非您确定它们的名称是纯 ASCII，否则不要手动查找文件，并考虑大小写。尝试使用一致的大写风格。我建议全部小写。
第三：在 Windows 上，例如，如果您将 Windows 1250 作为系统编码，并且您想创建一个ê通过窄的、基于字符的 API命名的文件，e则会创建一个名为的文件。这当然很容易避免，但是这个确切的问题曾经困扰过我一次：WinRAR 提取文件ê.png，è.png然后e.png全部写入e.png，覆盖数据。其他编码混淆也可能发生类似问题。
如何避免：不要char*在 Windows 上使用将文件名作为 a 的 API。
于 2014-12-07T22:29:09.843 回答