Namazu-devel-ja(旧)

[Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx>]

寺西です。

Yukio USUDA wrote:
> 
> NMZ.field.uriの話題になにかコメントしようと思い、
> ヒントになるかなと現状のmknmzがファイルシステムsjis（Windows環境）
> の時に２バイト文字のuriエンコードをする動作を見ていて疑問に思いま
> した。

えっとですね。これは UNIX を基本で、Win32 環境はそこにちょっと
手を加えて動かすようにしたという経緯があるからです。

> "-U"付の場合はcgiで生成するページの文字コードとの整合をとる必要があ
> るのでeucにしているとして
> 
> "-U"なしのときのNMZ.field.uriは"%82%C8"となるほうがよいのではないか
> と思うのですがどうでしょうか？

Win32 版では "-U"なしでは漢字の uri にアクセスできないのです。
なぜできないのかは臼田さんが指摘しているようにコードが違うからです。

そんなわけで、"-U"付きで mknmz を実行しましょうというのが、Win32 向け
の回答になっています。

> 現状の"-U"なしでのNMZ.field.uriが正しく機能するのは
> 　MS-Winローカルでインデックスを作っておきファイルシステムにEUCを用
> 　いているhttpサーバーにファイルとインデックスを転送した場合
> というケースかと思います。

ある特殊な環境では使えますが、普通は "-U"付きは使えないと思って
ください。

> MS-Win上でhttpサーバ(04Webserver, AN HTTPD　という２種を試してみました)
> を動かしてみたところ
> %A4%CA.txt(EUC)　%82%C8.txt（SJIS）　%e3%81%aa.txt（utf-8）とどの文字
> コードをuriエンコードしたものでアクセスしてもちゃんと表示できました。
> httpサーバのlogには"な.txt"へのアクセスしか残っていないのでブラウザ
> かサーバで判断して変換しているようです。すごいですね。

全部が全部ってことはないと思いますよ。まじめに調べたことはないけど。
Webブラウザ依存、Webサーバ依存であることは確かだと思います。
 
> と想像していた通りの動作をしているので
> Windowsの２例のhttpサーバーではhttpサーバー側で文字コードを判断して
> 変換して対応しているようだがhttpサーバによってはファイルシステム上の
> 文字コードをeucにせずそのままuriエンコードしておいたほうがよいのでは
> と考えました。

というような問題を回避するため、すべてデコードした eucJP で記録して、 
表示の時はそのまま(必要に応じて漢字コードを変換)、リンク先はサーバの
漢字コードに変換後、uriエンコードしたものを使うということに
しましょう。と、いう話をしているわけです。

特殊な文字に関しては変換して、逆変換しても戻らなかったりするので、
問題がないわけではないのですが、これだと、インデックスを作成した
環境と、実際にインデックスを使って検索する環境が異なっても、
同じ動作することになります。
現状は Win32 で作ったインデックスを Linux に持ってきてもダメなん
ですよ。
-- 
=====================================================================
寺西 忠勝(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