[#10553] base64.rb — Sinichiro Dezawa <dezawa@...>

出沢です

92 messages 1998/11/01
[#10565] Re: base64.rb — Shin-ichiro Hara <sinara@...> 1998/11/01

原です。

[#10583] Re: base64.rb — matz@... (Yukihiro Matsumoto) 1998/11/02

まつもと ゆきひろです

[#10595] Re: base64.rb — Sinichiro Dezawa <dezawa@...> 1998/11/02

出沢です

[#10611] Re: base64.rb — Sinichiro Dezawa <dezawa@...> 1998/11/04

出沢です

[#10613] Re: base64.rb — matz@... (Yukihiro Matsumoto) 1998/11/04

まつもと ゆきひろです

[#10614] Re: base64.rb — Sinichiro Dezawa <dezawa@...> 1998/11/04

matz> kconvにかけるってのは反則ですか? 今のkconvはB-encodingをデ

[#10615] Re: base64.rb — Sinichiro Dezawa <dezawa@...> 1998/11/04

>あー、そんなのがあったのか。反則だ。

[#10616] Re: base64.rb — Sinichiro Dezawa <dezawa@...> 1998/11/04

dezawa> >あー、そんなのがあったのか。反則だ。

[#10617] Re: base64.rb — WATANABE Hirofumi <watanabe@...> 1998/11/04

わたなべです.

[#10618] Re: base64.rb — Sinichiro Dezawa <dezawa@...> 1998/11/04

watanabe> 何も指定しなくていいです. もともとは nkf で

[#10621] Re: base64.rb — matz@... (Yukihiro Matsumoto) 1998/11/04

まつもと ゆきひろです

[#10623] Re: base64.rb — Sinichiro Dezawa <dezawa@...> 1998/11/04

matz> エンコードにはpack("m")がお勧めなのかなあ.

[#10635] Re: base64.rb — Sinichiro Dezawa <dezawa@...> 1998/11/04

dezawa> 手を付け兼ねてるのは、

[#10642] Re: base64.rb — WATANABE Hirofumi <watanabe@...> 1998/11/05

わたなべです.

[#10648] Re: base64.rb — Sinichiro Dezawa <dezawa@...> 1998/11/05

watanabe> エスケープとか全部含めて encode する必要があります.

[#10654] Re: base64.rb — WATANABE Hirofumi <watanabe@...> 1998/11/05

わたなべです.

[#10659] Re: base64.rb — Sinichiro Dezawa <dezawa@...> 1998/11/05

watanabe> といろいろ問題はあるけど pack("m") は encode した結果が長く

[#10663] Re: base64.rb — WATANABE Hirofumi <watanabe@...> 1998/11/05

わたなべです.

[#10664] Re: base64.rb — Sinichiro Dezawa <dezawa@...> 1998/11/05

watanabe> 自前で細切れに処理しないとだめかな?

[#10672] Re: base64.rb — aamine@... 1998/11/05

あおきです。

[#10673] Re: base64.rb — Sinichiro Dezawa <dezawa@...> 1998/11/05

aamine> さらに難しくしてしまうのもなんなんですが

[#10702] Re: base64.rb — Sinichiro Dezawa <dezawa@...> 1998/11/07

出沢@フジフイルム です

[#10737] Re: base64.rb — aamine@... 1998/11/09

あおきです。

[#10741] Re: base64.rb — Sinichiro Dezawa <dezawa@...> 1998/11/09

すばやい

[#10796] Re: base64.rb — Sinichiro Dezawa <dezawa@...> 1998/11/13

出沢です

[#10800] Re: base64.rb — Shun-ichi GOTO <gotoh@...> 1998/11/13

後藤@太陽計測です

[#10801] Re: base64.rb — Toru Hoshina <toru@...> 1998/11/13

保科です。

[#10802] Re: base64.rb — Shun-ichi GOTO <gotoh@...> 1998/11/13

後藤@太陽計測です

[#10804] Re: base64.rb — Toru Hoshina <toru@...> 1998/11/13

保科です。

[#10806] Re: base64.rb — Shun-ichi GOTO <gotoh@...> 1998/11/13

後藤@太陽計測です

[#10676] 11/10 tokyo offline meeting — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

19 messages 1998/11/06

[#10697] Re: 11/10 tokyo offline meeting — KIMURA Koichi <kkimura@...>

35 messages 1998/11/07
[#10721] Re: 11/10 tokyo offline meeting — keiju@... (石塚圭樹 ) 1998/11/08

けいじゅ@日本ラショナルソフトウェアです.

[#10729] Re: 11/10 tokyo offline meeting — matz@... (Yukihiro Matsumoto) 1998/11/09

まつもと ゆきひろです

[#10738] Re: 11/10 tokyo offline meeting — keiju@... (石塚圭樹 ) 1998/11/09

けいじゅ@日本ラショナルソフトウェアです.

[#10743] Re: 11/10 tokyo offline meeting — ARIMA Yasuhiro <fit0298@...> 1998/11/09

Regard to "[ruby-list:10738] Re: 11/10 tokyo offline meeting"

[#10708] Re: 11/10 tokyo offline meeting — TEI meiki <tei@...> 1998/11/07

鄭です。

[#10709] Re: 11/10 tokyo offline meeting — Sinichiro Dezawa <dezawa@...> 1998/11/07

では 「やぐら茶屋」NSビル店 で一応決まりということで?

[#10713] Re: 11/10 tokyo offline meeting — TEI meiki <tei@...> 1998/11/07

鄭です。

[#10747] ruby 1.1c7 released — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

23 messages 1998/11/09

[#10904] ruby 1.1c8 released — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

16 messages 1998/11/17

[#10910] require error (tkutil.so -> tk.so) — ttate@...

立石です。

17 messages 1998/11/17
[#10924] Re: require error (tkutil.so -> tk.so) — matz@... (Yukihiro Matsumoto) 1998/11/18

まつもと ゆきひろです

[#10926] Re: require error (tkutil.so -> tk.so) — WATANABE Hirofumi <watanabe@...> 1998/11/18

わたなべです.

[#11054] ruby-list offline meeting at 11/27 — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

36 messages 1998/11/26
[#11056] Re: ruby-list offline meeting at 11/27 — Sinichiro Dezawa <dezawa@...> 1998/11/26

残念なのですが、出沢は無理そうです。

[#11057] Re: ruby-list offline meeting at 11/27 — matz@... (Yukihiro Matsumoto) 1998/11/26

まつもと ゆきひろです

[#11061] Re: ruby-list offline meeting at 11/27 — IWAMURO Motonori <iwa@...> 1998/11/26

岩室@富士通です。

[#11062] Re: ruby-list offline meeting at 11/27 — keiju@... (石塚圭樹 ) 1998/11/26

けいじゅ@日本ラショナルソフトウェアです.

[#11067] Re: ruby-list offline meeting at 11/27 — "D.Kanda" <MAP2303@...> 1998/11/26

[#11072] Re: ruby-list offline meeting at 11/27 — keiju@... (石塚圭樹 ) 1998/11/26

けいじゅ@日本ラショナルソフトウェアです.

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

From: Shun-ichi GOTO <gotoh@...>
Date: 1998-11-14 06:33:23 UTC
List: ruby-list #10826
後藤@太陽計測です

>>>>> at Sat, 14 Nov 1998 03:51:38 +0900
>>>>> 菊谷 <kikutani@sprintmail.com> said,
菊谷> mikekit1.1のISO2022JPという文書の電総研の佐藤さんの案は
菊谷> 分割エンコードして、なおかつ空白を保存できるうまい案だと
菊谷> 思うのですがいかがでしょう?

この方法は知ってはいました。けど、どうも納得しかねるんですよね。当時の
議論には参加していません(経過はあとで読んでみます)ので、文書だけ読んで
思うことは,,,

(1) この手法を考慮したもの同士なら、そしてひろくこの手法が使われれば結
    構幸せになれると思います。けど、そうでなければ空白問題に取り組まな
    いのと大差無いのではないかな?と感じます。というのは、先の例の "漢
    字file" のように、RFC-2047の枠内で無空白をNDに対して伝達できるケー
    スをも放棄してしまうからです。

    ※ これは、ISO2022JP文書をそのまんま実装し、それ以外の考慮をしない
        のであれば、の話しですが。

    分書中のA案「補足」にもあるように、佐藤さんは認識した上での提案だ
    ということですから、MIME-kitの汎用化のためは必要だったのだと思いま
    す。

(2) マジメにMIMEしようとすると、structured/non-structuredなどのフィー
    ルドによる判定や、structuredの場合はその構文/制限などを考慮しなけ
    ればならず、構文処理とEncode/Decodeを分離しにくいというのは、MIME
    の(RFC-822拡張の)ツライところなのだなぁ、と実感。ここらへんは各MUA
    でも悩みどころなのだと思うので、こういう統一的方法はうれしい。けど、
    現状はMIME-kitのみだし、JPローカルだし、(1)も気になるし。。。

(4) でも、ESCシーケンスに別の機能を持たせるというのは、ちょっとヤだな。
    rfc-2047に則ってもなおそれしか方法が無い(あるいは則りようが無い)
    というのならわかるけど。


菊谷> お、今探すとmimekit1.8なんてのがあるのか。
菊谷> ftp://etlport.etl.go.jp/pub/DeleGate/delegate5.7.4.tar.gz
菊谷> の中にあります。ISO2022JPは変わってませんね。

実装のほうまではみていませんが、文書は変わってないようですね。
#delegateはいつも便利に使わせていただいています。

きっと、delegateのように、ユーザ対話でない自動処理プログラムは、MUAと
は違った悩みを持つのだと想像します。MUAだと、エンコード時に不正なケー
スはユーザに警告なり確認なりを行えるタイミングがあり、そこで「送らない」
こともできるわけですが、delgateはそうもいかない。どんな入力がきても処
理しなければならないわけですし、ましてやdelegateはプロトコルも多彩です
ので、MIMEエンコーダ部分の各プロトコルからの分離独立は重要なのでしょう。

「制約」と「一般化」の狭間で明確な線が引ないのは、ツライということか。。。



で、話しはrubyに戻って、rubyでのbase64.rbはどーあるべきかというと、よ
くわかりませんけど、題材としては、FLIM(emacs-lisp)の ruby化、
mime-kit(C言語)のruby化というのもありますね。どちらも結構独立したパッ
ケージなので、ruby-module化も可能のような気がします。
#気のせいかもしれませんが (^^;

先人たちの知恵の集結であるコードを放棄してしまうのはもったいないですし。
RFC-2047がしっかりしていない(?)以上、1から作るのはツライし。

どーでしょーかぁ

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

In This Thread