Naoya Murakami
visio****@gmail*****
2014年 1月 29日 (水) 12:32:25 JST
お世話になっております。村上です。 >>> あぁ、groonga-normalizer-mysqlに入っているノーマライザーは部 > >>> 分的にしかノーマライザーの機能を実装していないからかもしれま > >>> せん。ノーマライズ前は何バイト目にあった文字か、という情報を > >>> 入れれば動きそうな気が。。。 > >>> （空白を削除するとか、いわゆる全角文字を半角文字に正規化した > >>> りすると何バイト目かというのがずれるので、それを補正するため > >>> の情報です。） > >>> > >> > >> ご説明ありがとうございます！ > >> おかげでgrn_stringのchecksが何者か把握することができました。 > > す、すみません。。。説明が間違っていました。。。 > 「ノーマライズ前は前の文字から相対的に何バイト先にあったか」 > でした。（これでも説明がわかりにくい気がしますが。。。） > やはりそうですよね。 デバッグログを適当に埋め込んでNormalizerAutoで入れられるchecksを 見てたら、そうだろうなぁと思って対応してました。 ちなみに、normalizeコマンドでchecksが見れるようになったのですね！ これでchecksのテストも簡単にできていいですね。 > 今月のリリースには間に合わなかったのですが、 > groonga-normalizer-mysqlのmasterでは↑の機能に対応しておきま > した。groonga-function-snippet_tritonnに入っているテストも動 > くようになっています。 > ありがとうございます！ これで、一通り、スニペットにまつわる課題を対処できました。 お忙しい中、迅速に要望に対応いただきありがとうございました。 特に問題というわけではないのですが、NormalizerAutoと groonga-nomalizer-mysqlの動きを比較していて、少し気になる点が ありました。 groonga-nomalizer-mysqlのノーマライザでは、normalizedの末尾に NULL文字(\0)が入りません。 たとえば、「今日は雨」という文字列をgrn_string_get_normalizedし、 %sで文字列を出力すると、「今日は雨?」という値が出力されます。 一方、utf8_normalizeでは、normalizedの末尾にNULL文字(\0)が 入ります。 たとえば、「今日は雨」という文字列をgrn_string_get_normalizedし、 %sで文字列を出力すると、「今日は雨」という値が出力されます。 MySQL準拠のノーマライザでは、これは想定通りでよかったですか？ lengthがとれるので、トークナイズやスニペット処理には、影響がなく 特に問題ないかもしれません。 以上、よろしくお願いします。
