Namazu-devel-ja(旧)

[Yoshinori Takesako <takesako@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

竹迫です．

From: Rei FURUKAWA <furukawa@xxxxxxxxxxxx>
Subject: [namazu-devel-ja] Re: Namazu 2.0.6rc2 for Win32 Test Release
Date: Sat, 14 Jul 2001 23:52:01 +0900
> > あと、以下のスレッドの話のその後はどうなりましたでしょうか？
> > ・[namazu-users-ja] Re: mknmz のメタタグの扱い
> >   http://www.namazu.org/ml/namazu-users-ja/msg01311.html
> 
> よく考えてみると、結構根の深い話ですね。
> 
> たとえ nkf に手を入れて -Z3 オプションを作ったとしても、現状
> ではまずい点があります。というのも、現在の処理では、euc への
> 変換をしているのは、toeuc というサブルーチンで、これは mknmz
> で呼ばれていて、html 以外の文書にも効いてしまいます。

確かに filter/html.pl では html::decode_entity() を呼んで
きちんとデコードしているから大丈夫だけど，他のフィルタでは
そのことを考慮していませんから，現状ではまずいですね．

> ちゃんとやろうとすると、euc への変換はフィルタ側に移すか、フ
> ィルタモジュールから nkf のオプションを指定できるようにしない
> といけなくなります。

将来的には，フィルタモジュールから nkf のオプション指定が
できるようになると良いと思います．

というのも，現状の codeconv::toeuc() では，対象文書の日本語コードを
nkf の自動判別にまかせていますが，対象文書の charset が事前にわかっ
ている場合は，入力文字コードを明示的に指定しできると，ちょっと安心
かもしれません．

# 少ない確率ですが，Sfhit_JIS と EUC_JP のコードが重なってしまって
# いる文字だけから構成される文書に対しては自動判定できないはずです．

あと，namazu の多言語化を考えた場合，対象文書毎に charset を取得して，
その情報を元に内部エンコーディングに変換しないと，うまくいかないと
思います．個人的には，現状の namazu 2.x で多言語文書の対応は難しいと
考えているので，Namazu 3 での課題にするのが良いかと思われます．

> 河野さんに、patch と、「バグ修正だけでもしたほうが」というメ
> ールを出して、河野さんから「了解」との返事をいただいたのが去
> 年の 12 月。ですが、現在まで修正版は出ていないようです。こう
> いうのって、催促するのも何か違う気がして…

unicode 対応するらしい nkf 2.0 の開発動向も気になるところです．(^^;

--
  広島市立大学 情報科学部 情報機械システム工学科 知能ロボット講座
     竹迫 良範 <takesako@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>