Namazu-devel-ja(旧)

[Yukio USUDA <m6694ha392t@xxxxxxxxxxxxxxx>]

Tadamasa Teranishi wrote:

> > UTF-8からの変換もCP932の問題で用心しないと厄介かと思います。
> 
> あるコードページの文字を UTF-8 に変換して、それを元のコードページ
> に変換した場合は、可逆変換が可能なはずです。(さすがにそれはできた
> と思う。エラー文字でない限り。違ったかな。違ったとしてもほんの一部
> の文字が問題になるだけのはず。)
> 
○数字など絶対問題になることが分っていて割と使われそうなものがあります。

> 
> > ・namazuでの表示ルーチンの書きやすさ
> > ・uriアクセスの完全さの保証
> > ・filed検索でのファイル名の探しやすさ
> > ・namazu以外のクライアントがNMZ.field.uriを元のuriへアクセスする方法
> > 　を簡易にしておく
> > といった点が選択基準だと思います。
> 
> 他にも replace や日本語ドメイン対応、その他の uri の加工、
> パスの処理(現状はきちんと出来ていません)をプログラムで行う場合の
> プログラミングの容易さもあります。
> また、インデックスを作成した環境と検索を行う環境が異なる場合への
> 対応も考えたいのです。(これを考えると、uriアクセスの完全さの
> 保障は難しい問題だということになります。)
> 
> 根底にuriアクセスの完全さは放棄して、その他の利便性を優先したい
> という考えがあります。(完全ではないにしても、十分に実用的な
> 範疇だろうとは思っています。そもそも Namazu の各機能はかなり
> 不完全なものですし...。)
> 
私の考えている優先順位も先に並べた項目のとおりです。
まず、namazuの実装をシンプルに保つところを優先すべきと思っています。
（-Uオプションは読めるようになるけどアクセスできなくなるなど
利用者の目的と動作がずれているのでやめたい）


> # 個人的には、ドメイン名、ディレクトリ名、ファイル名に漢字なんて
> # つかうなよ。とは思っていますが。 
> 
私もファイル名の区切りにスペースが入っているのは扱いにくいと思うし
smb共有名が日本語だとsambaからマウントするのが困難なので
やめて欲しいと思いますが、そういう環境で生活しているので
対応できる方法を探しておきたいものです。

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

私はアクセス用のfieldは漢字コードですらなくバイナリ列だと考えようと
していました。
uriアクセスの完全性をおさえておけば、表示用のfieldは自由にでき、元の
文字コードに直す必要もありません。

考えられる課題は抽出しましたし、
私が勘違いしてイメージのみで話をしているとよくないですので
NMZ.field.uriの仕様については実装しなおす際の判断におまかせします。

臼田幸生