3

I have to use a library that accepts file names as strings (const char*). Internally files are opened with fopen. Is there a way to make this library to accept unicode file name? Can I use WideCharToMultiByte to convert unicode names into utf before passing them to the library?

One possible (undesirable) solution is to change library interface (char* -> wchar_t*) and replace fopen with windows specific _wopen. Another solution is to use create symbolic links to files and pass those to the library, but it is limited to NTFS volumes only.

quantum_well
  • 869
  • 1
  • 9
  • 17
  • 2
    You cannot use `WideCharToMultiByte` to convert to UTF-8 because Windows' narrow-`char` functions do not support UTF-8. They support only the local encoding (in which not all Unicode characters will be representable). Changing your library interface to use `wchar_t` is the typical thing to do on Windows. – jamesdlin Jan 28 '14 at 11:28
  • What is undesirable on _wopen() with https://stackoverflow.com/questions/148403/utf8-to-from-wide-char-conversion-in-stl ? It's the only way to do it properly! – Sam Ginrich May 16 '23 at 07:35

2 Answers2

5

Best way would be to rewrite the lib... Just my 2 Cents.

But if it is just about to open an existing file you can use GetShortPathName You find an existing discussion about this way here.

xMRi
  • 14,982
  • 3
  • 26
  • 59
  • `GetShortPathName` does not imply ASCII characters. Short filename aliases can be disabled on specific volumes as well. In addition, `GetShortPathName` can fail for cases, where you do not have permission to query parent directories. See [Short vs. Long Names](http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247.aspx#short_vs._long_names) for more information. – IInspectable Jan 28 '14 at 21:49
  • I already added a link to hat problem and a discussion about that! Didn't I? – xMRi Jan 29 '14 at 08:03
  • The link you provided has no mention of the failure mode I described: Failure to retrieve a short file name when the system cannot query a parent directory. No need to get all hissy. – IInspectable Jan 29 '14 at 09:00
  • I added two links! And the second explains the failure and problems. The second explains in detail how to prevent NTFS in 8.3 short names with: NtfsAllowExtendedCharacterIn8dot3Name. So again? What did I miss with my answer? – xMRi Jan 29 '14 at 11:38
  • 1
    This is getting tedious: The second link you provided does not illustrate the failure mode I pointed out **twice** already: The call to GetShortPathName can **fail** with an **access violation**, even if you have full access to the file in question. – IInspectable Jan 29 '14 at 12:01
2

Using WideCharToMultiByte you are only able to open files that have file names that contain only ANSI characters. This is because the ANSI variants (using a "char *" type argument) of file functions are not able to open files that contain characters above 255 in the file name.

Using GetShortPathName has the disadvantage that it might not work on certain file systems (maybe certain types of network drives) that do not support "8.3" file names.

I would rewrite the library using the "_wfopen" function (the UNICODE equivalent of "fopen" is "_wfopen", not "_wopen").

Please note that the second argument of "fopen" must also be an UNICODE string when using _wfopen.

Martin Rosenau
  • 17,897
  • 3
  • 19
  • 38