[ruby-list:42293] Re: mime_header.rb

> ふむ。encode_header_B64はエンコーディングつきのencoded-word
> を返すメソッドだったんですね。ちょっと誤解してたみたいです。

us-asciiな token は encodeしない と {勘違い | 当時はそうだった}してた
為の仕様です。
そうだすると、日英混じり文をencodeすると、encodeと非encodeが
入り雑じるので、エンコーディングつきで変換しないと、メソッド作る
メリットが無かったのです。
まとめてencodeして それに ヘッダー名とか エンコーディング方式とかを
つけくわえるので良いのなら、pack('m")でよいのだし。
   1行目の折り返しがうまくいかないかも、、、だけど
   packじゃだめかぁ、ってあのころ書いた気がするので、ひっくり返して
   見るかな。

ですので、RFCの正しい理解しなおして、考えなおす必要があるかも。

で、
> とすると、iso-2022-jp以外のエンコーディングは指定できるのか
> どうかとか、Qエンコーディングできるメソッドは用意するのかと
> か疑問は残ります。

取りあえずのバージョンでは、未対応としておいておいて、
必要に応じて、同じメソッドで対応出来るように上位互換できるだろう
とおもいます。
省略可能パラメータを必要に応じて増やして行けばよいのだし。

とすると、 
   文字コード、エンコード方式  を名前に取りこまない方がよく
   エンコーディングを着けて返すと言うことを示す名前がよい
   あ、、
   Headerだけではなく、Multipartの記述でも同じ様式だな、、、、

となると、やはり mime_{en|de}codeかな。

  mime_encode(pre="",len=76,sep="\n ",charset="iso-2022-jp",encoding="B")


ところで、「us-asciiのみのtokenはencodeしない」という私の
勘違い?仕様は、To: しん <[e-mail]> をそのまま
喰わせてもよいのですね。

  "To: しん <[e-mail]>".mime_encode
か
  "しん".mime_encode(pre="To: ")+" <[e-mail]>"
か。

日英が入り雑じると変換結果が長くなりますが、そのままのこしてしまいましょうか。