[Interest] QFile::encodeName in all platforms

Alejandro Exojo alex at vikingsoftware.com
Tue Jan 16 22:48:11 CET 2018


When having to pass a QString with a file/path to an API that requires an 
std::string or const char*, I've been using QFile::encodeName. The docs say:

"Converts fileName to the local 8-bit encoding determined by the user's locale. 
This is sufficient for file names that the user chooses."

That made a lot of sense to me when I looked at the implementation, but I no 
longer see this as sufficient and correct (at least, not the docs) in all 

The implementation just does QString::toLocal8bit() in Windows and Linux, and 
toUtf8() on macOS.

On Linux, my experience it's been using ISO-8859-1(5) or UTF-8 in the locale. 
When I had Latin1, even though if the file system would allow anything because 
it doesn't care how it's encoded, I only had files encoded in Latin1 because it 
would not make sense to have anything else (it would not display correctly). 
Now with UTF-8, toLocal8Bit() encodes properly as well.

On macOS, it does toUtf8() plus the Unicode normalization. I don't have a Mac 
at reach right now, but I remember that working well with the usual POSIX APIs 
for files.

Now enter Windows. I don't see how that can be correct there. toLocal8Bit() 
converts to Latin1 for me, but the file system supports much more than that. 
Seems the file system is encoded as UTF-16, so the only standard type that 
seems can hold all Unicode that QString can is std::wstring, which obviously 
is quite different than what QFile::encodeName does.

I know that wstring is not ideal for cross platform code (wchar being 2 or 4 
bytes...), but is there any alternative if one needs to pass a file name in a 
QString to a library that can't use Qt?

Viking Software, Qt and C++ developers for hire

More information about the Interest mailing list