出沢です

コメントありがとうございます。

> Jcode.pmにあわせるならば、
> mime_encode / mime_decode は無難かもしれません。
> "header"という文字列はありませんが、
> body用だと思う可能性は少ないでしょうし、
> 将来の名前空間を食ってしまうこともなさそうです。

今週一杯ぐらい議論を待ちますが、取りあえず これを第１侯補と
します。

ところで、
> RFC2047には、
> “The "B" encoding is identical to the "BASE64" encoding”
> とあるので、B64 でなく B の方がいいと思います。

了解。 base64 であることを名前に入れる場合は B を採ります。

> さておき、str = "テスト test" をいわゆる「BASE64」したとき、
> 期待される変換結果はおそらく二種類あります。
> 
> 一つはただ変換しただけの "GyRCJUYlOSVIGyhC\n"。
> もう一つは encoded-word にした "=ISO-2022-JP?B?GyRCJUYlOSVIGyhC?="。
> 変換結果がどちらなのか明確なメソッド名であるべきかと。

＞変換結果がどちらなのか明確なメソッド名であるべき

は賛成です。

で、
例に上げられた変換を見ていて、あれ! って思いました。

RFCを読み損なってたかな
  "テスト test" は、us-ascii な "test" が 非us-asciiな文字と
  white space で区切られているので、これはencde対象にはしなくて

  =?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?= test

  にする

と思っていたのですが、いま読み直してみたら見つからない。。。

私の勘違い? 
あまりにもあまりな規定なので改訂された?
実はそのとおりだけど、探し損ない?

仮に「実はそのとおりだ」であったとしても、
そこまでRFCに従わなでも、実際上は支障無いのですが、
mime_header.rb ではそこにこだわりました。。
  # これは個人的嗜癖じゃ、

よけいなことを仕込んでしまったかもしれません。

今生きてる RFC ではどうなってるでしょう。詳しい方よろしく。



> なお、他の言語では、
> Perl/Jcodeの場合
> http://openlab.jp/Jcode/Nihongo.html#item_mime_encode
> mime_encode で ISO-2022-JP、MIME_Header で UTF-8。

げげ、名前から受ける印象と合わないのは、なんとも。。。

おそらく、初めは mime_encodeしかなくて、そのうち
UTF-8 もサポートする必要が出てきて、
でも mime_encode を mime_encode_jis って改名すると
互換性がなくなるから、、、って事なのでしょうね。

mime_header.rb にその必要がでてきたら、省略可能パラメータで
文字コード指定するようにしましょう。