Files downloaded not UTF-8

[Pablo Quirós]

The name of the files downloaded have weird characters where there should be accents or spanish-specific characters (ñ).
I think it doesn't code them in UTF-8.

[Sebastien Bacher (seb128)]

thanks for your bug. what version of ubuntu do you use?

[Pablo Quirós (polmac1985)]

I use Ubuntu 6.06 (Dapper), and the version of amule is 2.1.0

[Aikurn (aikurn-deactivatedaccount)]

I've seen this bug too and it's quite annoying. The filename is displayed correctly in amule's gui though.

[Emilio Pozuelo Monfort (pochu)]

Do you have the same problem with amule 2.1.3?

[usr (usrlp-deactivatedaccount-deactivatedaccount)]

I have the problem too, but the bug is in CD/DVD's was bor in and with files of Windows partitions too.

[usr (usrlp-deactivatedaccount-deactivatedaccount)]

I have the problem too, but the bug is too into the CD/DVDs burned and with files of Windows partitions.

[usr (usrlp-deactivatedaccount-deactivatedaccount)]

And when I send web formularies in Konqueror, the sent formularies appears with "?" character in the post message.

When I am editing any txt file with the text editor (Kate), the characteres are reemplzaed with � characters.

[usr (usrlp-deactivatedaccount-deactivatedaccount)]

Sorry:
the characteres are changed with � characters.

Excuse my bad English.

[Pablo Quirós (polmac1985)]

Yes, just tried it and still have the same problem in aMule 2.1.3

@usr: you can solve your problems with files in Windows partitions adding the flag utf-8 under options in /etc/fstab

[Emilio Pozuelo Monfort (pochu)]

Pablo:

Do you also have character problems with other applications apart amule, as usr has?

I think this can be a character encoding problem, rather than an amule bug.

Regards
Pochu

[Pablo Quirós (polmac1985)]

No, I don't. For me, aMule downloaded files is the only character problem in the system, as far as I know.

[Emilio Pozuelo Monfort (pochu)]

I can confirm this bug in an Edgy machine with amule 2.1.3

The problem may be that amule is creating the files as iso, instead of utf-8.

I'll try to talk to the amule developers to see if this is the problem, and how to solve it.

Regards
Pochu

[Emilio Pozuelo Monfort (pochu)]

The problem is that amule saves the files as iso8859-1.

I'm building amule with utf-8 support, to see if this works.

Regards
Pochu

[Emilio Pozuelo Monfort (pochu)]

This patch should fix the problem

[Emilio Pozuelo Monfort (pochu)]

Reported upstream:

http://forum.amule.org/index.php?topic=12335.0

[usr (usrlp-deactivatedaccount-deactivatedaccount)]

The error is not only in amule. It is in the system.

[Emilio Pozuelo Monfort (pochu)]

No, the problem is in amule. And that patch fixes it (though that's not the best way to fix it, so I'm talking to the upstream developers to see how they are going to implement it).

That issue you have is different, probably because you haven't configured kate as utf-8. But the problem isn't in the system.

[Emilio Pozuelo Monfort (pochu)]

There is a patch which adds charset support to amule:
http://forum.amule.org/index.php?topic=12335

You can try it (with a current cvs snapshot) and give some feedback :)

It hasn't been applied yet, 'couse it needs more testing, but it will probably be applied for 2.2.0 (Feisty+1).

Best regards
Emilio

[Emilio Pozuelo Monfort (pochu)]

The patch is now applied. We can close this bug once we have 2.2.0 in the repos.

[Emilio Pozuelo Monfort (pochu)]

Please, feel free to test it, to see that everything works fine (and if you do it, don't forget to tell us!)

[usr (usrlp-deactivatedaccount-deactivatedaccount)]

" No, the problem is in amule. And that patch fixes it (though that's not the best way to fix it, so I'm talking to the upstream developers to see how they are going to implement it).
That issue you have is different, probably because you haven't configured kate as utf-8. But the problem isn't in the system."

The problem is kate, and in Konqueror explorer and browser, and in Ark (with compressed files in Windows), File-roller, etc.
I tried "dpkg-reconfigure locales" and "aptitude reinstall locales", but the problem persists.

¿Any solution?

P.S: The problem is in Debian too. But not in RPM's based distributions.

[usr (usrlp-deactivatedaccount-deactivatedaccount)]

I think that my bug is diferent (thank you Benjamín). For this, I moved my bug to https://bugs.beta.launchpad.net/ubuntu/+bug/98993

[Benjamín Valero Espinosa (benjavalero)]

Emilio, it would be great to fix this bug in 2.1.3 too, at least in Gutsy, would it be possible?

[Emilio Pozuelo Monfort (pochu)]

2.2.0 will be released soon, probably in less than a month, so it'll make Gutsy :)

[Barry deFreese (bddebian)]

Why is this marked fixed committed when one hasn't been? 2.2.0 is still also not in Debian nor Ubuntu. Thanks.

[usr (usrlp-deactivatedaccount-deactivatedaccount)]

The same problem in Kubuntu 6.06, 6.10, 7.04 and 7.10.

aMule's bug-tracker report: http://bugs.amule.org/view.php?id=938

[Launchpad Janitor (janitor)]

This bug was fixed in the package amule - 2.2.0~svn20080218-0ubuntu1

---------------
amule (2.2.0~svn20080218-0ubuntu1) hardy; urgency=low

  * New svn snapshot from 20080218 tarball, renamed debian/ to
    debian-upstream/.
    FeatureFreeze exception: LP: #192156.
    The 2.2.0 isn't released yet because of build failures in MacOS X,
    but is stable enough and recommended by upstream.
    LP: #40238, #112745, #65496, #123695, #192781.

  * debian/patches/cas_configfile.c_good_default_paths.diff:
    - Updated for the new release.
  * debian/patches/wx-2.8.diff,
    debian/patches/configure_proper_libpng_detection.diff,
    debian/patches/for_upstream-manpage_typos.diff
    - Removed, fixed upstream.
  * debian/patches/nodes-url.diff:
    - Removed, as upstream uses now a different server list.
  * debian/patches/series:
    - Updated accordingly.
  * debian/control:
    - Require libcrypto++-dev >= 5.5.2-1, as aMule now checks for crypopp
      instead of crypto++, and 5.5.2-1 added the necessary symlinks.
      Otherwise aMule FTBFS.
    - Build-depend on libgeoip-dev to get geoip support.
    - Require debhelper >= 5.0.51 to have dh_icons.
    - Moved homepage to the Homepage field.
    - Updated Standards-Version to 3.7.3. No changes needed.
  * debian/mans/amulegui.1:
    - Removed, as it's shipped upstream now.
  * debian/amule-utils-gui.manpages:
    - Ship amulegui.*1 manpages from upstream, and stop shipping
      debian/mans/amulegui.1
  * debian/rules:
    - Stop manually installing amulegui.desktop and amulegui.xpm.
      It's now done upstream.
    - No need to symlink debian/amule.xpm to debian/amule-32.xpm and
      remove it in clean. Let's rename amule-32.xpm to amule.xpm instead.
    - Build with geoip support.
    - Call dh_icons and dh_desktop.
    - Explicitly install debian/amule.xpm, as upstream's amule.xpm isn't
      menu-policy compliant (32x32 vs 128x128).
  * debian/amule-32.xpm, debian/amule.xpm:
    - Renamed debian/amule-32.xpm as debian/amule.xpm.
  * debian/amulegui.desktop:
    - Removed, it's included upstream now.

 -- Emilio Pozuelo Monfort <email address hidden> Mon, 18 Feb 2008 19:43:28 +0100

[Jose M. Albarrán (yomismo-jmalbarran)]

Hi. I'm using Ubuntu 8.04 and 20080218 SVN version.

The bug now is worse. Now, all files with special spanish character are saved with the name "Unknown"

[Benjamín Valero Espinosa (benjavalero)]

I am also using Ubuntu 8.04 and the version of the official repositories. I have started a download, meanwhile I have changed the name of the file to "áéíóúñ.rar" and I have waited it to download. Then I have gone to the download folder and the name of the downloaded file is right, respecting the Spanish characters. Do you download your files in an ext3 partition or in some other file system?

[Jose M. Albarrán (yomismo-jmalbarran)]

I forget to report I'm using amuled+amulegui

My file system is ext3, with Ubuntu 8.04 updated until now.

I think (I'm not sure) that problem begins when the original file has the special characters.

My normal secuence (I have several Unknow problem in my disk) is

a) I begins to download the file with special characters (the ed2k link has special characters)
b) I touch the name, but keeping the special character (v.g, I change "House - Un puño de hierro" to "04X12 House - Un puño de hierro". I'm not sure if changing the name when the download already begun has any influence, but is my normal sequence.
c) The file ends with "Unknown" name

Is there any amuled log file I can check?

[Benjamín Valero Espinosa (benjavalero)]

Mmm, perhaps you should open a new bug related to the package 'amule-daemon', saying that is related to this bug, and let this one closed and fixed.

[Emilio Pozuelo Monfort (pochu)]

Could you check if this happens with amule, and not amuled? This may be specific
to it.

[Jose M. Albarrán (yomismo-jmalbarran)]

I'm using ext3-utf8

I'll check with amule directly and I'll report a new bug or retry this. Thanks!

[Jose M. Albarrán (yomismo-jmalbarran)]

Tested: In amule works fine. It only fails with amuled.

I'll open another bug. Thank you very much for your help and patience.

[Tian Bai (tian.hack)]

Has this bug been fixed please? It seems to me that both 'amule' and 'amuled' (2.2.2 using wxGTK2 v2.8.8) shipped with Ubuntu 8.10 have the same problem that Chinese filenames (encoded in UTF-8) embeded in ed2k links become weird characters. I ran a simple test and found: only when a link is clicked locally (so added to the local 'amule' or 'amuled' via 'ed2k') the Chinese filename is correct. If I copy the link location and add it manually to 'amule' locally, the Chinese filenames are incorrect. If a link is clicked remotely (so added to the remote 'amule' or 'amuled' via 'amulecmd') the Chinese filename is incorrect.

So, to me, this seems like that only 'ed2k' handles UTF-8 filenames (the ones embeded in the ed2k links) correctly, while 'amulecmd' and 'amule' cannot fail to handle UTF-8. Would anyone shed some light on this? Thanks!

[Jose M. Albarrán (yomismo-jmalbarran)]

Hi, Tian

I think we are maybe talking about two different bugs. This one is about the moment the file is created. You add the file and see the correct file name in traffic windows, but in the moment the download ends, it create the file incorrectly (always speaking about spanish utf-8 characters 'ñ'). Is this your problem? Or, maybe, your problem is in the moment the file is added? Do you see the file name correctly in traffic window?

[Tian Bai (tian.hack)]

Joe, thanks for pointing this out. You are right that my issue is that the display is incorrect since it's added into the 'transfer' view.

Let me try to find if there is an existing bug for my problem, and if not, I'll open another separate one. The problem seems quite common according to the complaints among Chinese users.