Hello. 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 platforms. 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 http://www.vikingsoftware.com _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
