Namazu-devel-ja(旧)

[Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx>]

寺西です。

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

Win32版 iconv で丸数字の可逆変換テストをしてみましたが、ちゃんと
元に戻っていました。(さて、何の文字が問題なんでしょう。)

Windows NT 系ファイルサーバは UNICODE で管理していて、クライアント
とのやり取りの間に Shift_JIS に変換されるはずです。
Windows 系では UNICODE <-> Shift_JIS 変換は日常的に行われています。

これで問題が起きないのなら、何らかの方法(Win32で使っている
変換テーブルを用意するなり)で対処可能な気はします。

> 私の考えている優先順位も先に並べた項目のとおりです。
> まず、namazuの実装をシンプルに保つところを優先すべきと思っています。
> （-Uオプションは読めるようになるけどアクセスできなくなるなど
> 利用者の目的と動作がずれているのでやめたい）

-U オプションは対処療法的に実装されたものですから、これは廃止すべき
でしょう。
 
> 私はアクセス用のfieldは漢字コードですらなくバイナリ列だと考えようと
> していました。
> uriアクセスの完全性をおさえておけば、表示用のfieldは自由にでき、元の
> 文字コードに直す必要もありません。

が、uri は加工処理の対象のため、表示用としてインデックス作成時
に決定できるものではありません。
結局何らかの加工を行う(行わないで使うこともありますが)ことになり
ますので、元の文字コードでいろいろ処理を行わなければならなく
なってしまい、それがnamazuの実装を複雑化させることになります。
-- 
=====================================================================
寺西 忠勝(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