[Interest] QFile::encodeName in all platforms
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
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