こんにちは、鶴谷@京都です。
"Takayuki Matsuki" <matsuki@tokyo-kasei.ac.jp> さん>
> 現象は確認しました。確かにJISコード以外でも発生していました。
> これは、検索CGI に渡された検索語が16進数表示されたままの
> 状態で吐き出されているということです。
>
> 以下は鶴谷さんの行ったことの確認です。
> １）Ver.4.16 で
> LANGUAGE JAPANESE
> LANGFILE /usr/local/share/analog/lang/uk.lng
> としたときに、uk.lng中にJISコードの日本語を書いたのかどうか。
書いていません。
検索語を decode した後に ISO-8859-1 でない文字ができるので、
そのままではまずいと思い、出力ファイルのコーディング指定に
charset=ISO-2022-JP が入るようにと、その部分だけ修正したのです。
で、単に decode しただけだと、いろんな文字コードが混ざるので、
とりあえずは nkf に通してできるだけ JIS にしようとしました。
> ２）私も同様に上記の設定で実験しました。その際、uk.lngにJIS
> コードの日本語を入れておきました。
> ３）その結果を "nkf -j Report.html > out416.html" としてみました。
> この出力中では、「検索語レポート」中では、正常の文字と文字化け
> した項目がありました。
>
> 結論としてはやはり、検索語レポート中に現れる文字列のコードは、
> 1種類ではないので、たちばなさんの作成したパッチが必要です。
> nkf は１つのコードから1つのコードへの変換はできますが、数種類の
> コードが混じったファイルを統一した1つのコードへ変換したファイルには
> できないと思います。
今試してみましたが、できているようです。
EUC, JIS, SJIS 混在したファイルを作って、nkf に通すと、
全て JIS のファイルを作ることができました。
ただし、常にできるかどうかは、確かに確信はないです。
いままでも、確かうまく変換されていないのもあったように
記憶しています。
> また、Ver5.22では、マルチバイト文字コードの場合には、検索語の
> デコード（%付きの16進表示から文字コードに変換）を行わずに出力
> を行っているということだと思います。
うーん、そのようで...
これが一番の疑問だったのです。
自分でもいろいろ試しているうちに、(少なくとも日本語関係の
LANGUAGE もしくは LANGFILE 内での指定があれば) decode されて
いないことに気がつきました。
で、出力を更に sed に通して ContentType を書き換えることにして、
生の uk.lng を使うことにしました。
今後はこのままの仕様で行くのでしょうか。
マルチバイト文字コードでも変換して欲しいのですが、
encode前の文字コードが一定でない以上、難しい気もします。
結局は、printableでないASCII文字をdecodeするため*だけ*に
decode機能が存在することになるのですね。
せめて設定ファイルでdecodeするかどうかを指定できると
うれしいのですが(出力ファイルの修正は自己責任、ってことで)...
どうもありがとうございました。
--
鶴谷 直樹@高分子物理.物理第一.京都大
E-mail: turutani@scphys.kyoto-u.ac.jp