Christian Biere wrote: > Daichi Kawahata wrote: > > However where outgoing query is concerned, gtkg with GTK2 and ICU is > > dropping my search query (some Japanese, Chinese, Russian) automatically > > with '(WARNING): dropping invalid local query ""'. > For example, if I search for the Kanji that is pronounced "no" (looks like > the traffic sign for "no parking") I get the above error message.
I meant Hiragana not Kanji, of course. ;) > There's something wrong in compact_query() and/or compact_query_utf8(). The latter ate characters sometimes. This should be fixed in CVS now. > > Ah, my problem might be around here. If there is a feature which can > > confirm filenames of mine currently shared (I know there is number of > > files, its size and LimeWire have all these feature), or emits > > notification when I'm trying to share a file with invalid encoded its > > filename, the problem caused by encoding is less than now for those who > > are annoying against bogus strings same as me, > > yes, applied only to outgoing of hits on local DB in the gtkg though... > 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. 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. -- Christian
pgpQEczLPL9Oi.pgp
Description: PGP signature
