通过旧的非wcharAPI函数在非ANSI系统上打开文件

如何解决通过旧的非wcharAPI函数在非ANSI系统上打开文件

|| 我正在写一些让我发疯的中间件。我正在寻找一些I18N专家来帮助我-这对我来说还很新。 现在这一切都在Windows中，但是它也必须在Linux和Mac上也可以工作，尽管我敢打赌，这些将很容易。 我有一个系统（我无法触摸），它会给我一个作为wchar_t *的字符串。它以UTF-8或当前语言环境输入，并通过魔术使我得到wchar_t *。 我有另一个正在使用的API，该API只能将文件名作为char *使用（我也无法使用）。 因此，我一直在做的事情是将我的文件名放在wchar_t *中，并使用Windows API函数WideCharToMultiByte并将其转换为char *并将其传递给我的其他API函数。在质量检查人员决定使用日语操作系统之前，它一直工作良好。现在，fopen（无法触及的API深度）失败了。 我已经尝试在我的WideCharToMultiByte调用中同时使用CP_ACP和CP_UTF8，并且两者都可以在我的开发（美国英语）计算机上使用，即使文件名中包含日语字符也是如此。但是两者都无法在日语操作系统上运行。 关于如何真正处理这些文件名的任何提示？     

解决方法

        好吧，解决此问题的正确方法是修复其他API。仅接受狭窄的非unicode文件名就是坏行为。 但是...你说你不能那样做。您可以通过获取短文件名（不包含任何非ANSI字符）并将其传递给损坏的API来解决此问题。 （这样做的原因是短文件名旨在用于16位应用程序，而16位窗口完全不支持Unicode） 当然，如果文件名不能表示为短文件名，或者目标计算机上的短文件名已关闭，则这将失败—但这实际上是唯一的选择。 编辑：更多注意事项-如果文件名包含Unicode，则短文件名通常将不可读。它将重命名为使用一堆十六进制垃圾，该垃圾在世界范围内仅限于8.3文件名的情况下唯一标识该文件。