[Date Prev][Date Next][Thread Prev][][Date Index][Thread Index]

Re: w3m-type for w3m-0.3-m17n-20020316.tar.gz



From: TSUCHIYA Masatoshi <tsuchiya@pine.kuee.kyoto-u.ac.jp> さん曰く
Subject: [emacs-w3m:03018] Re: w3m-type for w3m-0.3-m17n-20020316.tar.gz
Message-ID: <20020318233127O.1000@pine.kuee.kyoto-u.ac.jp>
Date: Mon, 18 Mar 2002 23:43:23 +0900

白井> けど、化ける記事は wanderlust でも化けるし、(試していませんが)
白井> T-gnus で shimbun しても化けるんじゃないかな。w3mmee も化ける
白井> sb-*.el があると思います。

土> T-gnus + w3mmee で試してみましたが,とりあえず sb-zdnet.el は大丈夫で
土> したよ.

ふむ。

土> というわけで,白井さんの提案された変更にはかなり疑問を感じます.

えっと、自分でもとっても疑問に感じていますので大丈夫です。:-)

白井> 原因としては、w3m-m17n だと retieve 結果の buffer が *生* のバイ
白井> ト列だけど、w3m だと *生じゃない* データで、shimbun 自体は *生じゃ
白井> ない* と思って動いているからだと思います。

土> これ,ちょっと信じられないのですが.

お昼休みの3分ハッキングだったので ^^;;;

土>     (defun shimbun-retrieve-url (url &optional no-cache no-decode)
土>       (let (type)
土>         (when (and url (setq type (w3m-retrieve url no-decode no-cache)))
土>           (unless no-decode
土>             (w3m-decode-buffer url))
土>           type)))

土> という関数定義になっているので,第3引数で明示的に指定されていない限り,
土> w3m-type の値に関わらず,buffer は decode されるはずなんですけど.

土屋さんのサジェスチョンで原因がわかりました。

以下の挙動は w3m-m17n と w3mmee で、かつ、w3m(-m17n|mee) の吐き
出す情報が間違っているときに発生する可能性があると思います。

たとえば、 http://www.zdnet.co.jp/news/ は本文が shift-jis で書
いてあり、また、html には
<meta http-equiv="content-type" content="text/html;charset=x-sjis">
と埋め込んであるのですが、"=" を押してみると、

----- emacs-w3m の出力 ----- 
Page Information

Title:          ZDNN:トップページ
URL:            http://www.zdnet.co.jp/news/
Document Type:  text/html
Last Modified:  

━━━━━━━━━━━━━━━━━━━━━

Header information

W3m-current-url: http://www.zdnet.co.jp/news/
W3m-document-charset: US-ASCII		<== この行注目
HTTP/1.1 200 OK
Server: Netscape-Enterprise/3.6 SP3
Date: Tue, 19 Mar 2002 03:07:51 GMT
Content-type: text/html
----- emacs-w3m の出力 ----- 

となっています。w3m-m17n のときは、この US-ASCII が attributes
に登録されるので、以下、

(w3m-decode-buffer "http://www.zdnet.co.jp/news/") 

したときの w3m-decode-buffer の動きは

(w3m-content-charset "http://www.zdnet.co.jp/news/") => US-ASCII
(w3m-charset-to-coding-system "US-ASCII") => raw-text

となり、w3m-decode-buffer() では raw-text で
decode-coding-region() しているだけだからというのが結論ですね。

# それで、ぼくには *生* のバイト列に見えたというおちですね。

ちなみに、w3mmee だと W3M-Document-Charset: shift_jis と出たので、
w3mmee での zdnet は大丈夫なのでしょう。

さて、どうしましょう。この辺りの動きを完璧に理解しているわけでな
いので、またまた自信が無いですが、

(defun w3m-decode-buffer (url &optional content-charset content-type)
  (w3m-decode-get-refresh url)
  (let (cs)
    (unless content-charset
      (setq content-charset (w3m-content-charset url))
      (when (or (null content-charset)
		(string= (upcase content-charset) "US-ASCII"))
	(setq content-charset
	      (when (string= "text/html"
			     (or content-type (w3m-content-type url)))
		(let ((case-fold-search t))
		  (goto-char (point-min))
		  (when (or (re-search-forward
			     w3m-meta-content-type-charset-regexp nil t)
			    (re-search-forward
			     w3m-meta-charset-content-type-regexp nil t))
		    (match-string-no-properties 2)))))))
    (when content-charset
      (setq cs (w3m-charset-to-coding-system content-charset)))
   .....
な感じで "US-ASCII" は無視するか。

けど、普通に kterm 上で

% w3m-m17n http://www.zdnet.co.jp/news/

で "=" 押すと

----- w3m-m17n の出力 ----- 
Information about current page

Title                ZDNN:トップページ
Current URL          http://www.zdnet.co.jp/news/
Document Type        text/html
Last Modified        unknown
Document Charset     [Japanese (Shift_JIS, CP932) ]
                     [Change]
...
----- w3m-m17n の出力 ----- 

と Shift_JIS と表示されるから w3m-m17n は Shift_JIS だとわかって
いるわけです。ので、w3m-m17n の main.c の

dump_extra(Buffer *buf)
{
    printf("W3m-current-url: %s\n", parsedURL2Str(&buf->currentURL)->ptr);
    if (buf->baseURL)
	printf("W3m-base-url: %s\n", parsedURL2Str(buf->baseURL)->ptr);
#ifdef USE_M17N
    printf("W3m-document-charset: %s\n",
	   wc_ces_to_charset(buf->document_charset));
#endif

あたりがなにかしらおかしいか?ですね。どうでしょうか? > 坂本さん


P.S.

土> これ,非常にややこしくて困っているのですが,w3m-retrieve() の 第2引数 
土> no-decode は,漢字コードを decode しないことを指定する引数ではなく,転
土> 送用に変換・圧縮されたコンテンツを展開するかどうかを指定する引数なんで
土> すね.

知らなかった ^^;;;

-- 
白井秀行@で、また昼休みが終わってしまったわけだ