後藤@太陽計測です


>>>>> at Thu, 18 Mar 1999 09:22:45 +0900
>>>>> 出沢 <dezawa / miya.fujifilm.co.jp> said,
出沢> ユーザが入れた 空白(改行を含む)も、MUA が入れる 空白 とは
出沢> 区別できない。そして復号時にどちらも削って良い。

細かいようで申し訳ないのですが、空白ではなく改行です。
MUAはencode時にencoded-wordが並ぶ部分に改行+空白をいれることはありますが、
それ以外のASCIIな部分に勝手に空白を追加することはありません。
もともと空白がある部分に改行を追加(folding)することはあっても。


出沢> これで encode は楽になりました。
出沢> その代わり、復号時にどのように空白を消すべきか、という
出沢> あらたな問題が出て来てしまいましたが。
出沢> 消さないでも RFC 的には問題ないのですが、それだと
出沢> もともと 1行のものが2、3行に別れてしまうので、、、

# rfc2047を実行する部分とrfc822を解釈する部分とMUA的な表現処理
# (unfolding, etc.)を混ぜ合わせてしまっているように感じます。:-(

デコーダの振る舞いとしては、デコードだけが目的であるため、
encoded-word間のlinear-white-spaceのみを削除すれば良いと思います。
それ以外の部分のunfoldingはデコーダに渡す側が事前に行なうか、
あるいはデコーダから受け取った側が事後に行なうか、あるいはunfold
しない、ということになるとおもいます。

mime.rbの仕様というか、どういうレベルの処理を受け持つのかにもよるので
なんともお答えできません。


出沢> もっとも、 RFC2231はまだちゃんと読んでいないので、ここに B encode や 
出沢> Q encodeを "" で挟んで!! 入れて良いとされているかどうか未確認です。

=?ISO-2022-JP?B?....?=のようなもののことを言っているのであれば、
それはRFC的にはダメです。でも、実際にはまかり通ってしまっていますが。
なので、デコードは出来るときっとうれしいでしょう。
エンコードに関してはRFC2231に従がうのが本筋でしょうが、
ちょっと甘くして、オプションでfilename="=?ISO-2022-JP?B?....?="
なんてのを許すという手もあります。

RFC2231をサポートしているMUAは非常に少ないので、まだ早いうちにサポートすれば
名を上げられるという効果もあります(^^;


出沢> もし駄目よ、ってことなら mime.rb の というか、{en,de}code64 の
出沢> 範疇ではないから今回は気にしない。

RFC2231もB-encode, Q-encodeを使うと言う点では同類ではあります。
とりあえず後回しにするにしても、RFC2231は難しいものではないので
チャレンジしてみてはいかがでしょうか?

--- Regards,
 Shun-ichi Goto  <gotoh / taiyo.co.jp>
   R&D Group, TAIYO Corp., Tokyo, JAPAN