客户抱怨我们的代码过去常常写入文件名中包含日语字符的文件，但现在不再适用于所有情况。我们一直只是使用良好的旧 char * 字符串来表示文件名，所以它曾经起作用让我有点震惊，而且我们没有做任何我知道应该让它停止工作的事情。我让他们向我发送了一个文件，其中嵌入了从我们的软件导出的文件名，看起来这些字符串使用十六进制字符 82 和 83 作为双字节序列的第一个字符来表示日语字符。在网上查了一下，我相信这可能是 SHIFT_JIS 和/或 Windows 代码页 932。
在我看来，之前发生的事情是 fopen 和 ofstream::open 使用此代码页接受的文件名；现在只有 fopen 可以。我检查了 Visual Studio fopen 文档，没有看到任何关于如何将可接受的字符串传递给 fopen 的提示。
从短期来看，我希望有人能为我阐明特定的 Windows fopen 与 ofstream::open 问题。从长远来看，我真的很想知道在 Windows、Linux 和 OS X 上用 C++ 打开 Unicode（和其他？）文件名的可接受方式。
编辑添加：我相信工作的打开是在“C”区域设置中完成的，而不起作用的打开是在客户的默认区域设置中完成的。然而，这种情况已经存在多年了，而且该程序的旧版本至今仍然可以在他们的系统上运行，因此这似乎不太可能解释我们所看到的问题。
更新：我向客户发送了一个小测试程序。已验证 fopen 对于 SHIFT_JIS 文件名可以正常工作，而 std::ofstream 则不能。这是在 Visual Studio 2005 中，无论我使用默认区域设置还是“C”区域设置，都会发生这种情况。
我仍然很感兴趣是否有人对这种行为有解释（以及为什么它神秘地改变了——也许是 VS2005 的服务包？），并希望整合一个全面的“最佳实践”来在可移植的 C++ 代码中处理 Unicode 文件名。
像 fopen 或 ofstream::open 这样的函数将文件名视为 char *，但这会被解释为位于系统代码页中。
这意味着它可以是表示为 Shift-JIS (cp932) 的日语字符，也可以是简体中文 (Big 5/cp936)、韩语、阿拉伯语、俄语，只要您能想到的都可以（只要它与操作系统代码页匹配）。
这也意味着它只能在日语系统上使用日语文件名。
更改系统代码页，应用程序“停止工作”
我怀疑这就是这里发生的情况（自 Win 2000 以来 Windows 在这方面没有大的变化）。
这是更改系统代码页的方法：http://www.mihai-nita.net/article.php?artID=20050611a
从长远来看，您可能会考虑转向 Unicode（并使用 _wfopen、wofstream）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
