通过旧(非wchar)API函数在非ANSI系统上打开文件

Question

我正在写一些让我疯狂的中间件.我正在寻找一些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,并且在我的开发(美国 - 英语)机器上工作,即使文件名中包含日文字符.但两者都失败了日本的操作系统.

关于我应该如何处理这些文件名的任何提示？

Answer 1

好吧,解决这个问题的正确方法是修复其他API.仅接受狭窄的非unicode文件名只是简单的行为.

但是......你说你不能这样做.您可以通过获取短文件名来解决此问题,该文件名不具有任何非ANSI字符,而是将其传递给损坏的API.(原因是短文件名设计用于16位应用程序,16位窗口根本不支持Unicode)

当然,如果文件名不能表示为短文件名,或者在目标机器上关闭了短文件名,那么这将失败 - 但它确实是这里唯一的选择.

编辑:还有一个注意事项 - 如果文件名包含Unicode,短文件名通常不会是人类可读的.它将被重命名为使用一堆十六进制垃圾,它在一个仅限于8.3文件名的世界中唯一标识该文件.