[ruby-list:12840] Re: kconv SJIS

出沢です

dezawa> 風邪が収まって来たから、ちゃちゃ、っとかたづけて、JFのほうのチェックの
dezawa> 参加を目論んだんだが、なかなか一筋縄では行かないぞ。

一応出来たので、in.coming/mime.rb に置きました。
mime2.rb もあるけれどこれは没。

最後は力業でやってしまったので、美しさは気に入らないけれど。


class String への追加defineの形で書いています。
   string.encode64 で 変換文字列が返り
   string.decode64 で 復元文字列が返ります。
74Byte制限の為に追加された \n、\s はこの decode64 を通すと
削除されます。

これが RFC 通りかどうかは、御意見を。


Known BUG 一つ。
   B変換された文字列のあとに、B変換不要の文字列が続くと、１行長制限を越えて
   しまいます。
   変換されていない文字列間に改行を追加すると、その改行を復号時に削除
   出来ない為です。
	汚い手で、ごまかす方法は今思い付いたのですが、このケースは
	現実にはほとんど現れない様なので、とりあえずはこのままで。

BUGってほどではないけれど、、、
   １行制限のためにbase64変換すべき文字列が泣き別れすると、ここに日本語の
   SO SI が追加されます。それは decode64 では削除しません。
   復元された文字列を表示した時は、元と同じに見えますが、 Byte列としては、
   余分な SI SO が増えています。
   
   行長制限を満たす為の、プログラム上設けた制限数はチューンしてないので
   短か過ぎや、長すぎの可能性もあります。
   encode64 のoptional param で指定できます。

気持悪いけれど、、、
    変換文字列間の \s+ は１行長制限のために追加されたものとみなされ、復号時に
    削除されます。このためもともとの形が 「日本語文字\n\s*日本語文字」という
    ものを、行毎に変換を掛けると、復元時にこの \n\s* も削除されてしまいます。
    これを避ける為、\n\s* も含めて encode しました。ですから、このような
    行達の場合は、encodeされた文字列と、元の文字列とでは、改行位置が変わります。

    変換文字列の行末に、    という空の base64 が来る
    事があります。その直前が変換不要文字列で、直後に変換必要文字列が来る
    場合で、かつ、その文字列を入れると、行長制限を越える場合です。
    これは、直後の改行を、復号時に削除する為のおまじないです。
	これを用いて、Known BUG対策できるな、と思ったのですが、汚いよね。

と言う事で
dezawa> 1 長い日本文字が74Byteに収まらなくて、二つに分ける時、切れ目に 
dezawa>   si/so を追加する必要があるのであろうか？

追加した。これは復号時に削除されない。

dezawa>   1-3 じゃあ mew はどうなってるのか？と調べたら、Mew version 1.93b37 では
dezawa> 	混じりけ無しの日本語だけの時は、分けていなかった。。。

分けたぞ。

dezawa> 2 復元は大丈夫であろうか？？ と mew が複数行に分けてくれた(ASCII、space混じり)
dezawa>   のMIME化ものを nkf -m や Kconv してみたら、encode 間に入った \s は
dezawa>   残ったままだった。
dezawa>    → decode も必要か。。。。

decodeも作り直したぞ

dezawa> あれーーーー
dezawa>  Subject: あああlいいい  を mew したら
dezawa>  Subject: あああlいいい
dezawa> 
dezawa> だぞ、、、、 encode の前後に \s がない。
dezawa> 
dezawa> mewは私の MIME バイブルなのにー。。。。

これのケースは  "あああlいいい"  全体をencodeした。