在非ANSI系统上通过旧（非wchar）API函数打开文件 [英] opening files on non-ANSI systems via old (non wchar) API functions

问题描述

我正在写一些中间件，这使我坚持。我正在寻找一些I18N的专家帮助我 - 这对我来说都是新的。

I'm writing some middleware that's driving me nuts. I'm looking for some I18N experts to help me out - this is all pretty new to me.

现在这是所有在Windows，但它必须工作在Linux和Mac上，虽然我敢打赌这些将很容易。

Right now this is all in Windows, but it will have to work on Linux and Mac too, though I bet those will be easy.

我有一个系统（我不能碰），将给我一个字符串wchar_t *。它接受UTF-8或当前语言环境的输入，并给魔术给我一个wchar_t *。

I have a system (that I can't touch) that will give me a string that's as a wchar_t*. It takes input in either UTF-8 or the current locale and does the magic to give me a wchar_t*.

我有另一个我使用的API，只能将文件名作为char *（我也不能触摸）。

I have another API that I'm using that can only take filenames as char* (That I also can't touch).

所以我一直在做的是在wchar_t *中使用我的文件名，并使用Windows API函数WideCharToMultiByte并将其转换为char *，并将其传递给我的其他API函数。它工作很好，直到QA决定使用日本操作系统。

So what I've been doing is taking my filename in wchar_t* and using the Windows API function WideCharToMultiByte and converting it to a char* and passing that to my other API function. It was working just fine until QA decided to use a Japanese OS. Now the fopen (deep inside the API that I can't touch) is failing.

我尝试在我的WideCharToMultiByte调用中同时使用CP_ACP和CP_UTF8，并且两者都可以工作我的开发（美国英语）机器甚至在文件名中有日语字符。但是在日本操作系统上都失败了。

I've tried using both CP_ACP and CP_UTF8 in my WideCharToMultiByte call and both work on my development (US-English) machine even with Japanese characters in the filename. But both fail on the Japanese OS.

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

Any hints on how I should really be handling these filenames?

推荐答案

很好，解决这个问题的正确方法是修复其他API。只接受狭窄的非unicode文件名是简单的破坏行为。

Well, the correct way to fix this would be to fix the other API. Accepting only narrow, non-unicode filenames is simply broken behavior.

但是...你说你不能这样做。你可以通过获取短文件名来解决这个问题，它不会有任何非ANSI字符，而是传递给破坏的API。 （这是因为短文件名设计用于16位应用程序，并且16位窗口根本不支持Unicode）

But... you said you can't do that. You might be able to work around this by getting the short file name, which will not have any non ANSI characters, and passing that to the broken API instead. (The reason for this is that short filenames are designed to work for 16 bit applications, and 16 bit windows didn't support Unicode at all)

当然这将失败如果文件名不能表示为短文件名，或者在目标机器上关闭短文件名，但这是真正唯一的选择。

Of course this will fail if the filename is not representable as a short file name, or if short file names are turned off on the target machine -- but it's really the only option here.

EDIT ：另一个注意事项 - 如果文件名包含Unicode，短文件名通常不会是人类可读的。它将被重命名为使用一堆十六进制的垃圾，唯一标识该文件在一个世界限制为8.3文件名。

EDIT: One more note -- if the filename contains Unicode the short filename will generally not be human readable. It will be renamed to use a bunch of hex garbage which uniquely identifies the file in a world restricted to 8.3 filenames.

这篇关于在非ANSI系统上通过旧（非wchar）API函数打开文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！