我在另一个关于 Unicode 的 SO 问题下找到了这个声明,我想进一步详细说明这个相当令人惊讶的事实。
- 相信一旦您成功创建了一个给定名称的文件,当您在其封闭目录上运行 ls 或 readdir 时,您实际上会发现使用您创建它的名称的文件是错误的、损坏的和错误的代码。不要对此感到惊讶!
这种情况什么时候发生,该怎么办?
我在另一个关于 Unicode 的 SO 问题下找到了这个声明,我想进一步详细说明这个相当令人惊讶的事实。
- 相信一旦您成功创建了一个给定名称的文件,当您在其封闭目录上运行 ls 或 readdir 时,您实际上会发现使用您创建它的名称的文件是错误的、损坏的和错误的代码。不要对此感到惊讶!
这种情况什么时候发生,该怎么办?
我想到的第一个例子:如果你在 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。