From ari ＠ atesoft.advantest.co.jp Mon Apr 9 14:21:09 2001 From: ari ＠ atesoft.advantest.co.jp (Akihiro Arisawa) Date: 09 Apr 2001 14:21:09 +0900 Subject: std11-lexical-analyze Message-ID: <7te7l0ufy2i.fsf@puyo.mei9.advantest.co.jp> (std11-lexical-analyze (encode-coding-string "日本語" 'iso-2022-jp) mime-lexical-analyzer) を評価した時に、(wrong-type-argument number-or-marker-p (13)) とエラーが発生します。 Index: std11.el =================================================================== RCS file: /cvs/root/flim/std11.el,v retrieving revision 1.7.8.4 diff -u -F^( -r1.7.8.4 std11.el --- std11.el 2000/12/15 03:42:27 1.7.8.4 +++ std11.el 2001/04/09 05:18:00 @@ -396,7 +396,7 @@ (defun std11-lexical-analyze (string &op (null (setq r (funcall func string start)))) (setq rest (cdr rest))) (or r - (list (cons 'error (substring string start)) (1+ len))) + (cons (cons 'error (substring string start)) (1+ len))) )) (setq dest (cons (car ret) dest) start (cdr ret)) ではないかと思うのですが、問題なければ CVS commit いたします。 -- 有沢明宏 From yamaoka ＠ jpl.org Mon Apr 9 17:01:50 2001 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: 09 Apr 2001 17:01:50 +0900 Subject: std11-lexical-analyze References: <7te7l0ufy2i.fsf@puyo.mei9.advantest.co.jp> Message-ID: >>>>> In [emacs-mime-ja : No.00833] >>>>> ari ＠ atesoft.advantest.co.jp (Akihiro Arisawa) wrote: > (std11-lexical-analyze (encode-coding-string "日本語" 'iso-2022-jp) > mime-lexical-analyzer) 有沢さん> を評価した時に、(wrong-type-argument number-or-marker-p (13)) 有沢さん> とエラーが発生します。 > --- std11.el 2000/12/15 03:42:27 1.7.8.4 > +++ std11.el 2001/04/09 05:18:00 > - (list (cons 'error (substring string start)) (1+ len))) > + (cons (cons 'error (substring string start)) (1+ len))) 有沢さん> ではないかと思うのですが、だいぶ以前にもこの話がありましたが、std11.el が想定している普通の使い方、すなわち一般的なメッセージヘッダに含まれる文字列の parse ではここは通らないから放っておこう、という結末になったような記憶があります。有沢さん> 問題なければ CVS commit いたします。明かにバグだと思うので、修正するのが素直な対応であると個人的には思います。:-) -- Katsumi Yamaoka From ari ＠ atesoft.advantest.co.jp Mon Apr 9 19:35:22 2001 From: ari ＠ atesoft.advantest.co.jp (Akihiro Arisawa) Date: 09 Apr 2001 19:35:22 +0900 Subject: std11-lexical-analyze In-Reply-To: (Katsumi Yamaoka's message of "09 Apr 2001 17:01:50 +0900") References: <7te7l0ufy2i.fsf@puyo.mei9.advantest.co.jp> Message-ID: <7telmpae4yd.fsf@puyo.mei9.advantest.co.jp> >>>>> In [emacs-mime-ja : No.00834] >>>>> yamaoka ＠ jpl.org (Katsumi Yamaoka) wrote: 山岡> だいぶ以前にもこの話がありましたが、std11.el が想定している普通の使い山岡> 方、すなわち一般的なメッセージヘッダに含まれる文字列の parse ではここ山岡> は通らないから放っておこう、という結末になったような記憶があります。添付ファイルのファイル名が生 JIS だった時というのは、やはり想定外なんでしょうね(^^; -------------- next part -------------- 添付ファイル -------------- next part -------------- -- 有沢明宏 From ari ＠ atesoft.advantest.co.jp Tue Apr 10 14:05:46 2001 From: ari ＠ atesoft.advantest.co.jp (Akihiro Arisawa) Date: 10 Apr 2001 14:05:46 +0900 Subject: std11-lexical-analyze In-Reply-To: <7telmpae4yd.fsf@puyo.mei9.advantest.co.jp> (Akihiro Arisawa's message of "09 Apr 2001 19:35:22 +0900") References: <7te7l0ufy2i.fsf@puyo.mei9.advantest.co.jp> <7telmpae4yd.fsf@puyo.mei9.advantest.co.jp> Message-ID: <7telmp9s5sl.fsf@puyo.mei9.advantest.co.jp> >>>>> In [emacs-mime-ja : No.00835] >>>>> ari ＠ atesoft.advantest.co.jp (Akihiro Arisawa) wrote: > 添付ファイルのファイル名が生 JIS だった時というのは、やはり > 想定外なんでしょうね(^^; > Content-Disposition: attachment; filename=日本語 flim-1_14 では、ここでエラーにはならないのですね(^^; ;; flim-1_14-rfc2231 だと、`mime-parse-Content-Disposition' から ;; mime-lexical-analyze を実行するところでエラーになりました。 -- 有沢明宏 From shuhei ＠ aqua.ocn.ne.jp Tue Apr 10 20:46:08 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 10 Apr 2001 20:46:08 +0900 Subject: std11-lexical-analyze References: <7te7l0ufy2i.fsf@puyo.mei9.advantest.co.jp> <7telmpae4yd.fsf@puyo.mei9.advantest.co.jp> <7telmp9s5sl.fsf@puyo.mei9.advantest.co.jp> Message-ID: <861yr1t1tr.fsf@aqua.ocn.ne.jp> ;; 召喚されました. >>>>> In <7telmp9s5sl.fsf ＠ puyo.mei9.advantest.co.jp>, >>>>> ari ＠ atesoft.advantest.co.jp (Akihiro Arisawa) wrote: > > 添付ファイルのファイル名が生 JIS だった時というのは、やはり > > 想定外なんでしょうね(^^; > > Content-Disposition: attachment; filename=日本語 > flim-1_14 では、ここでエラーにはならないのですね(^^; あ, やっぱり. 問題になったのは mew-dist に流れた mail だと思うのですが, 有沢さんだけが話題にしていたので, きっと flim-1_14-rfc2231 関連だと思っていました. > ;; flim-1_14-rfc2231 だと、`mime-parse-Content-Disposition' から > ;; mime-lexical-analyze を実行するところでエラーになりました。実際には私は comment out してある方の mime-lexical-analyze を使っていたのですが, error どころか無限 loop になってしまいました. ;; ので, そっちの修正だけ昨夜のうちに commit しました(^^; >>>>> In , >>>>> Katsumi Yamaoka wrote: > > - (list (cons 'error (substring string start)) (1+ len))) > > + (cons (cons 'error (substring string start)) (1+ len))) > だいぶ以前にもこの話がありましたが、std11.el が想定している普通の使い > 方、すなわち一般的なメッセージヘッダに含まれる文字列の parse ではここ > は通らないから放っておこう、という結末になったような記憶があります。そうなんでしたっけ? 全然記憶に残ってないです. ともかくこの patch はあてましょう. -- Shuhei KOBAYASHI From yamaoka ＠ jpl.org Wed Apr 11 07:37:47 2001 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: 11 Apr 2001 07:37:47 +0900 Subject: std11-lexical-analyze References: <7te7l0ufy2i.fsf@puyo.mei9.advantest.co.jp> <7telmpae4yd.fsf@puyo.mei9.advantest.co.jp> <7telmp9s5sl.fsf@puyo.mei9.advantest.co.jp> <861yr1t1tr.fsf@aqua.ocn.ne.jp> Message-ID: >>>>> In [emacs-mime-ja : No.00837] >>>>> Shuhei KOBAYASHI wrote: 山岡> だいぶ以前にもこの話がありましたが、std11.el が想定している普通山岡> の使い方、すなわち一般的なメッセージヘッダに含まれる文字列の山岡> parse ではここは通らないから放っておこう、という結末になったよう山岡> な記憶があります。小林さん> そうなんでしたっけ? 全然記憶に残ってないです. ごめんなさい、ここではなくて utf-2000 ＠ m17n.org だったかもしれません。小林さん> ともかくこの patch はあてましょう. 有沢さん commit ありがとうございます。実はここからが本題なのですが、ChangeLog の日付はやはり UT にしませんか? 日本では現在 4月11日ですが、committer の一人である市川さんを含めて、世界のかなりの領域ではまだ 4月10日ですんで。 ;; ぼくはパッチを作る目的のために、端末の TZ を UT にしています。 -- Katsumi Yamaoka From ari ＠ atesoft.advantest.co.jp Wed Apr 11 12:51:42 2001 From: ari ＠ atesoft.advantest.co.jp (Akihiro Arisawa) Date: 11 Apr 2001 12:51:42 +0900 Subject: std11-lexical-analyze In-Reply-To: <861yr1t1tr.fsf@aqua.ocn.ne.jp> (Shuhei KOBAYASHI's message of "10 Apr 2001 20:46:08 +0900") References: <7te7l0ufy2i.fsf@puyo.mei9.advantest.co.jp> <7telmpae4yd.fsf@puyo.mei9.advantest.co.jp> <7telmp9s5sl.fsf@puyo.mei9.advantest.co.jp> <861yr1t1tr.fsf@aqua.ocn.ne.jp> Message-ID: <7tevgocqek1.fsf@puyo.mei9.advantest.co.jp> >>>>> In [emacs-mime-ja : No.00837] >>>>> shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) wrote: > ;; 召喚されました. どうもありがとうございます(^^; > > > Content-Disposition: attachment; filename=日本語 > > flim-1_14 では、ここでエラーにはならないのですね(^^; > 問題になったのは mew-dist に流れた mail だと思うのですが, 有沢さんだけ > が話題にしていたので, きっと flim-1_14-rfc2231 関連だと思っていました. まさにその通りです。 flim-1_14-rfc2231 を使っている人は多くは無いのでしょうか…。 -------------- next part -------------- ;; 手で入れたのでおかしいかもしれません。 -------------- next part -------------- > 実際には私は comment out してある方の mime-lexical-analyze を使って > いたのですが, error どころか無限 loop になってしまいました. > ;; ので, そっちの修正だけ昨夜のうちに commit しました(^^; ;; ChangeLog を見たときにそうではないかと思いました:-) > ともかくこの patch はあてましょう. ということで、flim-1_14 と flim-1_14-rfc2231 に commit しました。 >>>>> In [emacs-mime-ja : No.00838] >>>>> yamaoka ＠ jpl.org (Katsumi Yamaoka) wrote: 山岡> 実はここからが本題なのですが、ChangeLog の日付はやはり UT にしま山岡> せんか? 日本では現在 4月11日ですが、committer の一人である市川山岡> さんを含めて、世界のかなりの領域ではまだ 4月10日ですんで。おっと、すみません。のちほど修正しておきます。山岡> ;; ぼくはパッチを作る目的のために、端末の TZ を UT にしています。そこまではできないので(^^;、とりあえず .emacs で適当に対処してみます。 (defadvice add-change-log-entry (around change-timezone activate) (let ((tz (getenv "TZ"))) (setenv "TZ" "UTC") ad-do-it (setenv "TZ" tz))) -- 有沢明宏 From shuhei ＠ aqua.ocn.ne.jp Wed Apr 11 20:28:58 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 11 Apr 2001 11:28:58 +0000 Subject: std11-lexical-analyze References: <7te7l0ufy2i.fsf@puyo.mei9.advantest.co.jp> <7telmpae4yd.fsf@puyo.mei9.advantest.co.jp> <7telmp9s5sl.fsf@puyo.mei9.advantest.co.jp> <861yr1t1tr.fsf@aqua.ocn.ne.jp> <7tevgocqek1.fsf@puyo.mei9.advantest.co.jp> Message-ID: <86hezvsmit.fsf@aqua.ocn.ne.jp> >>>>> In <7tevgocqek1.fsf ＠ puyo.mei9.advantest.co.jp>, >>>>> ari ＠ atesoft.advantest.co.jp (Akihiro Arisawa) wrote: > [2 iso-2022-jp''%1b$B0l%3b~$N%1b%28B%20utf-8%20%1b$B$N%3bH$$J}$N$h$&$KN.9T$i$J$$$+$J%1b%28B%28^^%3b ] > > ;; 手で入れたのでおかしいかもしれません。御覧のように flim-1_14-rfc2231 では decode できなかったのですが, encode が間違っているのかどうかは断言できないことに気付きました. RFC 2231 (MIME Parameter Value and Encoded Word Extensions) では | ext-octet := "%" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") となっていて, 一見すると uppercase 限定のように見えるのですが, RFC 2234 (Augmented BNF for Syntax Specifications: ABNF) には | NOTE: ABNF strings are case-insensitive and | the character set for these strings is us-ascii. と書かれていて, uppercase 限定の場合には ext-octet := "%" 2(DIGIT / %x41 / %x42 / %x43 / %x44 / %x45 / %x46) のようになっていなければいけないんですね. さて, 問題は RFC 2231 が RFC 2234 を採用しているかどうかなのですが... ;; 両者はほぼ同時に発行されていますが, RFC 2231 の References には ;; RFC 2234 は挙がっていないので, 採用されていないのだと思います. それはともかく, quoted-printable と同様に, decode 時には lowercase を許容した方が良さそうですね. -- Shuhei KOBAYASHI From shuhei ＠ localhost.localdomain Sun Apr 15 15:24:19 2001 From: shuhei ＠ localhost.localdomain (shuhei ＠ localhost.localdomain) Date: 15 Apr 2001 06:24:19 -0000 Subject: std11-lexical-analyze References: <200002191744.CAA19653@mail.ba2.so-net.ne.jp> Message-ID: <20010415062419.51284.qmail@elizabeth.localdomain> <7te7l0ufy2i.fsf ＠ puyo.mei9.advantest.co.jp> BCC: shuhei ＠ aqua.ocn.ne.jp From: Shuhei KOBAYASHI Date: 15 Apr 2001 15:24:19 +0900 Message-ID: <86u23qd6jw.fsf ＠ aqua.ocn.ne.jp> Lines: 37 >>>>> In <7te7l0ufy2i.fsf ＠ puyo.mei9.advantest.co.jp>, >>>>> ari ＠ atesoft.advantest.co.jp (Akihiro Arisawa) wrote: > diff -u -F^( -r1.7.8.4 std11.el > --- std11.el 2000/12/15 03:42:27 1.7.8.4 > +++ std11.el 2001/04/09 05:18:00 > @@ -396,7 +396,7 @@ (defun std11-lexical-analyze (string &op > (null (setq r (funcall func string start)))) > (setq rest (cdr rest))) > (or r > - (list (cons 'error (substring string start)) (1+ len))) > + (cons (cons 'error (substring string start)) (1+ len))) > )) > (setq dest (cons (car ret) dest) > start (cdr ret)) [emacs-mime-ja:00425] (Date: Sun, 20 Feb 2000 02:44:14 +0900) にて eword-decode.el (eword-lexical-analyze-internal) に対する同様の patch が出されていたのを発掘して flim-1_14, flim-1_14-rfc2231, clime-1_14 に適用しました. >>>>> In <200002191744.CAA19653 ＠ mail.ba2.so-net.ne.jp>, >>>>> SANETO Takanori wrote: > diff -u -r1.16 eword-decode.el > --- eword-decode.el 1999/05/31 09:41:49 1.16 > +++ eword-decode.el 2000/02/19 17:31:18 > @@ -755,7 +755,7 @@ > ) > (setq rest (cdr rest))) > (or r > - (list (cons 'error (substring string start)) (1+ len))) > + (cons (cons 'error (substring string start)) (1+ len))) > )) > (setq dest (cons (car ret) dest) > start (cdr ret)) -- Shuhei KOBAYASHI From ysjj ＠ unixuser.org Tue Apr 17 19:00:42 2001 From: ysjj ＠ unixuser.org (YAMASHITA Junji (=?ISO-2022-JP?B?GyRCOzMyPBsoQiAbJEI9YztKGyhC?=)) Date: Tue, 17 Apr 2001 19:00:42 +0900 Subject: mime-browse-url-regexp and https Message-ID: <87heznx2ut.wl@fine.do-johodai.ac.jp> 山下純司です。 semi-def.el で定義されている mime-browse-url-regexp が https を認識しません。なので、以下の修正を提案します。 (defcustom mime-browse-url-regexp - (concat "\$http\\|ftp\\|file\\|gopher\\|news\\|telnet\\|wais\\|mailto\$:" + (concat "\$https?\\|ftp\\|file\\|gopher\\|news\\|telnet\\|wais\\|mailto\$:" "\$//[-a-zA-Z0-9_.]+:[0-9]*\$?" 以上、御考慮願います。 P.S. Subject: mime-bbdb.el (bbdb-extract-field-value) X-ML-Name: emacs-mime-ja X-Mail-Count: 00799 に全く反応がないのですが、忘れられているのでしょうか… もし、このメールと共に、この ML にそぐわない話題でしたらすみません。 -- 山下純司 mailto:ysjj ＠ unixuser.org From yamaoka ＠ jpl.org Tue Apr 17 21:29:19 2001 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: 17 Apr 2001 21:29:19 +0900 Subject: mime-browse-url-regexp and https References: <87heznx2ut.wl@fine.do-johodai.ac.jp> Message-ID: >>>>> In [emacs-mime-ja : No.00842] >>>>> YAMASHITA Junji (山下純司) wrote: 山下さん> semi-def.el で定義されている mime-browse-url-regexp が https 山下さん> を認識しません。なので、以下の修正を提案します。山下さん> (defcustom mime-browse-url-regexp 山下さん> - (concat "\$http\\|ftp\\|file\\|gopher\\|news\\|telnet... 山下さん> + (concat "\\(https?\\|ftp\\|file\\|gopher\\|news\\|teln... 山下さん> "\\(//[-a-zA-Z0-9_.]+:[0-9]*\$?" 僭越ながら semi-1_14 枝 (と wemi) に apply させていただきました。 2001-04-17 YAMASHITA Junji * semi-def.el (mime-browse-url-regexp): Allow https. 山下さん> Subject: mime-bbdb.el (bbdb-extract-field-value) 山下さん> X-ML-Name: emacs-mime-ja 山下さん> X-Mail-Count: 00799 山下さん> に全く反応がないのですが、忘れられているのでしょうか… いまだに BBDB のことはよくわからないのですが、拝見し直しました。現行の mime-bbdb.el によれば `bbdb-hooks' は provide されていない。 `bbdb-extract-field-value' は aotoload になっている。そのため `bbdb-header-start' が無かったら "bbdb-hooks" を load となっていますが、CVS latest な BBDB を見ると `bbdb-hooks' は provide されている。 `bbdb-extract-field-value' は aotoload になっていない。という状況です。また、山下さんが X-Mail-Count: 00799 でおっしゃっているように `bbdb-header-start' は aotoload になっています。これに限らず BBDB はいろんなものが ChangeLog に明記されずにコロコロ変わるようで、こういうものを相手にするのは辛いですね。素人なりに考えてみたのですが、こういうのではいかがでしょうか? (or (and (fboundp 'bbdb-header-start) (fboundp 'bbdb-extract-field-value)) (load "bbdb-hooks")) ;; 両方 autoload になっている BBDB の版があったらだめか。(^^;;) -- Katsumi Yamaoka From ysjj ＠ unixuser.org Wed Apr 18 21:20:37 2001 From: ysjj ＠ unixuser.org (YAMASHITA Junji (=?ISO-2022-JP?B?GyRCOzMyPBsoQiAbJEI9YztKGyhC?=)) Date: Wed, 18 Apr 2001 21:20:37 +0900 Subject: mime-browse-url-regexp and https In-Reply-To: References: <87heznx2ut.wl@fine.do-johodai.ac.jp> Message-ID: <87eluqo0ve.wl@fine.do-johodai.ac.jp> 山下純司です。 >>>17 Apr 2001 21:29:19 +0900 の刻に、 >>>Subject: Re: mime-browse-url-regexp and https >>>において Katsumi Yamaoka氏曰く >>>(以下、山岡さん == Katsumi Yamaoka氏) (snip) 山岡さん>僭越ながら semi-1_14 枝 (と wemi) に apply させていただきました。ありがとうございます。 (snip) 山岡さん> (or (and (fboundp 'bbdb-header-start) 山岡さん> (fboundp 'bbdb-extract-field-value)) 山岡さん> (load "bbdb-hooks")) 山岡さん>;; 両方 autoload になっている BBDB の版があったらだめか。(^^;;) 現在、私が使ってる bbdb のバージョンは Debian(unstable) の package にある 2.3 なのですが、まさに両方 autoload になっています。 ;; バージョン決め打ちのコードは確かに見苦しいのですが… -- 山下純司 mailto:ysjj ＠ unixuser.org From yamaoka ＠ jpl.org Thu Apr 19 07:54:48 2001 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: 19 Apr 2001 07:54:48 +0900 Subject: mime-bbdb.el (bbdb-extract-field-value) References: <87heznx2ut.wl@fine.do-johodai.ac.jp> <87eluqo0ve.wl@fine.do-johodai.ac.jp> Message-ID: >>>>> In [emacs-mime-ja : No.00844] >>>>> 山下純司さん wrote: 山岡> (or (and (fboundp 'bbdb-header-start) 山岡> (fboundp 'bbdb-extract-field-value)) 山岡> (load "bbdb-hooks")) 山岡>;; 両方 autoload になっている BBDB の版があったらだめか。(^^;;) 山下さん> 現在、私が使ってる bbdb のバージョンは Debian(unstable) の山下さん> package にある 2.3 なのですが、まさに両方 autoload になって山下さん> います。おおっと、bbdb-autoloads.el の存在を忘れていました。かくなる上はくだんの部分は以下のようにしたらどうでしょう? (or (fboundp 'tm:bbdb-extract-field-value) (progn (or (and (fboundp 'bbdb-extract-field-value) (not (eq 'autoload (car-safe (symbol-function 'bbdb-extract-field-value))))) (condition-case nil (require 'bbdb-hooks) (error (load "bbdb-hooks")))) (fset 'tm:bbdb-extract-field-value (symbol-function 'bbdb-extract-field-value)) (defun bbdb-extract-field-value (field) (let ((value (tm:bbdb-extract-field-value field))) (and value (eword-decode-string value)))) )) -- Katsumi Yamaoka From ysjj ＠ unixuser.org Thu Apr 19 13:51:10 2001 From: ysjj ＠ unixuser.org (YAMASHITA Junji (=?ISO-2022-JP?B?GyRCOzMyPBsoQiAbJEI9YztKGyhC?=)) Date: Thu, 19 Apr 2001 13:51:10 +0900 Subject: mime-bbdb.el (bbdb-extract-field-value) In-Reply-To: References: <87heznx2ut.wl@fine.do-johodai.ac.jp> <87eluqo0ve.wl@fine.do-johodai.ac.jp> Message-ID: <87y9sxeblt.wl@fine.do-johodai.ac.jp> 山下純司です。 >>>19 Apr 2001 07:54:48 +0900 の刻に、 >>>Subject: Re: mime-bbdb.el (bbdb-extract-field-value) >>>において Katsumi Yamaoka氏曰く >>>(以下、山岡さん == Katsumi Yamaoka氏) (snip) 山岡さん>おおっと、bbdb-autoloads.el の存在を忘れていました。かくなる上は山岡さん>くだんの部分は以下のようにしたらどうでしょう? (snip) なるほど… 手元の環境でしか動作確認していませんが、多分これでよいと思います。ありがとうございました。 -- 山下純司 mailto:ysjj ＠ unixuser.org From shuhei ＠ aqua.ocn.ne.jp Thu Apr 19 17:05:54 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 19 Apr 2001 17:05:54 +0900 Subject: std11-lexical-analyze References: <86k8na8bk4.fsf@aqua.ocn.ne.jp> <86hficoqc7.fsf@aqua.ocn.ne.jp> <86yabldk3a.fsf_-_@aqua.ocn.ne.jp> <7tevgocqek1.fsf@puyo.mei9.advantest.co.jp> <86hezvsmit.fsf@aqua.ocn.ne.jp> Message-ID: <868zkx1fh9.fsf@aqua.ocn.ne.jp> >>>>> In <86hezvsmit.fsf ＠ aqua.ocn.ne.jp>, >>>>> Shuhei KOBAYASHI wrote: > 御覧のように flim-1_14-rfc2231 では decode できなかったのですが, > encode が間違っているのかどうかは断言できないことに気付きました. 著者に尋ねたら, ABNF によれば `ext-octet' は case-insensitive だと言われましたので, comment を修正しました. また, [emacs-mime-ja:00149, 00151, 00165] への対応を改善しました. ;; 次のような例は他の実装ではどのように decode されるのでしょうか? -- Shuhei KOBAYASHI -------------- next part -------------- foo%62%61%72.txt From shuhei ＠ aqua.ocn.ne.jp Sun Apr 22 11:33:12 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 22 Apr 2001 11:33:12 +0900 Subject: m17n CVS: commit by shuhei: /cvs/root/flim: ;;; mime-parse.el --- MIME message parser References: <987686961.24384.1@cvs.m17n.org> <987906427.29218.1@cvs.m17n.org> Message-ID: <86ae593bpz.fsf@aqua.ocn.ne.jp> こばやしです. ごめんなさい. cvs commit の引数を間違えて, mime-parse.el の全体を mime-parse.el の log として commit してしまいました. 可能でしたら以下の内容を log として差し替えてもらえませんか? (mime-parse-Content-Disposition): Add description of return value to the docstring. (mime-parse-Content-Transfer-Encoding): Ditto. -- Shuhei KOBAYASHI From akr ＠ m17n.org Mon Apr 23 13:42:35 2001 From: akr ＠ m17n.org (Tanaka Akira) Date: 23 Apr 2001 13:42:35 +0900 Subject: m17n CVS: commit by shuhei: /cvs/root/flim: ;;; mime-parse.el --- MIME message parser In-Reply-To: <86ae593bpz.fsf@aqua.ocn.ne.jp> (Shuhei KOBAYASHI's message of "22 Apr 2001 11:33:12 +0900") References: <987686961.24384.1@cvs.m17n.org> <987906427.29218.1@cvs.m17n.org> <86ae593bpz.fsf@aqua.ocn.ne.jp> Message-ID: In article <86ae593bpz.fsf ＠ aqua.ocn.ne.jp>, Shuhei KOBAYASHI writes: > 可能でしたら以下の内容を log として差し替えてもらえませんか? > > (mime-parse-Content-Disposition): Add description of return value to the docstring. > (mime-parse-Content-Transfer-Encoding): Ditto. やっときました。cvs admin -m を使うのは生まれてこのかた 2回めです。 -- [田中哲][たなかあきら][Tanaka Akira] 「ふえろ! わかめちゃん作戦です?」(Little Worker, 桂遊生丸) From ichikawa ＠ jpl.org Wed Apr 25 13:19:57 2001 From: ichikawa ＠ jpl.org (Tatsuya Ichikawa) Date: 24 Apr 2001 23:19:57 -0500 Subject: How to handle S/MIME on Emacs (Gnus/SEMI/FLIM...) Message-ID: 市川です。時代の流れと言うか何と言うか、社内でのメールにいよいよ暗号化メールが採用される事になり、それが何と S/MIME (PGP ぢゃ無い)何です。所で、Gnus/SEMI/FLIM 等から S/MIME message を扱うためには、私なりに調べたんですが 1. SEMI Variants で対応しているものは EMIKO/EMY がある 2. smime tool が必要 (http://www.bacus.pt/Net_SSLeay/smime.html) 3. smime tool をcompile するのに OpenSSL http://www.openssl.org/ Cons http://www.dsmit.com/cons/ が必要… とまでは分かりました。現状、EMY を利用しているんですが、これで S/MIME の message を扱った実績はあるんでしょうか? それと、扱うための Document はありますか? -- Tatsuya - Tim - Ichikawa From shuhei ＠ aqua.ocn.ne.jp Fri Apr 27 22:27:04 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 27 Apr 2001 22:27:04 +0900 Subject: Why `capitalize' twice? Message-ID: <86u23axyl3.fsf@aqua.ocn.ne.jp> 前々から気になっていたのですが, `(capitalize (capitalize field-name))' のように capitalize を二度行なうのは何のおまじないなのでしょうか? (capitalize "content-type") => "Content-Type" (capitalize "Content-Type") => "Content-Type" | % cd flim-1_14 | % grep -n -e capitalize *.el [...] | mime.el:335: (intern (capitalize (capitalize field-name)))))) | mmbuffer.el:178: (intern (capitalize (capitalize field-name))))) | mmexternal.el:160: (intern (capitalize (capitalize field-name))))) | mmgeneric.el:62: (setq field-name (intern (capitalize (capitalize field-name))))) [...] flim-1_14, flim-1_14-rfc2231, clime-1_14 に対する修正を commit します. -- Shuhei KOBAYASHI From shuhei ＠ aqua.ocn.ne.jp Sun Apr 29 13:56:04 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 29 Apr 2001 13:56:04 +0900 Subject: flim-1_13-rfc2231 vs flim-1_14-rfc2231 (Re: flim-1_14-rfc2231) References: <86pug42otj.fsf@aqua.ocn.ne.jp> Message-ID: <861yqc9ue3.fsf@aqua.ocn.ne.jp> FLIM の RFC 2231 対応の main trunk への merge を検討しているのですが... >>>>> In <86pug42otj.fsf ＠ aqua.ocn.ne.jp>, >>>>> Shuhei KOBAYASHI wrote: > 中身は FLIM 1.14.2 + parameter value decoder ですが, > flim-1_13-rfc2231 とは異なる実装となっています. "cvs rdiff -rflim-1_13 -rflim-1_13-rfc2231 flim" の出力によると, flim-1_13-rfc2231 では以下の変更が行なわれているようです. 1. RFC 2231 とは無関係なもの. a. 関数 mime-entity-root. (FLIM 1.14 での mime-find-root-entity) b. eword-decode の structured-field 系 decoder が parse に失敗した場合に unstructured-field として強制的に decode する. 2. encoded-word の RFC 2231 対応. * encoded-word に language info が含まれていた場合, decode 結果の `mime-language' text-property (symbol) とする. 3. parameter value の RFC 2231 対応. * decode は lazy に行なう. * language info は `mime-language' text-property (symbol) とする. (mime-parse-Content-Type "application/x-stuff; title*0*=us-ascii'en'This%20is%20even%20more%20; title*1*=%2A%2A%2Afun%2A%2A%2A%20; title*2=\"isn't it!\"") => ((type . application) (subtype . x-stuff) ("title" . [en us-ascii ((0 t . "This%20is%20even%20more%20") (1 t . "%2A%2A%2Afun%2A%2A%2A%20") (2 nil . "isn't it!")) nil])) (mime-content-type-parameter (mime-parse-Content-Type "application/x-stuff; title*0*=us-ascii'en'This%20is%20even%20more%20; title*1*=%2A%2A%2Afun%2A%2A%2A%20; title*2=\"isn't it!\"") "title") => #("This is even more %2A%2A%2Afun%2A%2A%2A isn't it!" ; XXX 0 49 (mime-language en)) flim-1_14-rfc2231 では 2. と 3. の対応を行なっています. ただし 3. は, 「そんなの lazy に decode することないじゃん」という判断から eager に decode を行ないます. (mime-parse-Content-Type "application/x-stuff; title*0*=us-ascii'en'This%20is%20even%20more%20; title*1*=%2A%2A%2Afun%2A%2A%2A%20; title*2=\"isn't it!\"") => ((type . application) (subtype . x-stuff) ("title" . #("This is even more ***fun*** isn't it!" 0 37 (mime-language en)))) このため flim-1_13-rfc2231 とは異なり, API の拡張[*]は不要になっています. -- Shuhei KOBAYASHI -------------- next part -------------- (benchmark 100 ...) を 16 回計測した結果の平均値の相対値. 1. 通常の plain text の Content-Type. (mime-content-type-parameter (mime-parse-Content-Type "text/plain; charset=\"iso-2022-jp\"") "charset") 1.1. gc-cons-threshold を事実上無限大にした場合. FLIM 1.14 vanilla: 1.00 FLIM 1.13 rfc2231: 3.15 FLIM 1.14 rfc2231: 3.90 1.2 gc-cons-threshold を 400000 (19.29 以降の初期値)にした場合. FLIM 1.14 vanilla: 1.00 FLIM 1.13 rfc2231: 2.68 FLIM 1.14 rfc2231: 3.25 1.3 gc-cons-threshold を 100000 (19.28 までの初期値)にした場合. FLIM 1.14 vanilla: 1.00 FLIM 1.13 rfc2231: 1.79 FLIM 1.14 rfc2231: 1.60 2. parameter の数が多い場合. (gc-cons-threshold は 400000) (mime-parse-Content-Type "Message/External-body; name=\"rfc2822.txt\"; site=\"ftp.isi.edu\"; access-type=\"anon-ftp\"; directory=\"in-notes\"") FLIM 1.14 vanilla: 1.00 FLIM 1.13 rfc2231: 2.25 FLIM 1.14 rfc2231: 1.82 3. RFC 2231 の parameter value の decode. (gc-cons-threshold は 400000) (mime-content-type-parameter (mime-parse-Content-Type "application/x-stuff; title*0*=us-ascii'en'This%20is%20even%20more%20; title*1*=%2A%2A%2Afun%2A%2A%2A%20; title*2=\"isn't it!\"") "title") FLIM 1.14 vanilla: ---- FLIM 1.13 rfc2231: 1.00 FLIM 1.14 rfc2231: 1.34 結論: 1 回の処理は flim-1_13-rfc2231 の方が高速だが, resource の消費量が多いと思われ, 実際の使用においては flim-1_14-rfc2231 の方が処理時間が少なくなると思われる. 実際, 数百通の mail を読む場合を ELP で測定すると flim-1_14- rfc2231 の方が速い*こともある*. ;; 測定結果のバラツキが大きくて ELP による比較を諦めたというのが真相(^^; decoder は使用頻度が低いと思われるので, この速度差は許容範囲と考える. 備考: vanilla FLIM 1.14 の mime-parse-Content-Type では media-type, parameter list 共に正規表現による pattern match で取り出している. flim-1_13-rfc2231 では media-type には正規表現による pattern match を使用するが, parameter list の方は lexical-analyze & parse を行なっている. flim-1_14-rfc2231 では field-body 全体を lexical-analyze & parse している. よって, flim-1_14-rfc2231 以外では, 変な位置に comment が入ると誤動作する. ;; でも, "Content-Type: (type) text / (subtype) plain" みたいなのが実際に ;; 使われるかは疑問なので, ほとんど問題にはならないはず. From shuhei ＠ aqua.ocn.ne.jp Sun Apr 29 15:24:39 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 29 Apr 2001 15:24:39 +0900 Subject: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231) References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> Message-ID: <86pudw8bq0.fsf_-_@aqua.ocn.ne.jp> >>>>> In <86vgno8cu0.fsf_-_ ＠ aqua.ocn.ne.jp>, >>>>> Shuhei KOBAYASHI wrote: > Q2-1. 現在の FLIM 1.14 実装とは `mime-content-type' の構造が異なって > いますが, これは FLIM 1.14 実装の bug なのでしょうか? [...] > Q3. `make-mime-content-type' は API に含まれないのですか? > `make-mime-content-disposition' は? (現在の FLIM 1.14 実装では未定義) Wanderlust に `mime-content-type' 型を直接いじっている箇所があるので, `mime-content-type' 型の構造は容易には変更できませんね. | grep -n -e "'type" *.el /dev/null | mmimap.el:114: (setq content-type (list (cons 'type 'multipart))) | mmimap.el:130: (list (cons 'type (intern (downcase (car bodystructure)))))) この辺はこんな感じでしょうか? (setq content-type (make-mime-content-type (intern (downcase (car bodystructure))) (if (nth 1 bodystructure) (intern (downcase (nth 1 bodystructure)))) (mmimap-parse-parameters-from-list (nth 2 bodystructure)))) (setq content-type (make-mime-content-type 'multipart (if (car bodystructure) (intern (downcase (car bodystructure)))) (mmimap-parse-parameters-from-list (nth 1 bodystructure)))) ;; `parameters' が alist というのに依存した code があるのは SEMI だったかな? -- Shuhei KOBAYASHI おまけ: `prog1' のこんな使い方は邪悪ですか? ;-) (defun mmimap-parse-parameters-from-list (attrlist) "Parse parameters from ATTRLIST." (prog1 attrlist (while attrlist (setq attrlist (setcdr attrlist (prog1 (cdr (cdr attrlist)) (setcar attrlist (prog1 (cdr attrlist) (setcdr (cdr attrlist) (car (cdr attrlist))) (setcar (cdr attrlist) (downcase (car attrlist))))))))))) From shuhei ＠ aqua.ocn.ne.jp Sun Apr 29 15:00:39 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 29 Apr 2001 15:00:39 +0900 Subject: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231) References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> Message-ID: <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> >>>>> In <861yqc9ue3.fsf ＠ aqua.ocn.ne.jp>, >>>>> Shuhei KOBAYASHI wrote: > FLIM の RFC 2231 対応の main trunk への merge を検討しているのですが... これに関連するのですが, FLIM-API.en に関していくつか質問があります. `mime-parse-Content-Type' に関する記述が 2 か所に出てきますが, | * MIME content information | | ** How to use | | (require 'mime) | | | ** Content-Type | | [Function] mime-parse-Content-Type (string) | Parse STRING as field-body of Content-Type field, and | return the result as `mime-content-type' structure. [...] | * MIME Field parsing | | ** How to use | | (require 'mime) | | | ** Level 2 features [...] | [Function] mime-parse-Content-Type (string) | Parse STRING as field-body of Content-Type field. | | Return value is | (PRIMARY-TYPE SUBTYPE (NAME1 . VALUE1)(NAME2 . VALUE2) ...) | or nil. PRIMARY-TYPE and SUBTYPE are symbol and NAME_n and VALUE_n | are string. Q1. "Level 2 features" って何ですか? std11 の方には "Level 1 features" という記述もあるみたいですね. Q2. ("Level 2 features" では?) `mime-content-type' 型の構造まで定めてしまうのですか? Q2-1. 現在の FLIM 1.14 実装とは `mime-content-type' の構造が異なっていますが, これは FLIM 1.14 実装の bug なのでしょうか? Q2-2. IMAP4 では parameter list を alist ではなく plist で表現していますが, FLIM の特定の実装でも同様に plist を採用するというのは許容されないのでしょうか? Q2-3. `mime-content-type-parameters' の返り値の型は? | [Inline function] mime-content-type-parameters (content-type) | Return parameters of CONTENT-TYPE. `mime-content-type' 型の構造が API に含まれないとなれば, この関数の返り値の型は実装依存になりますね. そもそも, `mime-content-type-parameter' と `mime-content-type-parameters' の両方があるのは冗長ではないですか? >>>>> In <861yqc9ue3.fsf ＠ aqua.ocn.ne.jp>, >>>>> Shuhei KOBAYASHI wrote: > このため flim-1_13-rfc2231 とは異なり, API の拡張[*]は不要になっています. flim-1_13-rfc2231 が「API の拡張」と呼ぶところの変更は `parameters' を外に見せているために必要となったもので, `mime-content-type-parameter' だけを使用していれば API の変更は不要ではないでしょうか? ;; language info 関連を除く. あ, "[Inline function]" と規定しているのも問題ですね. `mime-content-type' 型の詳細を隠蔽できなくなってしまいます. 守岡さんは(or FLIM API では) *.elc の互換性は気にしないのでしたっけ? Q3. `make-mime-content-type' は API に含まれないのですか? `make-mime-content-disposition' は? (現在の FLIM 1.14 実装では未定義) RFC 2231 からは離れますが, | [Function] mime-entity-encoding (entity &optional default-encoding) | [Function] mime-read-Content-Transfer-Encoding (&optional default-encoding) Q4. `default-encoding' は不要ではないでしょうか? 実際, FLIM 1.14 でも `(or (mime-entity-encoding entity) "7bit")' のような書き方がされています. ちなみに, flim-1_14-rfc2231 では `default-encoding' をこっそりと廃止してあったのですが, 問題があるという報告は出ていません;-) FLIM-API.en には他にも気になる点がありますが, とりあえずここまで. -- Shuhei KOBAYASHI From shuhei ＠ aqua.ocn.ne.jp Sun Apr 29 23:34:17 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 29 Apr 2001 23:34:17 +0900 Subject: some XEmacs functions References: <86u250lh9l.fsf@aqua.ocn.ne.jp> Message-ID: <86ae4zpyfq.fsf@aqua.ocn.ne.jp> >>>>> In <86u250lh9l.fsf ＠ aqua.ocn.ne.jp>, >>>>> Shuhei KOBAYASHI wrote: > >>>>> In , > >>>>> Daiki Ueno wrote: > > いくつか邪悪なものを commit しました。 > > > > XEmacs 19.13 and later: > > remassq, remassoc, remrassoc > > これらの定義は間違っているみたいですね. remassoc, remassq, remrassoc, remrassq の定義を修正しました. 何となくこんなものを書いてみたくなったので... (mime-parse-user-agent "T-gnus/6.15.3 (based on Oort Gnus v0.03) XEmacs/21.5 (beta0) (alfalfa) (sparc-sun-solaris2.6) WEMI/1.14.3 (=?ISO-2022-JP?B?GyRCNmJDKxsoQg==?=) CLIME/1.14.0 (=?ISO-2022-JP?B?GyRCOF40VkYyGyhC?=) APEL/10.3") => (["T-gnus" nil (6 15 3) "based on Oort Gnus v0.03" nil nil nil "6.15.3"] ["XEmacs" nil (21 5) "beta0 alfalfa sparc-sun-solaris2.6" nil nil nil "21.5"] ["WEMI" nil (1 14 3) "金谷" nil nil nil "1.14.3"] ["CLIME" nil (1 14 0) "五間堂" nil nil nil "1.14.0"] ["APEL" nil (10 3) "" nil nil nil "10.3"]) ;; 何かの役に立つのでしょうか? ;; BBDB などで User-Agent を収集している人には使いみちがある? -- Shuhei KOBAYASHI -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: 無し型: application/octet-stream サイズ: 3698 バイト説明: 無し URL: