QFtp and non-Latin1 FTP servers

Hi,

I have a problem with QFtp class. The problem is involved, so please forgive the longish explanation.

The Problem

I need to use some FTP servers (mainly Chinese) which do not stick to an ASCII/Latin1 character set, but use a different one (GBK in my case). As no GUI-based FTP client I know of can cope well enough with this situation, I decided to write one, taking the occasion to learn Qt in the process.

Now, QFtp uses only QString's for texts (both text parameters given to cd() or get() and texts returned by listInfo or rawCommandReply).

QString are Unicode-based (namely UTF16), which is very wise, and provide several means to convert to or from other encodings. But the latter seem not to apply to QFtp.

1) All strings QFtp passes to my app are already converted to UTF16 and neither QTextCodec::codecForCStrings() or QTextCodec::codecForLocale() seem to affect it. In fact the strings I get are (almost) garbage (but see below).

2) Strings I pass to QFtp must be in UTF16 and again, QTextCodec static methods do not seem to affect them. Probably there is a way to set a specific codec for each string I create, but this would be extremely cumbersome and solve only one half of the problem anyway.

I have to deal with Chinese servers, but I assume the same would apply to Greek, Russian, Hebrew, Arabic, Tamil,... servers if they have directories or files in their native languages and use local encodings.

The Trick

Luckily, I found a work-around. QFtp assumes all those strings were natively in Latin1 (I suspected it and the src confirms it). As Latin1 maps nicely to the first 255 UTF16 points (with a 'hole'), the strings I get are the original GBK strings with each byte zero-extended to 16 bits (0x20 becomes 0x0020, 0x21 becomes 0x0021 and so on up to 0xFF which becomes 0x00FF). With QString::toLatin1() I get a faithful QByteArray representation of the original GBK string.

For UI display, this QByteArray can be considered as GBK and converted to UTF16 with an appropriate QTextCodec.

And for sending to the FTP server, it can be considered Latin1 and converted to QString with for instance QString ( const QByteArray & ba ); QFtp will convert it back to Latin1 stripping all the 0 high bytes and voilÃ .

The Questions

The whole is not very reliable, of course.

1) Is there another way? I explored the QNetwork... classes, but they seems built around HTTP much more than FTP and seem to force me to parse all the FTP server responses (which QFtp does for you and is its greatest plus).

2) How robust is relying on this undocumented 'feature'? How probable is that a new Qt version will break it?

3) I cannot imagine what would happen if the remote strings use some of the characters in the Latin1 'hole' U+0080-U+009F? With GBK (or other GBx) this is not the case, but maybe some local encoding around there does it...

4) How portable is to other platforms: I have and use Qt4 and QtCreator under Windows and I do not know if the source I have is specific for win32 or truly cross-platform (there seem to be too few conditional compilation directive to be the same source used with *nix or Mac, but this is just a feeling).

5) Any other comment or suggestion?

With many thanks in advance,

Miwarre