https://bugs.kde.org/show_bug.cgi?id=384321

--- Comment #5 from Pali Rohár <pali.ro...@gmail.com> ---
Block device name is just ordinary file. In most cases people use only ascii
characters (because non-ascii names are lot of times broken in CLI or GUI
tools), but there is no restrictions for 8bit. On linux you can call mknod and
create block device on file system with any file name (all 8 bit characters
expect slash and nul are allowed)...

Now looking at QFile::decodeName() implementation (it is inlined in header file
qfile.h) and there is #ifdef. On linux it just call QString::fromLocal8Bit()
and on other platforms it doing some UTF-8 normalization.

So this filename stuff depends on you, if you are going to write application
which is linux-only then QString::fromLocal8Bit() is for sure enough (as
QFile::decodeName() is doing this on linux). But if you are going to support
also other systems (Mac OS, Windows, ...) then it is really a good idea to use
Qt functions which deals with those platform dependent problems...

But problem with LC_ALL=C is a real problem for linux, because all application
which uses wide characters (in C it is wchar_t and in C++ it is also
std::wstring) uses encoding specified in LC_CTYPE (resp. LC_ALL). And "C" means
7bit ASCII. Not Latin1, not UTF-8. And both C and C++ libraries uses LC_CTYPE
for converting char*/std::string to wchar_t*/std::wstring according to LC_CTYPE
(resp. LC_ALL). So with restriction to 7bit ASCII (as "C" is ASCII) you just
kill whole UTF-8/Unicode support.

To test current encoding you can use this simple C program:

  #include <stdio.h>
  #include <locale.h>
  #include <langinfo.h>
  int main() { setlocale(LC_CTYPE,""); puts(nl_langinfo(CODESET)); return 0; }

Also it is important that some programs works in UTF-8 independently of how is
LC_ALL configured (e.g mkudffs when is called with --utf8 param, but there are
probably others too). And so for these programs it is needed to use fromUtf8
and toUtf8, not fromLocal8bit/toLocal8bit (as those functions decode/encode
according to LC_CTYPE/LC_ALL).

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to