Windows代码页与标准C/C++文件名的交互？

发布时间：2020-12-14 01:51:05 所属栏目：Windows 来源：网络整理

导读：客户抱怨我们的代码用于在文件名中写入带有日文字符的文件,但在所有情况下都不再有效.我们总是使用好的旧char *字符串来表示文件名,所以它对我来说有点震撼它曾经有效,我们没有做任何我知道应该让它停止工作的事情.我让他们发给我一个带有嵌入式文件名的文件

客户抱怨我们的代码用于在文件名中写入带有日文字符的文件,但在所有情况下都不再有效.我们总是使用好的旧char *字符串来表示文件名,所以它对我来说有点震撼它曾经有效,我们没有做任何我知道应该让它停止工作的事情.我让他们发给我一个带有嵌入式文件名的文件,从我们的软件导出它,看起来字符串使用十六进制字符82和83作为双字节序列的第一个字符来表示日文字符.在线浏览让我相信这可能是SHIFT_JIS和/或 Windows代码页932.

在我看来,之前发生的事情是fopen和ofstream ::使用此代码页打开接受的文件名;现在只有fopen呢.我已经检查了Visual Studio fopen docs,我没有看到什么使得可接受的字符串传递给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或ofs??tream :: open这样的函数将文件名称作为char *,但这被解释为在系统代码页中.

这意味着它可以是一个日语字符,表示为Shift-JIS(cp932),或简体中文(Big 5 / cp936),韩语,阿拉伯语,俄语,您可以将其命名(只要它与OS系统代码页匹配).

它还意味着它只能在日文系统上使用日文文件名.
更改系统代码页,应用程序“停止工作”
我怀疑这就是这里发生的事情(自从Win 2000以来,Windows在这个领域没有大的变化).

这是您更改系统代码页的方法：http://www.mihai-nita.net/article.php?artID=20050611a

从长远来看,您可能会考虑转向Unicode(并使用_wfopen,wofstream).

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!