[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [Issue N23835] [PATCH] Files with non-utf8 names unaccessible
From:       Thiago Macieira <thiagom () wanadoo ! fr>
Date:       2003-07-04 10:21:54
[Download RAW message or body]


Waldo Bastian wrote:
>> I've implemented a slightly different solution mapping the characters to
>> a surrogate pair in the supplementary private use area, as this should
>> hopefully lead to less conflicts. The only disadvantage is that
>> currently (until we have a better surrogate handling in Qt) each of
>> these characters will show up as two boxes instead of one box and the
>> char mapped from latin1. The diff against qt-3.2 beta2 is attached.
>
>I don't think this is very bad, since the character may very well not be
>latin1 either anyway. Not using 0xfffd may give problems wrt compatibility
>though: currently a Qt application could check if a QString contains 0xfffd
>to decide whether the string used as input was valid utf8. I don't think
>QString provides another way to check if utf8 conversion was/will be
>successful.

This may solve only half of our problems.

The decodeFilename call is supposed to convert a given 8-bit character 
sequence into a unique Unicode representation, so that it can be used for 
displaying in widgets and titlebars. It's also necessary that this encoding, 
whatever it may be, gets us the original 8-bit character sequence when doing 
encodeFilename.

That is, apparently, solved.

However, the second part of the problem is what I'm worried about: I need to 
specify the encoding to be tried for the original string. And the attached 
patch deals with UTF-8 only, but some other encodings might fail as well. My 
situation is that of bug #56197, in which we have to try different encodings 
given the user's selection in a menu.

-- 
  Thiago Macieira  -  Registered Linux user #65028
   thiagom@mail.com           
    ICQ UIN: 1967141   PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]