[Mldonkey-bugs] [bug #9102] [CJK] File names in Downloads and search results Web UI page

[JongAm Park]

Follow-up Comment #20, bug #9102 (project mldonkey):

To Amorphous..

Your ideas :

-everything internal to mldonkey should use UTF-8
-add an option character_encoding_default with default UTF-8
-when a peer connects try to determine what encoding he uses and convert it
to/from UTF-8, if we can't determine it use character_encoding_default
-when searching use the option character_encoding_default to determine the
encoding we use (i assume here that the servers don't care about encoding)

are very good. However, we should be aware of this.
Although the eDonkey project itself is moving to Unicode based approach
nowadays, there are many eDonkey servers and clients which don't use
Unicodes. I believe that if eDonkey itself moves to the Unicode, then most
users will switch to the newer approach whether they like or not.
However there can be some servers/clients which don't use unicode in future.
We may be able to disregard those safely. Because it is an open source
project, and thus it is not as risky as commercial programs.
However, whatever you take, I think this should be discussed with guys at
eDonkey network people.
Actually, mldonkey is not only for eDonkey. You may need to discuss about
this issue with Kazza, Soulseek, and gnutella.(and so on. )
Nowadays there are Unicode gnutella clients. So, I think they are also moving
to the Unicode base.

Or it may be better to add "encoder specifier for each file name" to the
protocol itself. Because different servers and clients may have different
encoding scheme.
Or.. better approach, IMHO, is that the encoding method for the network
itself should be standardized on the Unicode.

What do you think about this?

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?func=detailitem&item_id=9102>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/