Namazu-devel-ja(旧)

[Youichi Iwakiri <yiwakiri@xxxxxxxxxxxx>]

いわきりです

#namazu-devel-jaに振ります。

Tadamasa Teranishi wrote in <3FCC2910.69CEA95@xxxxxxxxxxxxxxx> :
>寺西です。
>Youichi Iwakiri wrote:
>> namazu-devel-ja向けの話
>> NMZ.result.(normal|short).langテンプレート内で使える変数を
>> 拡張した方が良いですかね?
>更に漢字コードの話を含めた拡張案を提示しておりますので、漢字コード
>も含めて考えるようにお願いします。
>http://www.namazu.org/ml/namazu-devel-ja/msg03328.html

拡張に関してのたたき台です。
ご意見をお聞かせ下さい。

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

Unix系であれば、特にコード変換は行わずuriエンコードを行う。
utf-8, sjis, euc-jpにかかわらず実ファイル名をそのままエンコード
するため、そのuriへのhttpリクエストが合った場合、ファイルシステム
との相違が無いため実ファイルへのアクセスは問題ない。

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


問題の回避としては、
1. mknmz時にファイルシステムから得たパス名/ファイル名には一切
   手を加えず、uriエンコードのみとする。

2. 可読性を高めるには、uriをデコードしマルチバイト文字コードの
   検出をし出力したい文字コードに変換する

3. uriを検索対象として利用する際にeuc-jpで無い場合正しく検索が
   行えない。(mknmz -Uでuriエンコードを抑止した場合の話ですが)

ってことになると思うのですが、3は問題点1にあるとおりWindows, OS/2
では保証されますが、Unixの場合はファイルシステムの文字コードに
よっては、まったく意味をなしません。1はクライアントがサーバ上の
リソースに正しくアクセスできることを保証するものなので文字コード
変換は止めるべきと提案します。
2は、自サーバのファイルシステムで利用されている文字コードを出力用の
文字コードに変換するだけなので実装はそう難しいことではありません。

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

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

これに拘らなければ幸せになれるでしょう。

>> > mknmz の generate_uri 辺りに UTF-8 ならば、EUC に変換する処理を
>> > 加えれば良いということのようです。
>> 
>> UTF-8 を EUC に変換されると、実際には UTF-8 な URL へのリンク先
>> (ファイル)にたどり着けなくなると思いますが。
>ということで、EUC から UTF-8 への変換を行う必要があるということです。

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

<dd><a href="${uri}">${uri}</a> (${size} bytes)<br><br>
                     ------
                     この部分

namazu-users-jaで提案したものを拡張し、

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

${uri:format}  この形式を追加
${uri:n}       normal表示(デコード無)
${uri:d}       decode & 文字コード変換

namazuの出力はeuc-jp固定なので、FILEENCODINGディレクティブに
指定された文字コードからeuc-jpへのコンバートを行う出力形式を
追加するにあたってですが、
マルチバイト文字コードの操作に、libmbflを使おうと考えています。
phpのmbstringモジュールが利用しているライブラリになりますが
LGPL 2.1で公開されており、FILEENCODINGディレクティブには
UCS-4, UCS-4BE, UCS-4LE, UCS-2, UCS-2BE, UCS-2LE, UTF-32,
UTF-32BE, UTF-32LE, UCS-2LE, UTF-16, UTF-16BE, UTF-16LE, UTF-8, 
UTF-7, ASCII, EUC-JP, SJIS, eucJP-win, SJIS-win, ISO-2022-JP, JIS, 
ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, 
ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10, 
ISO-8859-13, ISO-8859-14, ISO-8859-15, byte2be, byte2le, byte4be, 
byte4le, BASE64, 7bit, 8bit, UTF7-IMAP 
EUC-CN, CP936, HZ, EUC-TW, CP950, BIG-5, EUC-KR, UHC (CP949), 
ISO-2022-KR, Windows-1251 (CP1251), Windows-1252 (CP1252), CP866, 
KOI8-R. 
が指定でき、autoを指定すれば、自動的に元の文字コードを検出し、
出力文字コードに変換できます。

他に、良い文字コード変換ライブラリがあれば教えて下さい。

是非、意見を戴きたいと思います。

-- 
Youichi Iwakiri mailto:yiwakiri@xxxxxxxxxxxx