我正在写一些让我疯狂的中间件。我正在寻找一些I18N专家来帮助我 - 这对我来说都很新鲜。
现在这一切都在Windows中，但它也必须在Linux和Mac上运行，不过我敢打赌这些都很容易。
我有一个系统（我无法触摸）会给我一个字符串，就像一个wchar_t *。它接受UTF-8或当前语言环境中的输入，并为魔法提供wchar_t *。
我有另一个我正在使用的API，它只能将文件名作为char *（我也无法触摸）。
所以我一直在做的是在wchar_t *中使用我的文件名并使用Windows API函数WideCharToMultiByte并将其转换为char *并将其传递给我的其他API函数。在QA决定使用日语操作系统之前，它工作正常。现在，fopen（我无法触及的API深处）失败了。
我尝试在我的WideCharToMultiByte调用中同时使用CP_ACP和CP_UTF8，并且即使文件名中包含日文字符，它们也可以在我的开发（美国 - 英语）机器上工作。但两者都失败了日本的操作系统。
关于我应该如何处理这些文件名的任何提示？
答案 0 :(得分：5)
嗯，解决这个问题的正确方法是修复其他API。仅接受狭窄的非unicode文件名只是破坏行为。
但是......你说你不能这样做。您可以通过获取短文件名来解决此问题，该文件名不具有任何非ANSI字符，而是将其传递给损坏的API。 （原因是短文件名设计用于16位应用程序，16位窗口根本不支持Unicode）
当然，如果文件名不能表示为短文件名，或者目标机器上的短文件名被关闭，那么这将失败 - 但它确实是唯一的选择。
编辑：还有一个注意事项 - 如果文件名包含Unicode，则短文件名通常不会是人类可读的。它将被重命名为使用一堆十六进制垃圾，它可以在限制为8.3文件名的世界中唯一标识文件。