你不会想象像使用C++标准库为Windows应用程序打开文件那样基本的东西很棘手......但它似乎是.在这里,我指的是UTF-8,但我可以转换为UTF-16或其他任何东西,重点是从Unicode文件名中获取一个ofstream实例.在我推出自己的解决方案之前,这里有一条首选路线吗？特别是跨平台的？
这不是一个设计问题,实际上,虽然看起来像它.(好吧,好吧,这是一个设计问题).我想知道的是为什么C++ std::fstream类不会std::string在构造函数或开放方法中使用它们.每个人都喜欢代码示例:
#include <iostream>
#include <fstream>
#include <string>
int main()
{
std::string filename = "testfile";
std::ifstream fin;
fin.open(filename.c_str()); // Works just fine.
fin.close();
//fin.open(filename); // Error: no such method.
//fin.close();
}
这使我一直处理文件.当然,C++库会std::string尽可能使用？
客户抱怨我们的代码用于在文件名中写入带有日文字符的文件,但在所有情况下都不再有效.我们总是使用好的旧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文件名.