一位客户提示说，我们的代码曾经在文件名中写入带有日语字符的文件，但在所有情况下都不再有效。我们一直只使用良好的旧 char * 字符串来表示文件名，所以它曾经起作用让我有点震惊，而且我们没有做任何我知道应该让它停止工作的事情。我让他们给我发了一个文件，里面有一个从我们的软件导出的嵌入式文件名，看起来这些字符串使用十六进制字符 82 和 83 作为双字节序列的第一个字符来表示日语字符。在网上四处闲逛让我相信这可能是 SHIFT_JIS 和/或 Windows 代码页 932。
在我看来，之前发生的事情是 fopen 和 ofstream::open 使用此代码页接受的文件名；现在只有 fopen 可以。我已经检查了 Visual Studio fopen 文档，但没有看到关于什么可以将可接受的字符串传递给 fopen 的提示。
在短期内，我希望有人能为我阐明特定的 Windows fopen 与 ofstream::open 问题。从长远来看，我真的很想知道在 C++、Windows、Linux 和 OS X 上打开 Unicode(和其他？)文件名的公认方式。
编辑添加:我相信有效的打开是在“C”区域设置中完成的，而不起作用的打开是在客户的默认区域设置中完成的。然而，多年来情况一直如此，旧版本的程序至今仍在他们的系统上运行，因此这似乎无法解释我们所看到的问题。
更新:我向客户发送了一个小测试程序。它已验证 fopen 可以很好地处理 SHIFT_JIS 文件名，而 std::ofstream 则不能。这是在 Visual Studio 2005 中发生的，无论我使用默认区域设置还是“C”区域设置都会发生。
如果有人对这种行为有解释(以及为什么它神秘地改变了——也许是 VS2005 的服务包？)，我仍然很感兴趣，并希望为在可移植 C++ 中处理 Unicode 文件名提供一个全面的“最佳实践”代码。
最佳答案
fopen 或 ofstream::open 等函数将文件名作为 char *，但它被解释为在系统代码页中。
意思是可以是表示为Shift-JIS(cp932)的日文字符，也可以是简体中文(Big 5/cp936)，韩文，阿拉伯文，俄文，随便你命名(只要匹配OS系统代码即可)页)。
这也意味着它只能在日文系统上使用日文文件名。 更改系统代码页和应用程序“停止工作” 我怀疑这就是这里发生的情况(自 Win 2000 以来，Windows 在这方面没有大的变化)。
这是您更改系统代码页的方式:http://www.mihai-nita.net/article.php?artID=20050611a
从长远来看，您可能会考虑转向 Unicode(并使用 _wfopen、wofstream)。
关于c++ - Windows 代码页与标准 C/C++ 文件名的交互？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/480849/