tags:

views:

211

answers:

3

There is a 3rd lib only accept char* filename e.g. 3rdlib_func_name(char* file_name). Every things get wrong when I provide a filename in Chinese or Japanese.

Is there any way to make this lib open UNICODE filename? The program is running on Windows.

Thanks for your reply.

+1  A: 

No, there isn't unless you can recompile it from modified source (a major undertaking). You might have better luck feeding the 3rd party library short filenames, like AHDF76~4.DOC; these filenames use ASCII. See GetShortPathName.

Anton Tykhyy
Thanks!I have tried this awesome GetShortPathName. It does work sometimes, but not all the time:)
zengkun100
A: 

You may try to convert the string to local code page:

setlocale(LC_ALL,"Japanese_Japan.932");
std::string file_name = convert_to_codepage_932(utf16_file_name);
3rdlib_func_name(file_name.c_str());

Otherwise?

Blame windows for not supporting UTF-8 ;-)

Artyom
Thanks for your reply.The current Windows ANSI code page used on my computer is 1252(retrieve from GetACP). I have tried 3 code pages CP_ACP, CP_UTF8 and 936(Simplified Chinese Code Page) to call WideCharToMultiByte to change a UNICODE Chinese filename to multibyte filename. The 3rdlib_func_name returns "file not found" with all of these 3 multibyte filenames.
zengkun100
Note. CP_UTF8 is not supported as filesystem code-page. I'd suggest just run tests with fopen and then with 3rd part library.If does not help stop using Windows `;-)`.
Artyom
To be honest, my home computer runs on Ubuntu, but I work on Windows:) I have tried fopen, it doesn't work either.
zengkun100
@zengkun100 This is known Windows issue. You met such issues almost anywhere when it comes to files opening and the library wasn't developed originally for Windows and UTF-16 support.
Artyom
@Artyonm thanks! I have learned a lot from this post:)
zengkun100
A: 

We has a similar problem too. Luckily there's a solution, though it's kinda tricky.

If the file/directory already exists - you may use the GetShortPathName function. The resulting "short" path name is guaranteed not to contain non-latin characters.

  1. Call GetShortPathNameW (unicode version) to get the "short" path string.
  2. Convert the short path into the ANSI string (use WideCharToMultiByte).
  3. Give the resulting ANSI string to the stupid 3rd-party lib.

Now, if the file/directory doesn't exist yet - you may not obtain its short pathname. In such a case you should create it first.

valdo
Thanks, I have tried this solution. It does not 100 percent work:( We have called the lib supplier this afternoon.
zengkun100