[Top][All Lists]

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

[Mldonkey-bugs] [bugs #9101] [CJK] Search with CJK characters

From: JongAm Park
Subject: [Mldonkey-bugs] [bugs #9101] [CJK] Search with CJK characters
Date: Fri, 31 Dec 2004 17:05:53 -0500
User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

This mail is an automated notification from the bugs tracker
 of the project: mldonkey, a multi-networks file-sharing client.

[bugs #9101] Latest Modifications:

Changes by: 
                JongAm Park <address@hidden>
                Fri 12/31/2004 at 21:54 (GMT)

------------------ Additional Follow-up Comments ----------------------------
I couldn't

[bugs #9101] Full Item Snapshot:

URL: <>
Project: mldonkey, a multi-networks file-sharing client
Submitted by: 0
On: Wed 05/26/2004 at 02:27

Category:  Core
Severity:  5 - Average
Item Group:  None
Resolution:  None
Privacy:  Public
Assigned to:  None
Status:  Open
Release:  2-5-16
Platform Version:  Mac OS X Jaguar
Binaries Origin:  Downloaded from third-party page
CPU type:  PowerPC

Summary:  [CJK] Search with CJK characters

Original Submission:  You know, eDonkey network is the most popular in Korea, 
and there are many files with Korean file names.

I know that search results can be different from trial to trial and from server 
to server. However the results are too different if it is compared to other 
programs like eMule. So, at least, wouldn't it be neccessary if the mldonkey 
searches files well?

Second problem is that the mldonkey doesn't seem to find files with CJK names 
well. For example, if you find files with CJK string, uh.. let's say it is 
"XAC", then the results should be something that contains XAC, but sometimes it 
is not. Some file names doesn't contain "XAC" at all.

So, could programmers or code examiners check if the search feature of the 
mldonkey treats CJK characters or other code set correctly? Or does it search 
files with CJK characters coincidently well? :)

Follow-up Comments

Date: Fri 12/31/2004 at 21:54       By: JongAm Park <JongAm>
I couldn't

Date: Sat 10/30/2004 at 17:43       By: JongAm Park <JongAm>
Yes... By the way, do you know how to do it with NSString or any other 
Cocoa/Core Foundation functions?

Date: Fri 10/29/2004 at 12:18       By: spiralvoice <spiralvoice>
"The second screen capture, search_result1_mldonkey1.jpg.jpg, shows that how 
the hash numbers are used instead of the file name."
I donĀ“t think that the filename is built with the hash value of that file, 
instead the ascii numbers are used.
To have UTF8 conversion have a look at this patch for the GTK2 GUI:

Date: Mon 10/04/2004 at 01:05       By: JongAm Park <JongAm>
If you scroll down a little, you can see like the one attached as 

What it shows is that the result contains files which are not related to the 
search keyword.

FYI, before searching, you should set the encoding method "euc-kr" with the 
Firefox or Korean( Windows, DOS ) with the Safari. Because most of the users 
are Windows users you should use the encoding method they use.

The mldonkey versions, a year ago probably, doesn't have the problem the 
serach_result_mldonkey2.jpg shows.
is it due to the object-caml language? I don't think you intentionally change 
the behaviour.

If you don't think that this issue is important, think about this. Most of the 
overnet users are Koreans. The eDonkey network is quite popular in Korea.
I think the most of population which use P2P could be Koreans among other 

Date: Mon 10/04/2004 at 00:56       By: JongAm Park <JongAm>
The second screen capture, search_result1_mldonkey1.jpg.jpg, shows that how the 
hash numbers are used instead of the file name.

FYI, the mldonkey finds and displays files with Korean names correctly with 
some files, but you have bunch of files like the one you can see in the 

Date: Mon 10/04/2004 at 00:52       By: JongAm Park <JongAm>
I think you don't understand this.

So, here I attach 3 files with which you can compare and understand what I mean.

First one is result with the eMule plus.
What you should look at is what it found, not whether the files found by the 
emule and the mldonkey are different.

Search result can be different from trial to trial.

Date: Mon 09/13/2004 at 00:21       By: JongAm Park <JongAm>
Yes. it still has the bug.

Date: Thu 08/19/2004 at 12:57       By: spiralvoice <spiralvoice>
Pre-compiled Mac cores are available here:

Date: Mon 08/16/2004 at 03:30       By: JongAm Park <JongAm>
Hello, sprialvoice.

I can't check the CVS version, because I can't compile the mldonkey on my MacOS 
X machine. The configure script throws "can't compile with gcc-something" 
error. Although I can compile C/C++/Java with the Xcode and with the gcc.


Date: Sun 08/15/2004 at 15:52       By: spiralvoice <spiralvoice>
Please check if this bug still is in current CVS version.
You should find a tarball of current CVS in files section of
this project:

CC List

CC Address                          | Comment
jongam --AT-- myrealbox --DOT-- com | 

File Attachments

Date: Mon 10/04/2004 at 01:17  Name: mldonkey2.jpg  Size: 241.05KB   By: JongAm
this is search_result1_mldonkey2.jpg, size reduced;item_file_id=1732

Date: Mon 10/04/2004 at 01:15  Name: mldonkey1.jpg  Size: 261.61KB   By: JongAm
this is search_result1_mldonkey1.jpg.jpg. size reduced;item_file_id=1731

Date: Mon 10/04/2004 at 00:52  Name: search_result_emule_plus.jpg  Size: 
209.62KB   By: JongAm;item_file_id=1730

For detailed info, follow this link:

  Message sent via/by Savannah

reply via email to

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