nmh

金曜日の夜から鼻水ずるずるで。土曜日は、ぜんぜん気にせずフォントと格闘していたんだけど、どんどんひどくなって、結局、土曜日は死んでました。でも、日曜日は少しましになったような気がする。

nmh って、まだ、メンテされているのね。ちょっと、ソースを見て動かしてみたんですが、(Makefile の -liconv を -L/usr/local/lib -liconv にするだけで compile できた)

＊　show/mhl が body の content encoding を見て decode しない

まぁ、MH は、昔からそうなんだけど。body に decode って書いたら malloc で落ちた。それで、

＊　mhmail で、Body decode をやる

という構成らしい。でも、そうすると、Base64 なUTF8 とか Q encode な JIS のメールに普通に reply できない。mhmail あほだし。読めればいいってもんでもないよね。それに、

＊　HTMLとかUTF8(とかpdfとかwordとか)で送ってくる人に普通にJISで返事する

のが面白いんだよ。

MH-JPは結構複雑なことをやっているんだけど、内部UTF8が考慮されているならば、もしかして、scan とか format とか変更なしでいけるのか? と思ってソースを読んだのだけど、あまり、そういう感じではなさそう。もっとも、折り返しとかは mh でやって仕方ないから無視しても良いんだけどね。

ただ、Subject は decode して iconvしてくれるので、そこはいじらなくて良いらしいです。すばらしい。ということは、

＊　mhl で content encoding にそって decode する

だけで良い気がする。だったら修正は容易なはず。mhl を Perl で書くっていうのは既にやってるし。

問題は送信側だが、

＊　今更、JISで送信にこだわっても仕方ないんじゃないか?

というか、この mh から書いている blog で Unicode が内部EUCで化けるのに困っているわけだ。UTF-8 そのまま送っていいなら楽なんですが。

実際、Q encode な UTF-8 を nmh から送っても全然問題なく iPhone で読める。他の人が読めるかどうかは知らんけど。たぶん、iconv で JIS に変更するのを失敗したら base64 UTF-8 で送るで良いんじゃないかな。

でも、今、手を付けるのはどうかと思うので、少し寝かせておくのかな。