2006年5月26日

[SpamAssassin-JP 254] Re:SpamAssassin-3.1.1日本語対応パッチ(案、その2)

** SpamAssassin メーリングリスト **
** 注意:このメールへの返信は SpamAssassin-jp へ行きます **
久保です。

亀レスですみません。

> 完全に人柱バージョンです。

少し中身を追いかけてみました。normalize_charsetを0にすると、正規化、言語
ごとのトークナイズなどがスキップされるようになっているので、dev MLで指摘
があったスループットの懸念は問題ないと思います。

また、ロジックを細かく追いかけたわけではありませんが、実際に1ヶ月ほど動
かしてみて、nbodyテストなども問題なく動いているようですので、ロジックも
大丈夫じゃないかと思います。

ただし、これは議論が分かれるところかもしれませんが、
get_normalized_body_text_array関数の中でトークナイズしていないので、単語
が改行で分割されている場合にマッチしない、という問題がありそうです。

トークナイズの利点

o 改行で分割された単語がつながってくれる。「出<改行>会い」というケースで
も見逃さなくなる。

o (辞書に依存する度合いが高いが)複数単語が連なっていることによって間違っ
たマッチを起こす可能性が減る

たとえば「人情」という単語を検出したい場合、トークナイズしなければ「個
人情報」もマッチしてしまうが、トークナイズすれば「個人<スペース>情報」
となるためにマッチしなくなる(辞書に「個人情報」が登録されていないなら
ば)。

トークナイズの欠点

o 使うトークナイザや辞書によってことなったわかち書きになることがあり、
nbodyの書き方がそれらに依存することになってしまう。とくに辞書に登録さ
れていないカタカナ用語などは、実際にわかち書きさせてみないとどうなるか
わからない。

 ユーザ会版のルールセットを共同制作する場合などに、トークナイザと辞書を
指定しなければならなくなります。

dev MLでも議論になった点なのですが、私は意図しないマッチを減らすために、
トークナイズする方が望ましいと思っています。

トークナイズしないテキストに対するテスト(nbody)、トークナイズしたテキス
トに対するテスト(たとえばntbody)という2とおりのテストを用意する、という
対処もありえると思いますが、そのことの是非も含めて検討が必要ですね。

--
----------------------------------------------------------------------
久保 元治 (株)サードウェア
Motoharu Kubo 274-0815 千葉県船橋市西習志野3-39-8
mkubo@xxxxx URL: http://www.3ware.co.jp/
Phone: 047-496-3341 Fax: 047-496-3370
携帯: 090-6171-5545
★弊社からのメールはZ-Linuxメールフィルタで全数検査しています★
★ ブログを始めました http://blogs.itmedia.co.jp/ossway/
--
SpamAssassin メーリングリスト
http://mm.apache.jp/mailman/listinfo/spamassassin-jp

投稿者 xml-rpc : 2006年5月26日 14:56
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/40044
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。