Namazu-users-ja(旧)

[knok@xxxxxxxxxxxxx (NOKUBI Takatsugu)]

  興味深い情報をいろいろとありがとうございます。

  Namazu の場合、encoding と言語処理の2つの側面について考慮する必要が
あるのですが、encoding については坂本さんやもろさんに教えて下さった

文字・コードに関する覚え書き
<http://www.asahi-net.or.jp/~EZ3K-MSYM/charsets/charsets.htm>
GB 18030関連情報
<http://www.jaet.gr.jp/gb18030/index.html>

  を参考にしてみます。

  言語処理の観点からでいえば、

韓国語
* 基本的に単語単位でわかち書きされている
* 単語の間に改行が入ることがある (坂本さん)

中国語
* 単語という概念はある (三村さん)
* 読みやすさのために空白/改行をいれることもある (もろさん)

  ということだと理解しました。完全な対応を考えると、どちらの言語におい
てもやはり KAKASI/ChaSen のようなソフトウェアが必要になりそうですが、
今のところそれらしきソフトウェアをみつけられていません。

  今回の話題に関連して... 以前「第５回多言語情報処理シンポジウム」とい
うイベントにて、タイ語についての話を聞いたことがあります。

* encoding には TIS-620-0, TIS-620-1, TIS-620-2 がある
* 電子テキストで単語を分割して書く習慣はないが、レンダリングは単語単位
  で分割する必要がある
* そのために cttex, swath といった形態素解析ソフトウェアがある

  といった感じのようでした。レンダリングになると字形の合成などもっと複
雑な要素があるようでしたが、Namazu に関してはとりあえず考慮しなくて済
むのでちょっと安心です ^^;

<20010410005727.AAJBC0A82637.D59EC293@xxxxxxxxxxxxxxxxx>の記事において
hsaka@xxxxxxxxxxxxxxxxxさんは書きました。

>> 各種 EUC 以外は Shift-JIS の様に multibyte 文字の 2byte 目に ASCII
>> 部分が来ることがあります。

  今の Namazu はどうも ISO-8859-1 あたりでも扱いに問題が出ることもある
らしいので、その辺りもなんとかしたいと思っているところです。

<20010410130208.F142.MORO@xxxxxxxxxxxxxxx>の記事において
moro@xxxxxxxxxxxxxxxさんは書きました。

>> 現状はともかく、将来的にはローカルコードを一つ一つ実装していくの
>> ではなく、本体は Unicode（特に UTF-8、UTF-16）にし、インデックス
>> を作るときには JIS や Big5 や GB などのファイルを Unicode にコン
>> バートしてから処理する、というのが現実的ではないでしょうか。

  そうですね。Namazu 3 ではおそらくそういう形になると思います。可能で
あれば、i18n だけでなく m17n な処理もしたいところです。その場合、文章
のどの部分がどの言語であるのか、という情報を保持したフォーマットに限る
ことになるでしょうが...
-- 
野首 貴嗣
E-mail: knok@xxxxxxxxxxxxx