[Namazu-devel-ja 1181] Re: 文字 N-gram ぽい実験 (Re: フレーズ検索って N-gram ですよね

[Tadamasa Teranishi]

寺西です。

NOKUBI Takatsugu wrote:
> 
> At Thu, 24 Aug 2006 00:24:20 +0900,
> Yukio USUDA wrote:
> > 後者は Encode::GUESS が tests/data/ja-wakati/builtin-m-
> > test.txt の文字コード判定
> > に失敗していることが原因のようですが、いまのところ対処方法を思い
> > つきません。
> 
>   とりあえずは#18としてTracに登録しておきました。
> 
>   Encode::GUESSで失敗するのはある意味Perl側の問題ですから、難しいです
> ね...

失敗するとは、誤認するのか、エラーになるのか、それ以外の何かが
起こるのかどれなのでしょう。

Encode::Guess だと複数返すことがあるのですが、その時の処理ができて
いないだけなのでは?

>   最近はTextCatというn-gramのデータベースに基づきエンコーディング、言
> 語の判定をする手法があり、その実装も何種類かあるようなので、それが利用
> できないかと考えています。
> 
> TextCat
> http://grid.let.rug.nl/~vannoord/TextCat/Demo/textcat.html

面白そうだったので、試してみましたが、UTF-8 で漢字を書くと
誤認するようです。

LIST OF LANGUAGES currently supported に UTF-8 とか、ISO-2022-JP
とかないので、仕方ないですけど。これはデータベースに UTF-8 のデータ
を入れていないだけなのでしょうか?

それと大きなデータベースが必要になりはしないかと心配します。


で、Encode::Guess で複数返した場合には、namazu 側でやっている
みたいに、候補のエンコーディングで変換した後の文字数を比較して
判定すれば、大丈夫なのではないでしょうか。*1
# これって、n-gram データベースじゃないけど、文字 n-gram 的な
# 発想かな? 出現頻度などの統計情報は利用しないけど。

もっとも、ISO-8859-* の判定とかは n-gramのデータベース等の統計情報
がないと判定不能ではありますが、今のところ自動判定で必要なのは
ISO-2022-JP, Shift_JIS, EUC-JP, UTF-8 と日本語だけです。
(ISO-8859-* の入力はサポート外ですし、今後も予定がありません。)

*1 namazu 側の判定は元々 query 用だったので、あのようなルーチン
となっています。入力テキストが巨大になると効率が悪いので改良の
余地はあります。例えば最初から1KBの文字列に限定するとか。
-- 
=====================================================================
寺西 忠勝(TADAMASA TERANISHI)  yw3t-trns ＠ asahi-net.or.jp
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E