0

我在另一个关于 Unicode 的 SO 问题下找到了这个声明,我想进一步详细说明这个相当令人惊讶的事实。

  1. 相信一旦您成功创建了一个给定名称的文件,当您在其封闭目录上运行 ls 或 readdir 时,您实际上会发现使用您创建它的名称的文件是错误的、损坏的和错误的代码。不要对此感到惊讶!

这种情况什么时候发生,该怎么办?

4

1 回答 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 回答