Namazu-devel-ja(旧)

[Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx>]

寺西です。

Yukio USUDA wrote:
> 
> > > shiftjis→uriエンコードという変換のみにしておけばこの問題は根本
> > > から解消されます。
> >
> > それは UTF-8 化でとりあえず解決する話ですよね。
> > (万能ではないにしろ、UTF-8 からは可逆変換可能ですから)
> 
> UTF-8からの変換もCP932の問題で用心しないと厄介かと思います。

あるコードページの文字を UTF-8 に変換して、それを元のコードページ
に変換した場合は、可逆変換が可能なはずです。(さすがにそれはできた
と思う。エラー文字でない限り。違ったかな。違ったとしてもほんの一部
の文字が問題になるだけのはず。)

変換の過程で別のコードページテーブルを使うと元に戻らない文字も
ありますが。

> ・namazuでの表示ルーチンの書きやすさ
> ・uriアクセスの完全さの保証
> ・filed検索でのファイル名の探しやすさ
> ・namazu以外のクライアントがNMZ.field.uriを元のuriへアクセスする方法
> 　を簡易にしておく
> といった点が選択基準だと思います。

他にも replace や日本語ドメイン対応、その他の uri の加工、
パスの処理(現状はきちんと出来ていません)をプログラムで行う場合の
プログラミングの容易さもあります。
また、インデックスを作成した環境と検索を行う環境が異なる場合への
対応も考えたいのです。(これを考えると、uriアクセスの完全さの
保障は難しい問題だということになります。)

根底にuriアクセスの完全さは放棄して、その他の利便性を優先したい
という考えがあります。(完全ではないにしても、十分に実用的な
範疇だろうとは思っています。そもそも Namazu の各機能はかなり
不完全なものですし...。)

# 個人的には、ドメイン名、ディレクトリ名、ファイル名に漢字なんて
# つかうなよ。とは思っていますが。 

> アクセス用と表示用に２つfieldを作るのはやはり冗長でしょうか

インデックスを作成した環境に依存する漢字コードをインデックスに
含むというファイルフォーマットの仕様は避けたいのです。
(そういうファイルフォーマットだと扱いがとても面倒になるからです。
処理後、別の漢字コードに変換して出力するという処理の方が
圧倒的に楽ですから。)

それをするなら別にインデックスを utf-8 化する必要は私には
ありません。
インデックスを utf-8 化しても、内部処理コードを utf-8 化しても
結局、utf-8 以外の漢字コードの処理ルーチンを書かなければならない
わけですから、現状の漢字コード泥沼状態と変わりありません。
(インデックスを読み込んだ後に utf-8 に変換して、utf-8 で処理を
行うことはできますが、それはインデックスを utf-8 化しておくのと
同じことですから、インデックスを元の漢字コードで作る必要がない
ことを意味しています。もちろん、これは処理を utf-8 で行う場合の話
です。個別にそれぞれの漢字コードの処理を書くのなら、インデックスに
作成環境の漢字コードを含めることは意味があります。)
-- 
=====================================================================
寺西 忠勝(TADAMASA TERANISHI)  yw3t-trns@xxxxxxxxxxxxxxx
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E