Ingo Klöcker schrieb:
> On Tuesday 20 January 2009, Thiago Macieira wrote:
>> Em Terça-feira 20 Janeiro 2009, às 06:56:29, Christian Ehrlicher 
> escreveu:
>>> Christian Ehrlicher schrieb:
>>> <snip>
>>>
>>>>> I can see how QString is a bad choice for paths - Thiago had the
>>>>> utopia that everyone would be using UTF-8 by now :-) ... but
>>>>> then the right choice is QByteArray IMHO, not QUrl... Of course
>>>>> the issue is how to put the right stuff into the bytearray,
>>>>> especially now that everything everywhere is using QString for
>>>>> paths. Even QUrl::toLocalFile(), BTW...
>>>>>
>>>>> Seems to me that proper support for this can only be done in Qt
>>>>> 5....
>>>> I don't care if we use QString or QUrl but QByteArray is
>>>> completly wrong.
>>> To be more clear - QByteArray isn't bad at all but not optimal.
>>> QFile::encodeName() returns a locale-encoded string which is wrong.
>>> It would be better to use QString::toUtf8() but this would mean
>>> that we (on windows) have to convert it back to a QString which
>>> makes it really slow.
>> No, you were right: QByteArray is completely wrong on Windows. If we
>> use the locale encoding (on Windows, it's called "ANSI"), then we
>> can't open files whose names are outside the locale. If we use UTF-8,
>> then we have to be careful not to pass those byte arrays to other
>> programs or in other contexts, since they may try to open using the
>> ANSI functions and will then fail.
>>
>> No, the proper solution is to use QString and to NEVER use
>> QFile::encodeName on Windows.
>>
>> Of course, on Unix, the situation is the reverse: ALWAYS use
>> QFile::encodeName. But the moment that you use QString, then you
>> can't open or deal with files whose names fall outside the locale
>> encoding, since they can't be represented in QString in the first
>> place (since Qt 4.3).
>>
>> So, if we say:
>> 1) KDE 4 *only* works in UTF-8 on Unix systems
>> and
>> 2) Opening of or dealing with non-UTF-8 files is NOT supported with
>> KDE 4 apps
>>
>> then we can use QString in KDE_open.
>>
>> Interestingly that is, in fact, this is what are already doing. See
>> WONTFIX bug 165044 [Dolphin can't handle well files/folders with
>> wrong encoding].
>>
>> All distributions I've seen ship with UTF-8 locales by default, even
>> though some may give the option to switch non-UTF-8. Windows supports
>> Unicode filenames since 1995, with the VFAT filesystem which most
>> floppies and USB sticks use. Mac's filesystem is UTF-8 only (though
>> they prefer NFD instead of NFC).
> 
> Does anybody know what the situation is like in Asia? Do Asian 
> distributions also use UTF-8 locales by default?
> 
Any news here? I really would like to add those functions to fix some 
bugs on windows.


Christian