{encode|decode}-mime-charset-* (Re: T-gnus bbdb)

[Katsumi Yamaoka]

;; T-gnus の方は APEL とは関係無く落ち着いてしまいましたね。:-)

>>>>> In [apel-ja : No.00397] 
>>>>>	tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote:

山岡> enable-multibyte-characters が nil だと 
山岡> encode-mime-charset-region などが何もしないせいですね。
山岡> → mcs-e20.el
山岡> ぼくはこの設計意図が何なのか知らないのですが、XEmacs などとの互
山岡> 換性を考慮して enable-multibyte-characters は不問にするか、
山岡> default-enable-multibyte-characters を参照するのでも良いような気
山岡> がしています。まったく確信はありませんが。

守岡さん> mcharset は unibyte の世界で使うことも考慮しています。
守岡さん> multibyte の世界で使う場合 unibyte の世界は byte 列の世界で
守岡さん> すが、unibyte の世界で使う場合 unibyte の世界は文字列です。

わかり易い解説をありがとうございます。

守岡さん> decode-mime-charset-* は byte 列 → 文字列 への変換であり、
守岡さん> encode-mime-charset-* は 文字列 → byte 列 への変換です。

守岡さん> 前述のとおり、preview-buffer が multibyte の場合、unibyte =
守岡さん> byte 列, multibyte = 文字列 なので、decode は unibyte → 
守岡さん> multibyte, encode は multibyte → unibyte の変換となります。
守岡さん> 同様に、unibyte の場合は、それぞれ unibyte → unibyte,
守岡さん> unibyte → unibyte の変換となります。

納得です。たしかに multibyte になっている *scratch* バッファで以下の式
を eval した結果は

(with-temp-buffer
  (set-buffer-multibyte nil)
  (insert "\e$B$\"$$$&$($*\e(B")
  (decode-coding-region (point-min) (point-max) 'iso-2022-jp)
  (buffer-string))
 => "\222\244\242\222\244\244\222\244\246\222\244\250\222\244\252"

となります。

守岡さん> ところで、Emacs 20 では multibyte buffer で byte 列を安全に
守岡さん> 表現できないので、１つの buffer で byte 列と文字列を混在させ
守岡さん> るのはまずいです。よって、-region は禁じ手となります。

これは理解できます。どんな悲惨な結果を生むかもしれないにせよ、unibyte
なバッファで decode-coding-region などを使うと何らかの変換結果がバッファ
に挿入されますが、これはプログラマの責任で回避すべきことですね。

しかしながら、unibyte 国に旅行に行った二人の日本人どうしが母国語で会話
するがごとく、

(with-temp-buffer
  (set-buffer-multibyte nil)
  (decode-coding-string "\e$B$\"$$$&$($*\e(B" 'iso-2022-jp))
 => "あいうえお"

という結果を得ることもできます。このように、たまたま current-buffer が
unibyte であったとしても、バッファの内容とは関係が無い処理は許されると
思っているのですが、いかがでしょうか?
そしてこれが OK だとすると、decode-mime-charset-string などが unibyte
なバッファでは何もしないという現在の仕様は、ぼくの期待するものとは違っ
ています。

守岡さん> なお、Emacs 21 では XEmacs-mule のように、multibyte buffer 
守岡さん> で byte 列を安全に表現できるようになる（128 〜255 を文字に変
守岡さん> 換して（binary 用の leading-byte を付けて）buffer に格納する
守岡さん> ようになる）そうなので、multibyte buffer だけで処理できるよ
守岡さん> うになると思います。但し、byte と文字の区別はないので、どっ
守岡さん> ちのつもりで扱っているのかを programmer が判断する必要があり
守岡さん> ます。

ううむ、やっかいなことにならないことを祈りますが、少なくとも Emacs 20
で正しく動いている既存のプログラムは、そのまま通用しそうですね。

守岡さん> XEmacs-mule の場合、単一の buffer 表現しか無いので、変換が生
守岡さん> じず、問題ありませんが、Emacs 21 の場合、unibyte buffer も存
守岡さん> 在し、unibyte buffer で 0 〜 255 をどういう文字に対応させて
守岡さん> いるかは環境に依存するので、unibyte buffer から取って来た文
守岡さん> 字列を multibyte buffer に挿入する場合には変換が生じます（実
守岡さん> 際にどのように変換するかの詳細は知りません）。よって、やはり
守岡さん> 複数 buffer を使う場合には byte と文字の区別を付けて取り扱う
守岡さん> 必要があると思われます。

了解しました。貴重な情報をありがとうございました。
-- 
Katsumi Yamaoka <yamaoka ＠ jpl.org>