Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[phoenix]

pochu,

Today's cvs tarball has the last patch. Please report if your issue is gone.

Cheers!

[pochu]

Hi phoenix

I've built today's tarball, and have downloaded three files with special characters. It hasn't worked.
I attach a screenshot of ~/.aMule/Incoming/ . One image is better than a thousand words

I have nothing more to say atm, will try to investigate this further.

Regards
Pochu

[phoenix]

Hi Pochu,

This image you submitted is from a system file browser or something like this, right? This is not from aMule.

The situation is the following: if the file name you have in your directory uses a character set that is not the same as in your system. Your system uses UTF-8. It will always read garbage when you have, for instance, ISO-8859-1file names, which seems to be the case.

Well, we have to find a reasonable policy here. At the present time, aMule works like this:

1) Converting from multibyte to UNICODE:
- Assume that input name is ISO-8859-1 and try to convert it to UNICODE. If this fails, then try to convert from UTF-8 to UNICODE.

2) Converting from UNICODE to multibyte:
- Try to convert UNICODE input to ISO-8859-1. If this fails, convert it to UTF-8.

I have been thinking, and maybe step 1 is wrong. ISO-8859-1 to UNICODE must never fail, while UTF-8 to UNICODE can fail. Maybe the right order is the opposite. Still there could be a situation where the file name is ISO-8859-1 but by chance it was a valid UTF-8 sequence.

What we can experiment with is not use ISO-8859-1file names and using the system encoding instead.

[phoenix]

Tomorrow CVS code will have a different behaviour for #1 above. Now we first try UTF-8 when converting to UNICODE. If this fails, then we try ISO-8859-1.

Cheers!

[pochu]

Hi phoenix

Firstly, sorry for not replying to the previous message, I forgot to do it!

Yes, that screenshot is the gnome file manager, nautilus. As you can see, that's the amule Incoming folder, and those are some files I downloaded to test your changes. But it didn't worked.

I'll try tomorrow's tarball, let's see if we can finalize this! (/me testing, you coding )

Best regards
Pochu

[phoenix]

Hi Pochu,

It is not a matter of working or not working. Maybe you did not understand. It cannot work always, that is the problem.

We could add an option to use the system encoding instead of ISO-8859-1... I don't know, I would like to hear other people's oppinion on that.

Cheers!

[pochu]

Hi phoenix:

With today's tarball, it still fails with the "ñ" in the files. In the Incoming folder, that char is displayed as "?".

Maybe that option of using the system encoding will be great

I've also seen that the next wx release will have UTF-8 support (http://www.wxwidgets.org/wiki/index.php/Development/UTF8)

Maybe with that this will be easier?

[Kry]

What, you mean along with the fact that they broke compilation?

[pochu]

Kry: the compilation fails with wx2.9, but not with 2.8.x (I've built now against 2.8.4-rc1).

This also failed with previous amule cvs and wx2.8.x (2.8.3.0, e.g.)

[Kry]

UTF8 is afaik only in 2.9

[pochu]

In wx yes, this can be solved in amule

[Kry]

?

[pochu]

I mean the charset issue

Phoenix got it solved some time ago (with the first or the second patch) but it shouldn't be the first way to do it, and now it doesn't work.

Sorry if I misunderstood your words!

[phoenix]

Pochu,

I have never got it "solved" as you say. If you want to try a system encoding, please, change this line:
In file src/libs/common/ConvAmule.h, line53:
   ConvAmuleBrokenFileNames aMuleConvBrokenFileNames(wxT("ISO-8859-1"));
Change to:
   ConvAmuleBrokenFileNames aMuleConvBrokenFileNames(wxConvLocal);

That is what Kry said to you in the first place. We might add this to the preferences or even better, start checking the LANG environment variable if this becomes an issue.

Cheers!

[wuischke]

Maybe a related issue: http://forum.amule.org/index.php?topic=12542.0