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

Re: User specified content type / w3mmee support



>> On Tue, 22 May 2001 12:28:47 +0900 (JST)
>> 「白井」== shirai@rdmg.mgcs.mei.co.jp (Hideyuki SHIRAI (白井秀行)) said as follows:

白井> x-moe-internal はあくまで w3mmee の内部コードなので、出力である
白井> -dump=half が x-moe-internal を吐き出す、ということはないと思い
白井> ます。

なんだ、そうだったんですか。なら、当分は x-moe-internal の decoder は
要らないのかなあ…。

でもそうすると、日本語(shift-jis)のページと中国語(big5)のページが、フ
レームの右と左に入っているようなページの -halfdump 結果はどうなるんで
しょうか?


白井> (1) w3mmee -dump=extra,head,source => この出力が x-moe-internal
白井> になる。(frame など)
 
白井> (2) 上記の x-moe-internal をそのまま w3mmee に渡し、w3mmee
白井> -dump=half すると、(設定に依存するが) euc-jp で出力される。

ということは、設定次第では iso-2022-8bit などで出力させることも可能な
のでしょうか? もしそれができるなら、多分実用上は問題ない程度の文字数が
使えると思うのですが。


白井> という感じなので、Emacs で x-moe-internal を直接扱うことはないで
白井> す。だけど、about://source/ したときに、x-moe-internal を decode
白井> できないと表示が化けまくると思いますが。

まあ、実用上は気にしなくていいでしょう。


白井> Decode なら、以下、まったく自身はありませんけど。。。
...
白井> から 'x' を抜き出して ucs-4 にして、rfc2279 より

この x だけを抜き出すと4バイトになるのですが、その時、その4バイトの最
上位ビットが 0 の場合だけ UCS-4 になり、それ以外は適当な変換を経て 
iso-2022-jp などの通常の ISO-2022 準拠のコード系や、それ以外のコード系
になります。

# と、須藤さんに教えて貰いました。

それで、その様々なコード系に展開される規則が分かれば CCL が書けるはず
なので、libmoe のソースを見ているのですが、どうも良く分からない…。うー
ん、うーん。


白井> で utf-8 に変換すれば Emacs + Mule-UCS で表示できるのかな?
白井> ccl の実装は全くできませんけど。:-)

この件についても Mule-UCS の実装の詳細が理解できずに止っています。

-- 
土屋 雅稔  ( TSUCHIYA Masatoshi )
    http://www-nagao.kuee.kyoto-u.ac.jp/member/tsuchiya/