[ruby-list:10802] Re: base64.rb

< ^ > P N |<>|^_>< --- | ~ ...Help
後藤＠太陽計測です

>>>>> From: Toru Hoshina <toru / gte.net>
> ちょっと、うまく切れないので引用が長くなってしまいましたが、
> Sinichiro Dezawa さんがおっしゃることと、後藤＠太陽計測さんの
> おっしゃることって大意は同じですよね？

あーわたしもちょっとDezawaさんのメールを勘違いしてたようです。

で、上記とはちょっとずれますが、

> 後藤＠太陽計測さんは、multiple header lineのための行頭の空白、えっと
> Non Linear White Spaceでしたっけ？を計算に入れて、75charsという
> 解釈のようですが、細かいことですが、私はやはり読んだとおりで、
> encoded-wordの長さは76charsまで、つまり=?から?=までで76bytesだと
> 思います。

これに関しては一応、以下のように75に制限されています。
先の引用個所の直前です。

>   An 'encoded-word' may not be more than 75 characters long, including
>   'charset', 'encoding', 'encoded-text', and delimiters.  If it is
>   desirable to encode more text than will fit in an 'encoded-word' of
>   75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
>   be used.

1行が単一のencoded-wordであれば 1+75で76が最大。
複数の encoded-wordがあったとしても、1行は76が最大。
結局1行は76文字以内ということです。


> > エンコード後の長さが妥当になるような、元文の区切り点を見つける処理が面
> > 倒だとは思いますが。
> 
> 実際には =?iso-2022-jp?B?...?= という形のencoded wordになるわけですが
> iso-2022-jpだよ、と言う以上、それらしくESC$Bではじまって、ESC(Bなどで
> us-asciiなりJIS1バイト英数字なりに戻してやるのがお約束なのだろうとは
> 思います。

当然そうですね。encoded-wordはそれ自体で閉じていなければならないと
明記されていますからね。


> =?iso-2022-jp?B?...?= abc =?iso-2022-jp?B?...?=
> 
> などという形式になるってことは、エスケープシーケンスはencoded wordの中です。
> これって、フザケんなよ凸(-_-#)って感じですよねぇ。

JISベースでバイトストリームを扱おうとすると面倒ですが、エンコード対象
文字列を、バイトではなく「文字」単位で考え、MIMEエンコードする直前で
iso-2022-jpにエンコード(ESC$Bなどの付加も含む)して考えるとよいと思います。

でもなんにしても、区切り点が計算1発で求まらないので、悩ましいですよね。


> iso-2022-jpというと、code set も encode method もJIS X 0208(でしたっけ？)
> をそのまま使いますが、2バイト文字集合だけで、1バイトカナは含まず、という
> ものだったと思うので、実際には、1バイトの英数字は含まないですよね。
> 
> 思うにUnix系のユーザさんは英数字は1バイトの文字を使うかたがほとんどな
> ように見えるので、放っておいてもそこでencoded wordは切れることになるので
> 実際にはencoded wordの76bytesな縛りってのは効いてこないような気もします。

ここはおっしゃる意図が良くわからないのですが。。。
iso-2022-jpでのcharsetでは英数字は含みます。

それから、RFC2047では、例えば "漢字file" というのは white-spaceで
区切られていないので、"=?iso-2022-jp?B?GyRCNEE7ehsoQg==?= file" と
してはダメで、=?iso-2022-jp?B?GyRCNEE7ehsoQmZpbGU=?= といっしょに
エンコードしなければなりません。そうしないと、decodeすると
 "漢字 file"となってしまうからです。
＃このへんはまじめに実装していないメーラーも多いのよね。

なので、半角がある個所で切れるわけではないです。


> base64って3bytesが4bytesになる勘定ですから、え～～っと、
> 76 から =?iso-2022-jp?B? と ?= の分だけ引いて、58。4で割って14と2余り(笑)
> 14かける3で42。エスケープシーケンスの分6bytesを引くと、36。2で割って18。
>
> 半角カナの全角化をしないですむような素直なEUCの文字列とすると、18文字で
> 切って8bit目を立て、前後をESC hogeではさみ、B encodeして余りの2バイトは
> paddingということになるでしょうか。はぁ大変…

そうやって逆向きに1発で計算しちゃおうとするとドツボにはまりますよ(^^;
適当な個所で切ってみて長ければ、短くする（ヘンな日本語）手順は
必ず必要だと思います。

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