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

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> In [apel-ja : No.00398] 
>>>>>	"山岡さん" = Katsumi Yamaoka <yamaoka ＠ jpl.org> wrote:

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

;; というか、APEL/FLIM 的に正しい解が出て良かったというか。


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

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

山岡さん> という結果を得ることもできます。このように、たまたま 
山岡さん> current-buffer がunibyte であったとしても、バッファの内容と
山岡さん> は関係が無い処理は許されると思っているのですが、いかがでしょ
山岡さん> うか?

上記の例の処理の入出力に buffer は関わっていない気がします。文字列は
buffer と独立に unibyte/multibyte 型の区別を持っていますから、入出力だ
けを見れば上記は

(decode-coding-string "\e$B$\"$$$&$($*\e(B" 'iso-2022-jp)

と同じに思えます。


山岡さん> そしてこれが OK だとすると、decode-mime-charset-string など
山岡さん> が unibyteなバッファでは何もしないという現在の仕様は、ぼくの
山岡さん> 期待するものとは違っています。

文字列の処理が buffer に依存するのは確かに変です。ただ、Emacs 20 にお
ける mcharset は次の要求を満たすこをが期待されています：

(1) buffer 毎に unibyte/multibyte の世界を実現できること
(2) ある buffer で表現可能な MIME-charset をその buffer の表現に適合し
    た形で decode すること
(3) ある buffer で表現不可能な文字を decode しないこと

(2) より decode-mime-charset-string はそれが使われる preview-buffer の
表現形式での文字列を返すことが期待されています。例えば、

(decode-mime-charset-string "Gau\xdf" 'iso-8859-1)

の返り値である文字列 "Gauß" は multibyte buffer では "Gau\x8df" という
multibyte 表現によって表現され、latin-1 な unibyte buffer では
"Gau\xdf" という unibyte 表現によって表現されます。どちらも意味は
"Gauß" です。

特に、(3) を実現するには enable-multibyte-characters を見るのが簡便な
方法であろうと思います。

しかし、今から思えばこういう要求が妥当なのかはやや疑わしい気がします。
例えば、latin-1 な unibyte buffer で

(insert "Gau\x8df")

すれば "Gau\xdf" で表現される文字列 "Gauß" が挿入される訳で、(3) を諦
めさせすれば（また、unibyte buffer での効率の悪さを無視すれば）文字列
decode 関数が常に multibyte 文字列を返しても破綻しません。

そういう訳で、もし、今、同様のものを設計するなら多分常に decode するも
のを作ると思います。


なんで現在のようになっているのかは定かではないのですが、ChangeLog を見
ると

1997-11-04  MORIOKA Tomohiko  <morioka ＠ jaist.ac.jp>

	* emu-e20.el (encode-mime-charset-region,
	decode-mime-charset-region, encode-mime-charset-string,
	decode-mime-charset-string): New function (copied from emu-20.el);
	check `enable-multibyte-characters'.

がそのはじめのようで、なんとなく Emacs 20.2 以前の時代のことのようです。
この時代、unibyte/multibyte 文字列型はなく、byte 列が
enable-multibyte-characters 毎に異なった解釈をされる時代でした。

また、Emacs 20.3 以降の混乱期の状況は良く覚えていません。


まあ、もし、今 mcharset 相当のものを作るなら

・-region はなし

・-string は常に変換

・(insert-{encoded|decoded}-mime-charset-string STRING) および
  (insert-{encoded|decoded}-mime-charset-buffer-substring BUFFER
   &optional START END) みたいなものを導入し、ここで
  enable-multibyte-characters を見るようにする

と思います。互換性の観点から mcharset の仕様変更には反対しますが、これ
とは異なる新しい API を作ることには賛成します。

coding-standard の観点からも mcharset には問題があるので、例えば、
mime-cs というような新たな module を作るというのは良いかも知れません。
（APEL じゃなくて FLIM でやった方が良いかも知れませんが）。


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

multibyte buffer での 128 〜 255 の Mule-charset に依存したり、その他、
生の byte 表現に依存してたりするとだめかも知れません。

;; 今、Emacs 21 を使ってないので、識者にお任せします。
-- 
┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━
││ ─ │  ─  ／    ─   ┼─     ┬                ─   ─┼ ┬┴─
┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ m17n.org> ─ ─┬
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━