[Issue N23835] [PATCH] Files with non-utf8 names unaccessible from Qt when using utf8 locale

Waldo Bastian bastian at kde.org
Fri Jul 4 11:50:53 BST 2003

Hash: SHA1

On Friday 04 July 2003 12:21, Thiago Macieira wrote:
> 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.

As long as you use the same codec for both encoding and decoding you should be 
cool. At least with all single-byte encodings and, with this patch applied, 
utf8 encoding.

I don't know if there are other multi-byte encodings around that have the same 
problem as utf8. Some of the encodings popular in Asia are multi-byte, but I 
am not familar with them beyond that. They may pose a problem.

We must be careful with autodetection of encoding, that will work fine when 
decoding (to QString), but there is a risk that we no longer know which 
encoding was used when we get to the point where we need to encode the string 
again (from QString). 

It may be possible to pass the encoded string as-is via KURL, although that is 
somewhat fragile. For that to work in combination with the ftp slave, we 
probably need KURL::setPath8Bit(const QCString &) and QCString 
KURL::path8Bit(). Not sure if that will work, since it relies on URLs being 
passed as KURL and that may not always be the case.

- -- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org


More information about the kde-core-devel mailing list