後藤＠太陽計測です

base64.rbのためにも、続けちゃいます (._.)>

＃私自身はRFC2047は「欠陥がある」というよりは「十分でない」というくらい
＃に感じてるです。（間違った解釈している可能性も大ではありますが）


>>>>> at Fri, 13 Nov 1998 21:56:01 +0900
>>>>> dezawa <dezawa / miya.fujifilm.co.jp> said,

dezawa> １ ○１行の文字長の最大は、エンコードのみ、エンコードなしのみ、
dezawa>      そのごちゃまぜ含め、行頭の空白を含めて 76Byte。
dezawa>    ×１行76Byteではなくて、１行中のエンコード文字列長(合計)が76Byte

これは先のメールに書いたとおりかと。


dezawa> ２ ？"漢字file" は空白が無いから、全体をまとめて エンコードすべし。
dezawa>       英数字をスルーしないで一緒くたにencodeするのが正しい解釈

これが「空白保存の問題」かと思います。

Section 5 の (1)で

>    Ordinary ASCII text and 'encoded-word's may appear together in the
>    same header field.  However, an 'encoded-word' that appears in a
>    header field defined as '*text' MUST be separated from any adjacent
>    'encoded-word' or 'text' by 'linear-white-space'.

とあるため、encoded-word と それ以外のテキストとの間には liner-white-space
がMUSTなので。逆に、"漢字" と "file"に分けて前者のみをエンコードすると、
間にliner-white-spaceを入れねばならず、とすると、decode時に空白が取り除け
ない以上、原文と同じにならないじゃないか。じゃぁ、いっしょにエンコード
しなければならないじゃないか。という結論が導かれるわけです。

RFC2047には「分けてはいけない」とか、われわれが知りたいケースについて
は書いてありません。そういう明確な例がありませんし、分割のアルゴリズム
も提示していません。そこいらへんを考慮してくれてるのかいな？ と、疑っ
てしてしまいたくもなります。

＃そのあたりが、「word間にスペースはフツーあるでしょ」的な雰囲気を
＃感じる点です。


dezawa>    ？いっしょにエンコードするのは、必要最小限にすべき

「最小限にすべき」というのはちょっと言い過ぎでしたね。これは後述。
そうあって欲しいし、そうあってくれないとMLなどで困るし、という
一般的意識があるため、そう書いてしまいました。


dezawa> ３ ？"=?iso-2022-jp?B?GyRCNEE7ehsoQg==?= file" をデコードすると
dezawa>      "漢字 file" と間に空白が入る。

rfc2047には削除して良いとは書いてありませんから、そういうことになるで
しょう。ただし、encoded-wordの並びの間のliner-white-spaceに関しては削
除(無視)されると書かれています。これはコンコードされた文字列に長さ制限
を設けているため、長いエンコードの分割を許すために必要だからだというこ
とです。

section 6.2 
>6.2. Display of 'encoded-word's
...snip...
>   When displaying a particular header field that contains multiple
>   'encoded-word's, any 'linear-white-space' that separates a pair of
>   adjacent 'encoded-word's is ignored.  (This is to allow the use of
>   multiple 'encoded-word's to represent long strings of unencoded text,
>   without having to separate 'encoded-word's where spaces occur in the
>   unencoded text.)


dezawa> じつは、１は英語を読み違えてた様で、rfcを読み直す前の方が合っていた。
dezawa>   読む直前に、mew でどうなるかみたら、ずらーーっと長ーくエンコード
dezawa>   してたので、あれ？って思ってたんです。で、英語読む時に間違えた、、

ちなみにMewでは 76 char width をまじめに考慮してエンコードしているわけ
ではなく、オーバーしたらば元テキストを半分ずつにしてエンコード、を繰り
返して実現してます。

先のメールで挙げたFLIMは、結構まじめに、76を超えない最大となるように
がんばってます。


dezawa> ２ はどちらが正しいのでしょう。後藤さん「最小限にすべき」というのは
dezawa> どのあたりからそのようになったのでしょうか。

人間的にも「極力可読であってほしい」という一般的思いもあるため「すべき」
などと書きましたが、rfc2047でははっきり書いてあったかなぁ。このあたりかな？
ニュアンスがよく理解できないので違うかも。

section 5 の最後の、"Use of ..., but discouraged."

>5. Use of encoded-words in message headers
...snip...
>   Use of these methods to encode non-textual data (e.g., pictures or
>   sounds) is not defined by this memo.  Use of 'encoded-word's to
>   represent strings of purely ASCII characters is allowed, but
>   discouraged.  In rare cases it may be necessary to encode ordinary
>   text that looks like an 'encoded-word'.

（「その他の注意」の一部になるかな。。。）
訳： これらの非テキストデータ(例えば絵や音)のエンコード方法は
     本書では定義されません。 ピュアなASCII文字列を表すのにencoded-word
     を試用することは許されていますが、考え直してください。極まれに
     encoded-wordのよう（に解釈され得てしまう）な通常のテキストを
     エンコードする必要があるかもしれません。



dezawa> ３ ですが、(２とも絡むのですが、)これは正しいのでしょうか。

dezawa>    (=?ISO-8859-1?Q?a?= b)                      (a b)

dezawa>            Within a 'comment', white space MUST appear between an
dezawa>            'encoded-word' and surrounding text.  [Section 5,

dezawa> という記述があります。一見では "漢字 file"を支持するのですが、
dezawa> "Within a 'comment'" という断りが気になります。
dezawa> commentではない、すなわち( ) で囲まれない場合はどうなの？って
dezawa> 探してるんですが、未だ見付からず。

上記は確かに "Within a 'comment'"なので、そのまま全体には適用できない
ですよね。

では、comment以外の場合はどうかというと、明確に空白が保存されるとも書
いていませんが、先に挙げたように、text中でencoded-wordは単なるwordなの
で、当然空白を削除する根拠がありません。なので、空白が入る、と理解して
います。


ということで、どーでしょーか

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