『tm-mh-e で ISO-2022-JP 以外の文字 code を使う方法』
by 守岡 知彦

  MTA で ISO-2022-JP を EUC-JP や Shift-JIS などに code 変換している場
合、tm-mh-e の default の設定では文字化けします。こうしたことを行なう
ことはあまり勧められたことではないと思いますが、ここではこうした環境で 
tm-mh-e を使う場合の設定について説明します。


* Mule の場合

  tm-mh-e の標準設定では、charset parameter が存在する場合はそれで指定
された文字 code になり、charset parameter が存在しない場合（非 MIME
message を含む）の場合の文字 code は *ctext* となります。

  charset が存在しない場合の文字 code は変数 
mime/default-coding-system で指定されます。この既定値が *ctext* であり、
ISO-8859-1 か ISO-2022-JP などの JUNET 方式の ISO-2022 code であること
を期待しています。

  charset が存在する場合は、変数 mime/charset-coding-system-alist に設
定された、その charset に対応する Mule の coding-system が用いられます。

  これらの動作は関数 tm-mh-e/code-convert-region-to-emacs で行なわれま
す。よって、これらの変数および関数を変更することによって MTA で code 
変換された場合の対策を行なうことができます。


** 非 MIME message または charset が存在しない場合のみの対策

  非 MIME message の場合、変数 mime/default-coding-system に文字 code 
を設定すれば OK です。Shift-JIS の場合は

	(setq mime/default-coding-system *sjis*)

EUC-JP の場合は、

	(setq mime/default-coding-system *euc-japan*)

として下さい。


** charset が存在する場合も含めた対策

  charset が存在する場合、変数 mime/charset-coding-system-alist に 
"ISO-2022-JP" に対応する coding-system を *sjis* や *euc-japan* に変え
るというのが１つの方法です。但し、この場合、encode されて元の文字 code 
が保存されている場合に文字化けすることになります。

  このことを考慮すると、関数 tm-mh-e/code-convert-region-to-emacs を再
定義するのが良いといえます。おそらく、ISO-2022-JP 以外の文字 code は保
存されないでしょうから、以下のような定義で十分でしょう。

	(defun tm-mh-e/code-convert-region-to-emacs
	  (beg end charset &optional encoding)
	  (code-convert beg end *sjis* *internal*)
	  )