Namazu-devel-ja(旧)

[Yukio USUDA <m6694ha392t@xxxxxxxxxxxxxxx>]

臼田です。

元になっていた話題が別なので切り離しました。

Tadamasa Teranishi wrote:
> 私が eucJP に統一していないので... という辺りの話は忘れて
> いただいて結構です。問題は eucJP に統一していないことでは
> ありませんでした。
略
> 異常なファイル名のものをリンクで開けなくても、それは仕方ないと
> いえますし、ここは uri でも削除する方がよろしいかな。

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

１．ファイル名をsjisからeucに変換
２．-Uオプションをつけない場合はさらにuriエンコード
という処理をしていますが

"な.txt"というファイルがあるとすると、"な"の字の部分は下記のようにな
ります。
----------------------------------------------
ファイルシステム :　　NMZ.field.uri 
（NMZ.ｒも同じ） :----------------------------
   　            : 　-U なし   　:  -U 付
----------------------------------------------
  0x82 0xC8      : 　"%A4%CA" 　 : 0xA4 0xCA 
----------------------------------------------
"-U"付の場合はcgiで生成するページの文字コードとの整合をとる必要があ
るのでeucにしているとして

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

MS-Winローカルでインデックスを作り、MS-Win上でhttpサーバーを動かして
いると"%A4%CA"では表示が読みにくいだけでなく、アクセスもできないので
はないかと思うのです。

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

でもFreeBSD機にSamba（ファイルシステムeuc）経由でファイルを
送ってみてWebブラウザからuriエンコードしたファイル名でアクセス
してみたところ
Apache1.3.12の反応は
%A4%CA.txt(EUC)　　　　○
%82%C8.txt（SJIS）　　 ×
%e3%81%aa.txt（utf-8） ×
となりました。
httpdのlogにも
 "GET /%A4%CA.txt HTTP/1.1" 200 0
 "GET /%82%C8.txt HTTP/1.1" 404 281
 "GET /%e3%81%aa.txt HTTP/1.1" 404 282
と想像していた通りの動作をしているので
Windowsの２例のhttpサーバーではhttpサーバー側で文字コードを判断して
変換して対応しているようだがhttpサーバによってはファイルシステム上の
文字コードをeucにせずそのままuriエンコードしておいたほうがよいのでは
と考えました。

だいぶ長くなりましたが、eucにせずにuriエンコードするほうがよいのでは？
ということです。

臼田幸生