Re: history mojibake

[Hideyuki SHIRAI ( 白井秀行 ) <shirai@xxxxxxxxxxxxxxxxxxx>]

From: Kiyokazu SUTO <suto@ks-and-ks.ne.jp> さん曰く
Subject: [emacs-w3m:03170] Re: history mojibake
Message-ID: <20020408-234203-17281.suto@ks-and-ks.ne.jp>
Date: 08 Apr 2002 23:42:03 +0900

> > 添付した z1.html(iso-2022-7bit で保存した)を上記の引数で変換する
> > と同様に化けると思います。
> >
> > # とここまでやって、w3m-find-file() でも、もとのファイルが
> > # iso-2022-7bit だと化けて、iso-2022-7bit-ss2 だと化けないことに
> > # 気付いてしまいました。同じ原因だと思います ^^;;;
> 
> いただいたz1.html.gzをhex dumpしてわかりましたが、iso-2022-7bitという
> のはMuleの独自指示列である
> 
>  0x1B 0x2C 96セットの終端バイト

# 独自だったとは知りませんでした。
# 通りで調べてもわからなかったわけだ ^^;;;

> を使うんですね。libmoeはこれを解釈しない(昔は解釈していたけれども、あ
> るページで盛大に化ける原因になったので、それ以降止めた)ので、Latin-1の
> 右半分をG0に指示する
> 
>  0x1B 0x2C 0x41
> 
> の0x1Bを読み飛ばし(実際はもう少し複雑)
> 
>  0x2C 0x41
> 
> だけがレンダリング結果に現れて、それが化けているように見えるのでした。

解説ありがとうございます。iso-2022-7bit-ss2 にしなくてはいけない
理論的な裏付けが取れました。

> | $ -- iso-2022-7bit-ss2
> |   ISO 2022 based 7-bit encoding using SS2 for 96-charset
> 
> これの「-7bit-」というところを8bitと思い込んで、それ以降を読み飛ばして
> しまったために、余分なお手間を取らせてしまいました。ごめんなさい。

いえいえ、です。ということは、

From: Hideyuki SHIRAI (白井秀行) <shirai@rdmg.mgcs.mei.co.jp> 曰く
Subject: [emacs-w3m:03169] Re: history mojibake
Message-ID: <20020408.230959.31271411.shirai@netlaputa.ne.jp>
Date: Mon, 08 Apr 2002 23:09:59 +0900 (JST)

白井> # とここまでやって、w3m-find-file() でも、もとのファイルが
白井> # iso-2022-7bit だと化けて、iso-2022-7bit-ss2 だと化けないことに
白井> # 気付いてしまいました。同じ原因だと思います ^^;;;

が既知の問題として残ってしまったので、こっちは地道に考えます。

-- 
白井秀行 (mailto:shirai@rdmg.mgcs.mei.co.jp)