microdc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [microdc-devel] patch for escaped xml characters in filelist bug


From: Steffen Schulz
Subject: Re: [microdc-devel] patch for escaped xml characters in filelist bug
Date: Tue, 11 Sep 2007 13:10:12 +0200
User-agent: Mutt/1.5.9i

Chen,


On 070905 at 04:02, Yaohan Chen wrote:
> My patch only deals with listing and requesting remote files, so it shouldn't 
> affect the problem with other people getting your files. I'm not sure how to 
> fix your problem either. But I tried downloading a file with Japanese name in 
> UTF-8 using LinuxDC++, and it works fine. Do you know which clients have 
> problem downloading your files with umlauts?


Sorry for the late answer.

I'm using dc daily, with many users and diffent(mostly windows)
clients. Valknut works perfectly with them, but they all have a problem
downloading 'special' files from microdc2.

My locales are set to UTF-8, as are the filenames I create. Microdc2
has set the fs charset to UTF8.

Now I create a file with an umlaut in its name and share it. This is
what I get in microdc2' filelist and also in the filelists other
clients download from my me:

00000000  3c 46 69 6c 65 20 4e 61  6d 65 3d 22 74 c3 a4 73  |<File Name="t..s|
00000010  74 22 20 53 69 7a 65 3d  22 34 22 3e 3c 2f 46 69  |t" Size="4"></Fi|
00000020  6c 65 3e 0a                                       |le>.|

74 c3 a4 73 should be the correct utf8 representation.
A local 'ls|hexdump' confirms this.

However, when I try to download this file with a different microdc2 or
valknut, microdc2 produces a File not Available-Error. I had no luck
identifying the bug, but here is a starting point:

main.c, line 713:

msgq_get(uc->get_mq, MSGQ_INT, &id, MSGQ_INT, &type, MSGQ_STR, &remote_file, 
MSGQ_END);
local_file = resolve_upload_file(uc->info, type, remote_file, &flag, &size);

warn(_("\nXXX %s XXX %s XXX\n\n"), local_file, remote_file);
int i;
for (i=0;i<strlen(remote_file); i++)
    warn(_("%x "), remote_file[i]);


Produces this output when I request my täst-file:

XXX (null) XXX /downloads/täst XXX

2f 64 6f 77 6e 6c 6f 61 64 73 2f 74 ffffffe4 73 74


0xe4 is latin9 representation of ä, not UTF. As this works with other
clients, There must be some wrong charset conversion on remote_file
somewhere..


/steffen
-- 
No matter where you are... Everyone is always connected.
                                - Serial Experiments Lain




reply via email to

[Prev in Thread] Current Thread [Next in Thread]