[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: w3mmee vs emacs-w3m problems (was: ...)
>> On 10 May 2001 22:40:48 +0900
>> "suto" == suto@ks-and-ks.ne.jp (Kiyokazu SUTO) said as follows:
suto> 私の投稿したw3m.el用のパッチでcoding-systemの処理を一切しなくなる
suto> (w3mmee側の端末出力用encodingに対応するcoding-systemに固定される)ので、
suto> 問題は無い筈と思いますが、何か実際に問題が起きたのでしょうか。
これは、w3mmee に与えるオプションによって動作が異なってきます。例えば、
[emacs-w3m:00555] のように指定すると、具体的には
(setq w3m-decode-all-to-this-charset 'euc-jp
w3m-dump-head-source-option "-dump=extra,head,decode")
と指定すると、http://namazu.org/~tsuchiya/emacs-w3m/index.html は本来、
iso-2022-jp であるにも関わらず、
(w3m-download "http://namazu.org/~tsuchiya/emacs-w3m/index.html")
した結果は EUC-JP になってしまいます。これは個人的には、*大問題* だと
思います。
この問題の原因は、w3mmee によって -dump_source 相当の処理を行う時点で、
文字コード変換や圧縮の展開などが行われても、それを上位の emacs-w3m 側
で知ることができない、という点にあると思います。
副次的には、本家 w3m を利用する場合と比較して、emacs-w3m の動作が極端
に異なってしまう(特に文字コードの処理)ので双方に対応し続けることが難し
い、という点も問題だと考えています。ですから、なるべく本家 w3m と同様
の処理手順で処理できるように、w3mmee に歩み寄って頂けないでしょうか。
具体的には、以下のような処理手順を考えています。
(1) w3m -dump_source でコンテンツを取得。この段階では、文字コードの
変換や圧縮の展開など、コンテンツを改変するような操作は一切行わな
い。
(2) コンテンツをキャッシュに登録(w3m-cache-contents)
(3) Content-Encoding: の処理。gzip / bzip2 / inflate などの展開。
(4.a) 本家 w3m の場合
コンテンツの文字コードを EUC-JP に変換して w3m -halfdump を行
う。すなわち
w3m -T text/html -I e -halfdump < contents
という処理を行う。
(4.b) w3mmee の場合
文字コードについての解釈は行わずに w3mmee -halfdump を行う。つ
まり、raw-text を w3mmee に渡す。ただし、Content-Type: で指定
された文字コードを w3m に指定する必要があるので、以下のように
-I オプションで指定する。
w3m -T text/html -I euc-jp -halfdump < contents
サーバーが Content-Type: で文字コードを指定しなかった場合は、
w3m -T text/html -halfdump < contents
を実行して、w3mmee の自動コード判定に全て委ねる。
(5) w3m-fontify
このような処理手順であれば、w3mmee の最大の特徴である多言語対応を損な
うことなく、また本家 w3m とも殆んど変わらない手順で処理することができ
ますから、emacs-w3m としては大変対応が楽になるのでありがたいのですが。
また、w3mmee 側で具体的に必要になる変更は、
・-I オプションの拡張
e/s ばかりでなく、汎用の MIME charset 指定文字列を取れるようにする
の1点だけですから、これも簡単だと思うのですが、いかがでしょうか。
--
土屋 雅稔 ( TSUCHIYA Masatoshi )
http://www-nagao.kuee.kyoto-u.ac.jp/member/tsuchiya/