Namazu-devel-ja(旧)

[Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx>]

寺西です。

Youichi Iwakiri wrote:
> 
> 問題点1
>   mknmzは、マルチバイト文字の使われているパス名/ファイル名を
> Windows,OS/2であればsjisとみなしeucに変換してからuriエンコードを
> 行っている。

パス区切り記号を解析する部分ではマルチバイト文字を考慮していない
部分もあったりするので、パスについてはきちんとマルチバイト文字に
対応しているわけでは残念ながらありません。
# euc-jp なら問題ないけど。

また、namazu 側では uri の書き換えもマルチバイト文字については
きちんと動かないと思われます。(uri エンコードしていない場合と
uri エンコードしている場合とそれぞれにいろいろ問題があるような)

といったように、パスにマルチバイト文字を使った場合には、いろいろと
解決していかなければならない問題が多々あります。

今のところパスのマルチバイト文字を考慮している部分というのは全体
のうち、ほんのわずかな部分ってことです。

> Windows, OS/2システム上のNamazuへ問い合わせ(検索)があった場合、
> 検索結果のリンク先として、エンコード済みuriがクライアントに返される。
> そのuriに対してhttpリクエストが行われた場合、uriデコードで得られる
> パス名/ファイル名はeuc-jpであるため実ファイル(sjis)と一致しないため
> File not foundとなってしまう。

はい。mknmz -U を使えってことになっていたかと思います。
(それも、Web ブラウザによってはうまく行かないのですが、ほとんど
の場合、Windows の IE なので問題が起こらないということなのだ
と思います。未確認ですが。)

ここは何らかの対策が必要かと思います。
  
> 問題点2
> urlエンコードを行わない(mknmz -U)ことで、リンク先の可読性は非常に
> 高まるが、ブラウザはリクエスト時に、uriエンコードを行いアクセスを
> 行う。その際のマルチバイト文字コードは不定である。
> サーバ側の文字コードと合っていれば問題ないが、そうでなかった場合は
> File not foundとなってしまう。

mknmz -U を使ってみては? と軽く言ったのが誤解を招いているのだと
思いますが、これは Namazu とは直接関係ない話で、パスにマルチ
バイト文字列を使う際の普通の問題ですね。

本来、uri を指定する場合は Web サーバの漢字コードで uri エンコード
して指定すべきで、uri エンコードせずに指定すべきではありませんから。

きちんとした対応ではないですが、uri エンコードせずに指定して動く
環境で使っているのなら、(きちんとした対策ではないにしろ)とりあえず
uri エンコードせずに指定して使えば良いのではないか?
というのが、このスレッドの最初の発言の趣旨です。
# まぁ、その場しのぎの安直な対策です。

一方で、きちんと Namazu を改造する方はやらなければならないと
思いますので、きちんと対処するならリンク先は uri エンコード
されていなければならないというのは承知しています。
で、それはいろいろと煮詰めないといけない問題があります。
以下、その話です。
 
> 問題の回避としては、
> 1. mknmz時にファイルシステムから得たパス名/ファイル名には一切
>    手を加えず、uriエンコードのみとする。

まぁ、そういう手はあるわけですが...。
 
> 2. 可読性を高めるには、uriをデコードしマルチバイト文字コードの
>    検出をし出力したい文字コードに変換する

表示側ですね。はいそう考えています。
samba と併用している場合は cap だったりした場合、デコードできない
というケースがあります。(今は未対応) 
この辺りもひっくるめて対応したいと思います。(と、どこかで書いた
はず)
 
> 3. uriを検索対象として利用する際にeuc-jpで無い場合正しく検索が
>    行えない。(mknmz -Uでuriエンコードを抑止した場合の話ですが)
> 
> ってことになると思うのですが、3は問題点1にあるとおりWindows, OS/2
> では保証されますが、Unixの場合はファイルシステムの文字コードに
> よっては、まったく意味をなしません。1はクライアントがサーバ上の

漢字コードを統一すれば良いだけです。
現状、Unix は euc-jp しか考慮されていないってことです。

> リソースに正しくアクセスできることを保証するものなので文字コード
> 変換は止めるべきと提案します。

文字コードの変換をしてもリソースに正しくアクセスできれば良いわけです。
可逆変換なら本来問題になることではありません。
(まぁ特殊文字だとか非可逆変換なところもあってトラブルが起こることは
あるわけですが。)

> 2は、自サーバのファイルシステムで利用されている文字コードを出力用の
> 文字コードに変換するだけなので実装はそう難しいことではありません。

はい。
 
> 3は
> +uri: hogehoge
> って検索は運用上使う人が居るのか疑問に感じます。
> uriが判らないからnamazu等の検索システムを使うのであって、uriから
> 対応する要約を見るのも間抜けに感じませんか? 私だったら直接そのuri
> のサイトに行きます。

ちょっと誤解があるかと思います。
これは、ファイル名等で検索したい場合に使えます。また、ニーズも
多いです。(現在、きちんと機能していませんが。)

もっとも、現在では uri エンコードされているとか、改良しなければ
ならない話は山ほどあるわけですが、完全に捨ててしまうには惜しいと
思いますよ。

> Tadamasa Teranishi wrote in <3F78605B.D1F3D308@xxxxxxxxxxxxxxx> :
> >> ${uri} に UTF-8 のまま URL encode したものが入っていたという
> >> ことは、クリックしてファイルにたどり着けるかという点では問題は
> >> ありません。URL encode したものがウェブ・ページに表示される
> >> ことが、人間が読めないという点で問題でした。
> >
> >いや、${uri} は EUC でないと、他とのバランスが合わないんですよ。
> >(encode されている、されていないの違いはオプションで生じますが。)
> 
> これに拘らなければ幸せになれるでしょう。

ある意味そうですが、ある意味違うでしょう。

uri の表示とリンクだけに限ればそうですが、uri の利用用途をもっと
広げて考えると、漢字コードを変換して保持することが幸せになること
もあります。

リンク先は Web サーバの漢字コードで uri エンコードされているものを
提供し、表示する部分が出力漢字コードで出力しさえすれば良いわけで、
インデックスファイルの漢字コードが Web サーバの漢字コードでなければ
ならないということはありません。
現状、インデックスファイルの漢字コードは euc-jp で統一されています
し、インデックスファイルの漢字コードが統一されているということは
それだけで幸せな場合もあります。
(遠い将来は unicode で統一したいもんですけど。) 

uri の書き換えだとか、ファイル名検索に使うとかを考えると、
インデックスファイルに保存される uri は euc-jp に統一されている
方が何かと便利でしょう。
そのニーズがマルチバイト文字のuri表示/リンクの問題解決のニーズ
よりも小さいわけですが、このニーズを考慮した上で、マルチバイト文字の
uri表示/リンクの問題解決もできると思いますので、対策のの際には
考慮していただきたいと思います。(面倒でもね。)

> ここも疑問なのですが、Namazuによって提示されたuriへアクセスするのは
> ブラウザであってNamazuを経由せず直接uriをオープンするので、無意味に
> 思えます。寺西さんの言われていることは下記部分の表示についてと
> 解釈して、話を進めると
> 
> <dd><a href="${uri}">${uri}</a> (${size} bytes)<br><br>
>                      ------
>                      この部分

無論そうです。

> namazu-users-jaで提案したものを拡張し、
> 
> namazurcにFILEENCODINGディレクティブを追加
> 表示のためのテンプレート内で使用する変数${uri}を以下のように
> することで対処可能だと考えています。

Web サーバのファイルの漢字コードを namazurc で指定するのは
別に良いと思います。

# ついでに cap とかも指定できるようにお願いします。

そういえば、書き漏らしていましたが、Web サーバ内でファイル名の
漢字コードがバラバラなものについては対応できませんが、さすがに
そこまでは必要ないだろうというのが前提になっています。

> namazuの出力はeuc-jp固定なので、FILEENCODINGディレクティブに
> 指定された文字コードからeuc-jpへのコンバートを行う出力形式を
> 追加するにあたってですが、
> マルチバイト文字コードの操作に、libmbflを使おうと考えています。

あまりいろいろな文字コード変換ライブラリを使うのは避けたい
ですが、nkf は余計な変換もするので使えないし、やむなし
といったところではないでしょうか。他によさそうなものもないので、
これで良いかと思います。(他に必要なライブラリとかなければ)

> が指定でき、autoを指定すれば、自動的に元の文字コードを検出し、
> 出力文字コードに変換できます。

ファイル名の場合は文字数が少ないことも多いので、誤認する恐れが
ありますから、auto ではなく明示的に指定するのが良いと思います。

で、これらはそのうちやらなければならないと思っているのですが、
それよりも先に namazu-2.1.13 のリリースをしたいと思っているので、
手を付けていません。
もはや、年内リリースは難しいかなぁ。
-- 
=====================================================================
寺西 忠勝(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