问题
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.
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.
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*.
I have another API that I'm using that can only take filenames as char* (That I also can't touch).
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.
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?
回答1:
Well, the correct way to fix this would be to fix the other API. Accepting only narrow, non-unicode filenames is simply broken behavior.
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: 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.
来源：https://stackoverflow.com/questions/6351227/opening-files-on-non-ansi-systems-via-old-non-wchar-api-functions