Is there a standard way to do an fopen with a unicode string file path?

Question

Is there a standard way to do an fopen with a unicode string file path?

Answer 1

In *nix, you simply use the standard fopen (see more information in reply from TokeMacGuy, or in this forum) In windows, you can use _wfopen, and then pass a unicode string (for more information, see MSDN).

As there is no real common way, I would wrap this call in a macro, together with all other system-dependent functions.

Answer 2

No, there's no standard way. There are some differences between operating systems. Here's how different OSs handle non-ASCII filenames.

Linux

Under Linux, a filename is simply a binary string. The convention on most modern distributions is to use UTF-8 for non-ASCII filenames. But in the beginning, it was common to encode filenames as ISO-8559-1. It's basically up to each application to choose an encoding, so you can even have different encodings used on the same filesystem. The LANG environment variable can give you a hint what the preferred encoding is. But these days, you can probably assume UTF-8 everywhere.

This is not without problems, though, because a filename containing an invalid UTF-8 sequence is perfectly valid on most Linux filesystems. How would you specify such a filename if you only support UTF-8? Ideally, you should support both UTF-8 and binary filenames.

OS X

The HFS filesystem on OS X uses Unicode (UTF-16) filenames internally. Most C (and POSIX) library functions like fopen accept UTF-8 strings (since they're 8-bit compatible) and convert them internally.

Windows

The Windows API uses UTF-16 for filenames, but fopen only supports ASCII. Many C library functions have a non-standard equivalent that accepts UTF-16 (wchar_t on Windows). For example, _wfopen instead of fopen.

Answer 3

This is a matter of your current locale. on my system, which is unicode enabled, file paths will be in unicode. I'm able to detect this by means of the locale command:

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"

The encoding of file paths is normally set system wide, so if your file path is not in the system's locale, you will need to convert it, perhaps by means of the iconv library.