On Mon, 13 Dec 2004 15:20:47 +0100 Christian Biere <[EMAIL PROTECTED]> wrote:
> I don't think gtk-gnutella emits (many) false-positives at the moment. > At least, I don't witness such behaviour in the wild from gtk-gnutella. I learned the meaning of 'false-positive' listening the beep sound... > There's really a problem which doesn't concern gtk-gnutella only but also > others. I copy&pasted a search string from the search monitor to start > a new search. This string consisted of "06" some Japanese characters > followed by ".mp3". Soon, I got about 200 hits which had only "06" and > ".mp3" in common with the search string. Obviously, the remote servents > (gtk-gnutella, Morpheus, Trusty Files, etc. - no LimeWire or Bearshare > so far) discarded the Japanese characters. > > I think gtk-gnutella's matching code needs some overhaul because it > looks very ASCII and latin optimized. You mentioned all I want :-) then as far as incoming search results from which Shareaza are concerned, the main problem that is causing a certain conversion error comes from here. To make sure, I've downloaded a source of Shareaza 2.1 and I saw the encoding 'CP-UTF8'. If my memory is correct, Windows has Unicode support is from 98 or NT, so if someone used a this servent on Windows95 and shared ShiftJIS encoded files, it might bring an above-mentioned. Or it might be the 'CP-UTF8' I don't know what kind of UTF8 (little endian only?) this is, umm I'm uncertain... Thank you. -- Daichi ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
