From yamaoka ＠ jpl.org Mon Oct 17 15:49:08 2005 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Mon, 17 Oct 2005 15:49:08 +0900 Subject: improving eword-decode.el Message-ID: こんにちは山岡です。 先週 emacs-pretest-bug メーリングリストに、以下のような subject が Gnus で正しくデコードされないという報告があり、半田さんが巧妙 なやり方で解決して下さいました。 Subject: =?UTF-8?B?W2lwdC5ydSAjMTYzXSDQkNCy0YLQvtCe0YLQstC10YI6INCc0KHQmjog0KHQ?= =?UTF-8?B?nyDRgtC10YHRgg==?= これは、テキストを utf-8 でエンコードしたデータを、文字の境界で はない場所で分割し、それぞれを B エンコードしたものです。Gnus の rfc2047.el だけでなく、FLIM の eword-decode.el も、このようなも のを扱うことができません。RFC2047 には次のような記述があります。 5. Use of encoded-words in message headers [...] The 'encoded-text' in an 'encoded-word' must be self-contained; 'encoded-text' MUST NOT be continued from one 'encoded-word' to another. This implies that the 'encoded-text' portion of a "B" 'encoded-word' will be a multiple of 4 characters long; for a "Q" 'encoded-word', any "=" character that appears in the 'encoded-text' portion will be followed by two hexadecimal characters. ぼくは最初、上記のようなものはこの「MUST NOT」に該当するのではな いかと思ったのですが、半田さんからは以下の見解をいただきました。 This example doesn't violate the above restriction. Each 'encoded-word' is surely "multiple of 4 characters long". Please note that the above restriction is for 'encoded-text', not for the underlining coded character set. So, I think the above document doesn't prohibit diviging UTF-8 byte sequence at non-character boundary. 加えて、半田さんのコードの効率が良いこと、Gnus には何がなんでも 対応してしまう傾向があること、それに RMS からの命があることをもっ て、ぼくは同意したのでした。:) FLIM のデコーダはどうしましょうか? 分割された encoded words の 境界がテキストの文字単位になっていないものを他には見た記憶が無い ので、現在のままでもたぶん問題は無いと思うのですが、いちおう書い てみました。ただし、ご要望が無ければ CVS commit しないつもりです。 2005-10-17 Katsumi Yamaoka * eword-decode.el: Change the way to decode successive encoded-words: decode B- or Q-encoding in each encoded-word, concatenate them, and decode it as charset. See the following threads for more information: http://news.gmane.org/group/gmane.emacs.pretest.bugs/thread=9541 http://news.gmane.org/group/gmane.emacs.gnus.general/thread=61176 (eword-decode-encoded-words): New function. (eword-decode-string): Use it. (eword-decode-region): Use it. (eword-analyze-encoded-word): Use it. (eword-decode-encoded-word): Abolish. (eword-decode-encoded-text): Abolish. (eword-decode-encoded-word-error-handler): Abolish. (eword-warning-face): Abolish. (eword-decode-encoded-word-default-error-handler): Abolish. -------------- next part -------------- --- eword-decode.el~ 2005-07-06 01:55:39 +0000 +++ eword-decode.el 2005-10-17 06:45:12 +0000 @@ -88,30 +88,31 @@ if there are in decoded encoded-words (generated by bad manner MUA such as a version of Net$cape)." (setq string (std11-unfold-string string)) - (let ((dest "")(ew nil) - beg end) - (while (and (string-match eword-encoded-word-regexp string) - (setq beg (match-beginning 0) - end (match-end 0)) - ) - (if (> beg 0) - (if (not - (and (eq ew t) - (string-match "^[ \t]+$" (substring string 0 beg)) - )) - (setq dest (concat dest (substring string 0 beg))) - ) - ) - (setq dest - (concat dest - (eword-decode-encoded-word - (substring string beg end) must-unfold) - )) - (setq string (substring string end)) - (setq ew t) - ) - (concat dest string) - )) + (let (start end words) + (while (string-match eword-encoded-word-regexp string) + (setq start (match-beginning 0) + end (match-end 0) + words (list (list (match-string 1 string) ;; charset + (match-string 2 string) ;; language + (match-string 3 string) ;; encoding + (match-string 4 string)))) ;; word + (while (and (string-match (eval-when-compile + (concat "\\([\n\t ]*\\)" + eword-encoded-word-regexp)) + string end) + (= end (match-beginning 0))) + (setq end (match-end 0)) + (push (list (match-string 2 string) ;; charset + (match-string 3 string) ;; language + (match-string 4 string) ;; encoding + (match-string 5 string)) ;; word + words)) + (when (setq words (eword-decode-encoded-words (nreverse words) + must-unfold)) + (setq string (concat (substring string 0 start) + words + (substring string end)))))) + string) (defun eword-decode-structured-field-body (string &optional start-column max-column @@ -223,24 +224,29 @@ (save-restriction (narrow-to-region start end) (if unfolding - (eword-decode-unfold) - ) + (eword-decode-unfold)) (goto-char (point-min)) - (while (re-search-forward (concat "\\(" eword-encoded-word-regexp "\\)" - "\\(\n?[ \t]\\)+" - "\\(" eword-encoded-word-regexp "\\)") - nil t) - (replace-match "\\1\\7") - (goto-char (point-min)) - ) - (while (re-search-forward eword-encoded-word-regexp nil t) - (insert (eword-decode-encoded-word - (prog1 - (buffer-substring (match-beginning 0) (match-end 0)) - (delete-region (match-beginning 0) (match-end 0)) - ) must-unfold)) - ) - ))) + (let (start end words) + (while (re-search-forward eword-encoded-word-regexp nil t) + (setq start (match-beginning 0) + end (match-end 0) + words (list (list (match-string 1) ;; charset + (match-string 2) ;; language + (match-string 3) ;; encoding + (match-string 4)))) ;; word + (while (looking-at (eval-when-compile + (concat "\\([\n\t ]*\\)" + eword-encoded-word-regexp))) + (goto-char (setq end (match-end 0))) + (push (list (match-string 2) ;; charset + (match-string 3) ;; language + (match-string 4) ;; encoding + (match-string 5)) ;; word + words)) + (when (setq words (eword-decode-encoded-words (nreverse words) + must-unfold)) + (delete-region start end) + (insert words))))))) (defun eword-decode-unfold () (goto-char (point-min)) @@ -511,86 +517,53 @@ (make-obsolete 'eword-decode-header 'mime-decode-header-in-buffer) -;;; @ encoded-word decoder -;;; - -(defvar eword-decode-encoded-word-error-handler - 'eword-decode-encoded-word-default-error-handler) - -(defvar eword-warning-face nil - "Face used for invalid encoded-word.") - -(defun eword-decode-encoded-word-default-error-handler (word signal) - (and (add-text-properties 0 (length word) - (and eword-warning-face - (list 'face eword-warning-face)) - word) - word)) - -(defun eword-decode-encoded-word (word &optional must-unfold) - "Decode WORD as an encoded-word. - -If charset is unknown or unsupported, return WORD. -If encoding is unknown, or some error occurs while decoding, -`eword-decode-encoded-word-error-handler' is called with WORD and an -error condition. - -If MUST-UNFOLD is non-nil, unfold decoded WORD." - (or (and (string-match eword-encoded-word-regexp word) - (condition-case err - (eword-decode-encoded-text - ;; charset - (substring word (match-beginning 1)(match-end 1)) - ;; language - (when (match-beginning 2) - (intern - (downcase - (substring word (1+ (match-beginning 2))(match-end 2))))) - ;; encoding - (upcase - (substring word (match-beginning 3)(match-end 3))) - ;; encoded-text - (substring word (match-beginning 4)(match-end 4)) - must-unfold) - (error - (funcall eword-decode-encoded-word-error-handler word err)))) - word)) - - -;;; @ encoded-text decoder +;;; @ encoded-words decoder ;;; -(defun eword-decode-encoded-text (charset language encoding string - &optional must-unfold) - "Decode STRING as an encoded-text. - -If your emacs implementation can not decode CHARSET, it returns nil. - -If LANGUAGE is non-nil, it is put to `mime-language' text-property. -If ENCODING is not \"B\" or \"Q\", it occurs error. -So you should write error-handling code if you don't want break by errors. +(defun eword-decode-encoded-words (words must-unfold) + "Decode successive encoded-words in WORDS and return a decoded string. +Each element of WORDS looks like (CHARSET LANGUAGE ENCODING DATA). If MUST-UNFOLD is non-nil, it unfolds and eliminates line-breaks even -if there are in decoded encoded-text (generated by bad manner MUA such -as a version of Net$cape)." - (when (mime-charset-to-coding-system charset) - (let ((dest (encoded-text-decode-string string encoding))) - (when dest - (setq dest (decode-mime-charset-string dest charset)) +if there are in decoded encoded-words (generated by bad manner MUA +such as a version of Net$cape)." + (let (word charset encoding language rest) + (catch 'invalid + (while words + (setq word (pop words)) + (unless (mime-charset-to-coding-system (setq charset (car word))) + (message "Invalid charset: %s" charset) + (throw 'invalid nil)) + (setq encoding (nth 2 word)) + (cond ((member encoding '("B" "Q"))) + ((member encoding '("b" "q")) + (setq encoding (upcase encoding))) + (t + (message "Invalid encoding: $s" encoding) + (throw 'invalid nil))) + (setq language (nth 1 word) + word (encoded-text-decode-string (nth 3 word) encoding)) + (if (and rest + (string-equal charset (caaar rest)) + (equal language (cdaar rest))) + (setcdr (car rest) (concat (cdar rest) word)) + (push (cons (cons charset language) word) rest))) + (setq words "") + (while rest + (setq word (decode-mime-charset-string (cdar rest) (caaar rest))) (when must-unfold - (setq dest - (mapconcat - (function - (lambda (chr) - (cond ((eq chr ?\n) "") - ((eq chr ?\r) "") - ((eq chr ?\t) " ") - (t (char-to-string chr))))) - (std11-unfold-string dest) ""))) - (when language - (put-text-property 0 (length dest) 'mime-language language dest)) - dest)))) - + (setq word (mapconcat (lambda (chr) + (cond ((eq chr ?\n) "") + ((eq chr ?\r) "") + ((eq chr ?\t) " ") + (t (char-to-string chr)))) + (std11-unfold-string word) + ""))) + (when (setq language (cdaar rest)) + (put-text-property 0 (length word) 'mime-language language word)) + (setq words (concat word words) + rest (cdr rest))) + words))) ;;; @ lexical analyze ;;; @@ -713,28 +686,24 @@ (if (and (string-match eword-encoded-word-regexp string start) (= (match-beginning 0) start)) (let ((end (match-end 0)) - (dest (eword-decode-encoded-word (match-string 0 string) - must-unfold)) - ) - ;;(setq string (substring string end)) - (setq start end) + (words (list (list (match-string 1 string) ;; charset + (match-string 2 string) ;; language + (match-string 3 string) ;; encoding + (match-string 4 string))))) ;; word (while (and (string-match (eval-when-compile - (concat "[ \t\n]*\\(" - eword-encoded-word-regexp - "\\)")) - string start) - (= (match-beginning 0) start)) + (concat "\\([\n\t ]*\\)" + eword-encoded-word-regexp)) + string end) + (= end (match-beginning 0))) (setq end (match-end 0)) - (setq dest - (concat dest - (eword-decode-encoded-word (match-string 1 string) - must-unfold)) - ;;string (substring string end)) - start end) - ) - (cons (cons 'atom dest) ;;string) - end) - ))) + (push (list (match-string 2 string) ;; charset + (match-string 3 string) ;; language + (match-string 4 string) ;; encoding + (match-string 5 string)) ;; word + words)) + (when (setq words (eword-decode-encoded-words (nreverse words) + must-unfold)) + (cons (cons 'atom words) end))))) (defun eword-analyze-atom (string start &optional must-unfold) (if (and (string-match std11-atom-regexp string start) From gotoh ＠ taiyo.co.jp Mon Oct 17 18:36:48 2005 From: gotoh ＠ taiyo.co.jp (Shun-ichi GOTO) Date: Mon, 17 Oct 2005 18:36:48 +0900 (JST) Subject: improving eword-decode.el In-Reply-To: References: Message-ID: <20051017.183648.43139166.gotoh@taiyo.co.jp> どうも、後藤です。 >>>>> On Mon, 17 Oct 2005 15:49:08 +0900, >>>>> 山岡 == Katsumi Yamaoka wrote, 山岡> これは、テキストを utf-8 でエンコードしたデータを、文字の境界で 山岡> はない場所で分割し、それぞれを B エンコードしたものです。Gnus の 山岡> rfc2047.el だけでなく、FLIM の eword-decode.el も、このようなも 山岡> のを扱うことができません。RFC2047 には次のような記述があります。 ...snip... 山岡> ぼくは最初、上記のようなものはこの「MUST NOT」に該当するのではな 山岡> いかと思ったのですが、 character boundary を強制するのはその部分の文章ではなく、その2つ下の Each 'encoded-word' MUST represent an integral number of characters. A multi-octet character may not be split across adjacent 'encoded- word's. の部分ではないでしょうか？ # 後半が may not なのは、そういう事も想定してdecode は出来るべき、という # 意味なのだろうなと思ってますが、そこは自信なし。 山岡> FLIM のデコーダはどうしましょうか? 分割された encoded words の 山岡> 境界がテキストの文字単位になっていないものを他には見た記憶が無い 山岡> ので、現在のままでもたぶん問題は無いと思うのですが、いちおう書い 山岡> てみました。ただし、ご要望が無ければ CVS commit しないつもりです。 バイト列の途中というのはあったかどうかはもう覚えてないのですが、 以前はNetscape Communicatorとかが "$Bxxxx" "xxxx(B" みたいな分割をしてた事がありました。 今でも怪しいのは時々見かけます。 decode の際にそういうのに対応する柔軟性はあった方が良いかと思います。 というか、そうでないとユーザは結構困ると思うので。 --- Regards, Shun-ichi Goto R&D Group, TAIYO Corp., Tokyo, JAPAN From yamaoka ＠ jpl.org Mon Oct 17 19:41:37 2005 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Mon, 17 Oct 2005 19:41:37 +0900 Subject: improving eword-decode.el References: <20051017.183648.43139166.gotoh@taiyo.co.jp> Message-ID: >>>>> In [emacs-mime-ja : No.01991] >>>>> Shun-ichi GOTO wrote: > どうも、後藤です。 こんばんは。フォローありがとうございます。 > character boundary を強制するのはその部分の文章ではなく、その2つ下の > Each 'encoded-word' MUST represent an integral number of characters. > A multi-octet character may not be split across adjacent 'encoded- > word's. > の部分ではないでしょうか？ > # 後半が may not なのは、そういう事も想定してdecode は出来るべき、という > # 意味なのだろうなと思ってますが、そこは自信なし。 なるほど。エンコーダを設計するときの指針として眺めれば、たしかに 強制とは読めませんね。 山岡> FLIM のデコーダはどうしましょうか? > バイト列の途中というのはあったかどうかはもう覚えてないのですが、 > 以前はNetscape Communicatorとかが > "$Bxxxx" > "xxxx(B" > みたいな分割をしてた事がありました。 > 今でも怪しいのは時々見かけます。 > decode の際にそういうのに対応する柔軟性はあった方が良いかと思います。 > というか、そうでないとユーザは結構困ると思うので。 はい、同意します。じゃあ 山岡> ただし、ご要望が無ければ CVS commit しないつもりです。 これは、しばらく待ってみて反対が無かったら CVS commit します、に 変更しましょう。;-) ところで、さっきは書きませんでしたが、ぼくが書き換えたコードでは error-handler を再実装するのが面倒だったので、ばっさり捨ててしまっ てあります。 -------- そもそも `encoded-text' というものの実体が、人間が読んで意味のあ る `text' だとは思えないので、これは元の `text' を encode した結 果として得られたもの、と解釈したところからぼくの考えは始まりまし た。だから 'encoded-text' MUST NOT be continued from one 'encoded-word' to another. という一文は、単一の `encoded-text' をデコードした結果が、元の `text' を文字単位で切り刻んだ断片になることを求めているのだろう、 と読んだわけです。 加えて、あのロシア語の encoded words はいかにも低品質なエンコー ダで作られたように見えたので、そんなの放っておけばいいじゃんとい う気持ちが強かった一方で、とにかく FSF の親分が (彼はキリル文字 を ??? としか見ることができないみたいだけれど) 対処しろって言っ ているんだから、やっぱりやらなきゃだめなのかなあ、と揺れていたの でした。 From tomo ＠ m17n.org Tue Oct 18 15:05:51 2005 From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQg==?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 18 Oct 2005 15:05:51 +0900 Subject: improving eword-decode.el In-Reply-To: Katsumi Yamaoka's message of "Mon, 17 Oct 2005 15:49:08 +0900" References: Message-ID: 幽霊メインテナー(^_^;;の守岡です。 >>>>> In [emacs-mime-ja : No.01990] >>>>> Katsumi Yamaoka wrote: > FLIM のデコーダはどうしましょうか? 分割された encoded words の > 境界がテキストの文字単位になっていないものを他には見た記憶が無い > ので、現在のままでもたぶん問題は無いと思うのですが、いちおう書い > てみました。ただし、ご要望が無ければ CVS commit しないつもりです。 ちょっと今とっても疲れてて、判断できません。 また、できれば、小林さんと akr さんの見解を聞きたいです。 ;; 私の個人的偏見を述べれば、この手の件での半田さんや RMS 先生の御見解 ;; はあんまり信用できないです。(^_^; そういう訳で、私からの提案ですが、commit するにせよしないにせよ、まず、 commit 前の状態で一旦 FLIM を release してはどうかと思います。そうすれ ば、tag も付きますし、branch もしやすいでしょう。 もし、３日以内に反対がなければ、そこから１週間以内に FLIM 1.14.8 を release したいと思います。また、その release まで commit は凍結という ことで行きたいと思います。 > 先週 emacs-pretest-bug メーリングリストに、以下のような subject > が Gnus で正しくデコードされないという報告があり、半田さんが巧妙 > なやり方で解決して下さいました。 > > Subject: =?UTF-8?B?W2lwdC5ydSAjMTYzXSDQkNCy0YLQvtCe0YLQstC10YI6INCc0KHQmjog0KHQ?= =?UTF-8?B?nyDRgtC10YHRgg==?= > > これは、テキストを utf-8 でエンコードしたデータを、文字の境界で > はない場所で分割し、それぞれを B エンコードしたものです。Gnus の > rfc2047.el だけでなく、FLIM の eword-decode.el も、このようなも > のを扱うことができません。RFC2047 には次のような記述があります。 > > 5. Use of encoded-words in message headers > > [...] > > The 'encoded-text' in an 'encoded-word' must be self-contained; > 'encoded-text' MUST NOT be continued from one 'encoded-word' to > another. This implies that the 'encoded-text' portion of a "B" > 'encoded-word' will be a multiple of 4 characters long; for a "Q" > 'encoded-word', any "=" character that appears in the 'encoded-text' > portion will be followed by two hexadecimal characters. > > ぼくは最初、上記のようなものはこの「MUST NOT」に該当するのではな > いかと思ったのですが、半田さんからは以下の見解をいただきました。 > > This example doesn't violate the above restriction. Each > 'encoded-word' is surely "multiple of 4 characters long". > > Please note that the above restriction is for > 'encoded-text', not for the underlining coded character set. > So, I think the above document doesn't prohibit diviging > UTF-8 byte sequence at non-character boundary. 私としては、encoded-text の適格性ではなく、各 encoded-word で charset が指定されていることを根拠に、encoded-text が指し示すものが任意のバイ ト列ではなく、符号化文字データ要素といいたいです。 Some character sets use code-switching techniques to switch between "ASCII mode" and other modes. If unencoded text in an 'encoded-word' contains a sequence which causes the charset interpreter to switch out of ASCII mode, it MUST contain additional control codes such that ASCII mode is again selected at the end of the 'encoded-word'. (This rule applies separately to each 'encoded-word', including adjacent 'encoded-word's within a single header field.) は、UTF-8 の場合だと、制御文字で切替える訳ではないから微妙ですが、初期 状態（STD 11 の世界）は US-ASCII 文字列で、encoded-word 内は encoded-word の charset で解釈され、encoded-word が終ると US-ASCII 文字列の世界に戻るという前提から導かれる規定だと思います。 文字の境界でぶった切るということができると思う人は、charset が文字列と （符号化文字データ要素である）バイト列の変換であることを理解してないの かなと思います。 > 加えて、半田さんのコードの効率が良いこと、Gnus には何がなんでも > 対応してしまう傾向があること、それに RMS からの命があることをもっ > て、ぼくは同意したのでした。:) ;; 機会があれば、是非一度、RMS 先生の命に従って、夕方、17:30 で玄関が ;; 施錠されるオフィースビルのドアを、椅子を置くことでブロックすること ;; に同意してみてください。:-) セキュリティーがあって、警備員が来るシ ;; チュエーションだとなお良し。(^_^;;; > FLIM のデコーダはどうしましょうか? 分割された encoded words の > 境界がテキストの文字単位になっていないものを他には見た記憶が無い > ので、現在のままでもたぶん問題は無いと思うのですが、いちおう書い > てみました。ただし、ご要望が無ければ CVS commit しないつもりです。 一般論からいえば、encode は厳格に decode は寛容にというのが良いといえ ますが、encoded-word 単位に文字列と解釈することは、初期状態を常に US-ASCII に reset するということで、変な encoded-word から端末を守ると いう効果があると思います。そういう訳で、文字がぶった切られた encoded-word 列のサポートが良いことなのかちょっと判んないです。実際の 用例や頻度にも関係しますし。 迷うなら、オプションで選択できるようにするのが良いのかも知れませんが。 -- 守岡 知彦 (MORIOKA Tomohiko) From yamaoka ＠ jpl.org Tue Oct 18 15:55:50 2005 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Tue, 18 Oct 2005 15:55:50 +0900 Subject: improving eword-decode.el References: Message-ID: 無節操なことにあんまり抵抗の無い山岡です。 >>>>> In [emacs-mime-ja : No.01993] 守岡知彦さん wrote: > また、できれば、小林さんと akr さんの見解を聞きたいです。 ぼくも希望します。 > ;; 私の個人的偏見を述べれば、この手の件での半田さんや RMS 先生の御見解 > ;; はあんまり信用できないです。(^_^; ;; 半田さんはともかく、RMS は自分の環境で非 ASCII 文字を表示して ;; みようとも思わない人ですから、彼の根拠は単に「困っている人が ;; いるなら助けてあげよう」なんでしょう。 > そういう訳で、私からの提案ですが、commit するにせよしないにせよ、まず、 > commit 前の状態で一旦 FLIM を release してはどうかと思います。そうすれ > ば、tag も付きますし、branch もしやすいでしょう。 > もし、３日以内に反対がなければ、そこから１週間以内に FLIM 1.14.8 を > release したいと思います。また、その release まで commit は凍結という > ことで行きたいと思います。 了解です。ただ、ぼくとしては FLIM を改造することに強い意欲を持っ ているわけではありません。あそこまで無節操なことをするべきではな いという意見が多ければ、そう急いでリリースしていただく必要は無く なるはずです (守岡さんが、「あれはだめ」と言ってくれるだけでも、 ぼくには十分です ;-)。 [...] > 一般論からいえば、encode は厳格に decode は寛容にというのが良いといえ > ますが、encoded-word 単位に文字列と解釈することは、初期状態を常に > US-ASCII に reset するということで、変な encoded-word から端末を守ると > いう効果があると思います。そういう訳で、文字がぶった切られた > encoded-word 列のサポートが良いことなのかちょっと判んないです。実際の > 用例や頻度にも関係しますし。 結局のところ、RFC2047 が文字の切れ目以外の場所でぶった切ることの 是非を明確に規定していないのが問題なんですよね。 > 迷うなら、オプションで選択できるようにするのが良いのかも知れませんが。 あんな変な encoded-words は見たことが無い、と言い切れないところ で、少し迷いがあるのです。Spam 記事などでときどき目にする、いか にも粗悪なエンコーダで作られた、ところどころ文字化けしている subject が、実はそういうものなのかなあ、と。それが世界のある地域 にはびこっているのならば、Gnus で行なったような対応は必要なのか もしれません。 ;; ところで、その Gnus ですが、半田さんのコードだと未知の ;; charset が指定された場合に B または Q エンコードをデコードし ;; ただけのものを表示してしまうのが、ちょっとまずいです。近いう ;; ちに対策しようと思います。 From yamaoka ＠ jpl.org Tue Oct 18 19:36:14 2005 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Tue, 18 Oct 2005 19:36:14 +0900 Subject: improving eword-decode.el References: Message-ID: 大幅に書き直したものを、以下の場所に置いておきました。 ftp://ftp.jpl.org/pub/tmp/eword-decode.el.gz >> 迷うなら、オプションで選択できるようにするのが良いのかも知れませんが。 eword-decode-allow-incomplete-encoded-text is a variable defined in `eword-decode'. Its value is t Documentation: *Non-nil means allow incomplete encoded-text in successive encoded-words. If non-nil, the decoder will decode B- or Q-encoding in each encoded- word, concatenate them, and decode it by charset. Otherwise, the decoder will fully decode each encoded-word before concatenating them. [back] From handa ＠ m17n.org Tue Oct 18 20:40:28 2005 From: handa ＠ m17n.org (Kenichi Handa) Date: Tue, 18 Oct 2005 20:40:28 +0900 Subject: improving eword-decode.el In-Reply-To: <20051017.183648.43139166.gotoh@taiyo.co.jp> (message from Shun-ichi GOTO on Mon, 17 Oct 2005 18:36:48 +0900 (JST)) References: <20051017.183648.43139166.gotoh@taiyo.co.jp> Message-ID: In article <20051017.183648.43139166.gotoh ＠ taiyo.co.jp>, Shun-ichi GOTO writes: > character boundary を強制するのはその部分の文章ではなく、その2つ下の > Each 'encoded-word' MUST represent an integral number of characters. > A multi-octet character may not be split across adjacent 'encoded- > word's. > の部分ではないでしょうか？ そういうパラグラフもあるんですか（なにせ RFC はメイルに引用さ れている部分しか読んでいないので）。それなら確かに先の例は間 違ったエンコードですね。 > # 後半が may not なのは、そういう事も想定してdecode は出来るべき、という > # 意味なのだろうなと思ってますが、そこは自信なし。 上記の may no は単に不許可の意味でしょう。 --- 半田＠ＡＩＳＴ From tomo ＠ m17n.org Tue Oct 18 23:04:00 2005 From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQg==?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 18 Oct 2005 23:04:00 +0900 Subject: improving eword-decode.el In-Reply-To: Katsumi Yamaoka's message of "Tue, 18 Oct 2005 15:55:50 +0900" References: Message-ID: >>>>> In [emacs-mime-ja : No.01994] >>>>> Katsumi Yamaoka wrote: > ;; 半田さんはともかく、RMS は自分の環境で非 ASCII 文字を表示してみよ > ;; うとも思わない人ですから、彼の根拠は単に「困っている人がいるなら > ;; 助けてあげよう」なんでしょう。 ;; Emacs 20.3 の故事もあるので(^_^; > > そういう訳で、私からの提案ですが、commit するにせよしないにせよ、 > > まず、commit 前の状態で一旦 FLIM を release してはどうかと思います。 > > そうすれば、tag も付きますし、branch もしやすいでしょう。 > > > もし、３日以内に反対がなければ、そこから１週間以内に FLIM 1.14.8 > > をrelease したいと思います。また、その release まで commit は凍結 > > ということで行きたいと思います。 > > 了解です。ただ、ぼくとしては FLIM を改造することに強い意欲を持っ > ているわけではありません。あそこまで無節操なことをするべきではな > いという意見が多ければ、そう急いでリリースしていただく必要は無く > なるはずです ;; もう１年以上 release してないし、最後に変更が加わってからもう２ヶ月 ;; 以上経ってるので、急いでリリースするとはいえない気も。(^_^;;; > (守岡さんが、「あれはだめ」と言ってくれるだけでも、ぼくには十分です ;-)。 ;; 昔より丸くなったと思うので、現実的な利便性の観点無しに、「あれはだ ;; め」とはいわないです。:-) > 結局のところ、RFC2047 が文字の切れ目以外の場所でぶった切ることの > 是非を明確に規定していないのが問題なんですよね。 後藤さんの記事 [emacs-mime-ja:01991] にあるように、文字をぶった切るの は明らかにだめですね（encoder の挙動としては禁止）。 Decoder の挙動に関しては 6.3. Mail reader handling of incorrectly formed 'encoded-word's It is possible that an 'encoded-word' that is legal according to the syntax defined in section 2, is incorrectly formed according to the rules for the encoding being used. For example: (1) An 'encoded-word' which contains characters which are not legal for a particular encoding (for example, a "-" in the "B" encoding, or a SPACE or HTAB in either the "B" or "Q" encoding), is incorrectly formed. (2) Any 'encoded-word' which encodes a non-integral number of characters or octets is incorrectly formed. A mail reader need not attempt to display the text associated with an 'encoded-word' that is incorrectly formed. However, a mail reader MUST NOT prevent the display or handling of a message because an 'encoded-word' is incorrectly formed. という訳で、どっちでも良さそうですね。 そういう訳で、どっちがより安全側かという観点で議論するのが良いかなと思 います。 -- 守岡 知彦 (MORIOKA Tomohiko) From yamaoka ＠ jpl.org Tue Oct 18 23:35:38 2005 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Tue, 18 Oct 2005 23:35:38 +0900 Subject: improving eword-decode.el References: Message-ID: >>>>> In 守岡知彦さん wrote: >> 結局のところ、RFC2047 が文字の切れ目以外の場所でぶった切ることの >> 是非を明確に規定していないのが問題なんですよね。 > 後藤さんの記事 [emacs-mime-ja:01991] にあるように、文字をぶった切るの > は明らかにだめですね（encoder の挙動としては禁止）。 そうですか。あれは「明らか」なんですね。ぼくは今後も自分でそう判 断できるかどうか自信がなくなりました。^^;; > Decoder の挙動に関しては > 6.3. Mail reader handling of incorrectly formed 'encoded-word's > It is possible that an 'encoded-word' that is legal according to the > syntax defined in section 2, is incorrectly formed according to the > rules for the encoding being used. For example: > (1) An 'encoded-word' which contains characters which are not legal > for a particular encoding (for example, a "-" in the "B" > encoding, or a SPACE or HTAB in either the "B" or "Q" encoding), > is incorrectly formed. > (2) Any 'encoded-word' which encodes a non-integral number of > characters or octets is incorrectly formed. > A mail reader need not attempt to display the text associated with an > 'encoded-word' that is incorrectly formed. However, a mail reader > MUST NOT prevent the display or handling of a message because an > 'encoded-word' is incorrectly formed. > という訳で、どっちでも良さそうですね。 encoded-words に関する `need not' は、対応してもしなくても良いわ けですね。 ;; あまり話を広げたくないですが、先月の fj.sys.mac, fj.kanji に ;; 出てきた "=?ISO-2022-JP?Q?^[$B%F%9%H^[(B?=" というものは (1) ;; に該当しそうです。 > そういう訳で、どっちがより安全側かという観点で議論するのが良いかなと思 > います。 実は現在の ftp://ftp.jpl.org/pub/tmp/eword-decode.el.gz では、安 全ではないことをやってしまった気がしています。複数の連続した encoded-words は、途中の空白文字を取り除いてデコードしたものを連 結 (または連結したものをデコード) しますが、それらのうちの一つだ けがデコードできなかった場合でも、他を活かすようにしました。まあ、 あまり起きそうもない事故ですけれど。 From akr ＠ m17n.org Mon Oct 24 14:07:41 2005 From: akr ＠ m17n.org (Tanaka Akira) Date: Mon, 24 Oct 2005 14:07:41 +0900 Subject: improving eword-decode.el In-Reply-To: (=?ISO-2022-JP?B?GyRCPGkyLENOSScbKEI=?= / MORIOKA Tomohiko's message of "18 Oct 2005 15:05:51 +0900") References: Message-ID: <87veznmrik.fsf@m17n.org> In article , tomo ＠ m17n.org (守岡知彦 / MORIOKA Tomohiko) writes: >> FLIM のデコーダはどうしましょうか? 分割された encoded words の >> 境界がテキストの文字単位になっていないものを他には見た記憶が無い >> ので、現在のままでもたぶん問題は無いと思うのですが、いちおう書い >> てみました。ただし、ご要望が無ければ CVS commit しないつもりです。 > > ちょっと今とっても疲れてて、判断できません。 > > また、できれば、小林さんと akr さんの見解を聞きたいです。 エンコードが間違っているという話についてはとくに付け加えるこ とはありません。 デコード時に複数の encoded word 内の byte 列を連結してから decode することの是非は興味深いところです。 それは、その結果が正しいかどうかは、原理的には charset に依 存するからです。つまり、stateful な encoding において、ひと つめの encoded word の影響により、それ以降の encoded word の 解釈が変わるような charset を考えることは不可能ではありませ ん。 ただ、現実にそういう charset が存在するかどうかは私は知りま せん。 厳密には違いますが、それに近いものとして思い付くのは、 ISO-2022-JP な byte 列の終端において G0 が ASCII か JIS X 0201 かという違いが次の encoded word 内の 0x5c の解釈に影響 を与えるということが考えられます。(ただ、これは厳密にいうと、 規格では終端では G0 は ASCII になっていないといけないことに なっているので encoder 側の問題であると解釈できます。) まぁ、多くの charset ではそういう問題は起きないでしょうから、 デフォルトで連結してから decode するのは悪くないと思います。 また、仮にそういう問題が起きる charset が見つかったとしても、 そのときにその charset では連結しないようにすればいいことな ので、現時点でそうしても大きな問題は起きないように思います。 -- [田中 哲][たなか あきら][Tanaka Akira] From lapis-lazuli ＠ pop06.odn.ne.jp Tue Oct 25 00:40:46 2005 From: lapis-lazuli ＠ pop06.odn.ne.jp (Hiroya Murata) Date: Tue, 25 Oct 2005 00:40:46 +0900 Subject: mime-edit =?ISO-2022-JP?B?GyRCJE4zSEQlGyhC?= Message-ID: mime-edit.el を mime-edit-insert-file, -voice, -mail, -message で 挿入される各パートについて, 別バッファにエンコード済みのデータを置 いて mime-edit バッファに mime-view を用いて表現形式を挿入する様に 拡張してみました. ;; 現在の実装では, -insert-file で挿入されるパートのメディアタイプ ;; が text だった場合は, 選んだ encoding に限らず, 編集バッファに ;; そのまま挿入されてしまいます. 又これを使って, mime-edit-again では, mime 解析した各 entity から 編集バッファを構成する様にもしてあります. 未だ完全ではありませんが, 取り敢えず叩き台にでもなればと思い, 公開 します. 添付のパッチは, emiko-1_14 枝の先端からの差分です. -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: mime-edit.el.patch 型: application/octet-stream サイズ: 30680 バイト 説明: 無し URL: -------------- next part -------------- 尚, Wanderlust から使用する為には, 次のパッチを Wanderlust へ当て る必要があります. -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: wl.patch 型: application/octet-stream サイズ: 2760 バイト 説明: 無し URL: -------------- next part -------------- -- Hiroya Murata (村田 浩也) PGP fingerprint: 53B6 1B4A 8193 A2D4 1526 BC9E 9AEF 2F6D 249D 5F17 From yamaoka ＠ jpl.org Tue Oct 25 08:30:08 2005 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Tue, 25 Oct 2005 08:30:08 +0900 Subject: mime-edit =?ISO-2022-JP?B?GyRCJE4zSEQlGyhC?= References: Message-ID: >>>>> In [emacs-mime-ja : No.02000] 村田さん wrote: > mime-edit.el を mime-edit-insert-file, -voice, -mail, -message で > 挿入される各パートについて, 別バッファにエンコード済みのデータを置 > いて mime-edit バッファに mime-view を用いて表現形式を挿入する様に > 拡張してみました. ちょっと試してみました。 > ;; 現在の実装では, -insert-file で挿入されるパートのメディアタイプ > ;; が text だった場合は, 選んだ encoding に限らず, 編集バッファに > ;; そのまま挿入されてしまいます. そのまま挿入されてしまうことの何が問題か、あるいはタグだけを挿入 すると何が良いのかを説明していただくと良いのではないでしょうか。 えと、いじわるで突っ込みを入れてるわけじゃなくて、MIME-Edit と Gnus のそれぞれのやり方の善し悪しが、実はよくわからなくなってし まったものですから。 ;; もしかしたら一番うれしいのは XEmacs のユーザかもしれませんね。 ;; (挿入された invisible なパートの領域でも C-n, C-p が一行ずつ ;; 進むので。) ちなみに Gnus の場合は、挿入するファイルやバッファを指定するタグ を挿入するだけで、それらをエンコードするのは C-c C-c した後です。 > 又これを使って, mime-edit-again では, mime 解析した各 entity から > 編集バッファを構成する様にもしてあります. > 未だ完全ではありませんが, でも、完成度はかなり高いとお見受けしました。別バッファはちゃんと 消えるし編集バッファに挿入する場合に text/plain 以外は read-only になるみたいだし...。 > 取り敢えず叩き台にでもなればと思い, 公開します. 添付のパッチは, > emiko-1_14 枝の先端からの差分です. C-c C-x C-y はまだですね(?)。message/rfc822 パートを挿入するとき デコードして表示する計画はありますか? From lapis-lazuli ＠ pop06.odn.ne.jp Tue Oct 25 11:13:35 2005 From: lapis-lazuli ＠ pop06.odn.ne.jp (Hiroya Murata) Date: Tue, 25 Oct 2005 11:13:35 +0900 Subject: mime-edit =?ISO-2022-JP?B?GyRCJE4zSEQlGyhC?= In-Reply-To: References: Message-ID: In the message [emacs-mime-ja : No.02001] on Tue, 25 Oct 2005 08:30:08 +0900, Katsumi Yamaoka wrote: > > ;; 現在の実装では, -insert-file で挿入されるパートのメディアタイプ > > ;; が text だった場合は, 選んだ encoding に限らず, 編集バッファに > > ;; そのまま挿入されてしまいます. > そのまま挿入されてしまうことの何が問題か、あるいはタグだけを挿入 > すると何が良いのかを説明していただくと良いのではないでしょうか。 以前は出来ていた, 特定の coding-system + 改行コードでエンコードさ れたテキストファイルをそのままの状態で送信する事が出来なくなってい ます. charset は, 手でタグを編集する事で変更出来ますが, text パー トの改行コードは必ず, CRLF に正規化されてしまう事になります. mime-edit-insert-file では, text であっても encoding による変換だ けしてそのまま添付する形式にし, 挿入後編集したい場合は, mime-edit-insert-tag + insert-file で対応してもらうのが, 良いので はないかと思っています. ;; 実は, mime-edit-insert-file で charset の判定が上手く出来なくて, ;; あの様な事になった訳ですが... > ちなみに Gnus の場合は、挿入するファイルやバッファを指定するタグ > を挿入するだけで、それらをエンコードするのは C-c C-c した後です。 mime-edit-again で解析した mime-entity を使って編集バッファを構成 する事を先に考えて作ったので今の様になっています. 参照先の情報だ け持つ, mmedit でも作って実際のエンコードは, 遅延処理する実装が良 いのかもしれませんね. > > 未だ完全ではありませんが, > でも、完成度はかなり高いとお見受けしました。別バッファはちゃんと > 消えるし編集バッファに挿入する場合に text/plain 以外は read-only > になるみたいだし...。 一応考えているのは, 編集不可パートの表示/非表示の切り替えコマンド でしょうか. それとタグの編集を一切禁止している為, Content-Description の追加や Content-Disposition の編集が出来ない ので, その辺をなんとかしないと使い辛いと思っています. > C-c C-x C-y はまだですね(?)。message/rfc822 パートを挿入するとき > デコードして表示する計画はありますか? あれ? その様にしたつもりですが. 改めて確認した所, Wanderlust だと -insert-message で呼ばれる inserter が, draft バッファで呼ばれる事 を仮定しているので上手く行かない様ですが, メッセージが挿入されれば ちゃんと動く筈です. Wanderlust でも C-c C-x C-m だと出来ますね. ;; 実体の参照に text-property を使っている関係で, wl-draft-save で ;; 添付パートが消えちゃってます. 使ってみようと言う方は注意して下 ;; さい. -- Hiroya Murata (村田 浩也) mailto:lapis-lazuli ＠ pop06.odn.ne.jp PGP fingerprint: 53B6 1B4A 8193 A2D4 1526 BC9E 9AEF 2F6D 249D 5F17 From yamaoka ＠ jpl.org Tue Oct 25 14:48:40 2005 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Tue, 25 Oct 2005 14:48:40 +0900 Subject: mime-edit =?ISO-2022-JP?B?GyRCJE4zSEQlGyhC?= References: Message-ID: >>>>> In [emacs-mime-ja : No.02002] 村田さん wrote: > 以前は出来ていた, 特定の coding-system + 改行コードでエンコードさ > れたテキストファイルをそのままの状態で送信する事が出来なくなってい > ます. charset は, 手でタグを編集する事で変更出来ますが, text パー > トの改行コードは必ず, CRLF に正規化されてしまう事になります. あー、そういう問題がありましたねえ。 > mime-edit-insert-file では, text であっても encoding による変換だ > けしてそのまま添付する形式にし, 挿入後編集したい場合は, > mime-edit-insert-tag + insert-file で対応してもらうのが, 良いので > はないかと思っています. 了解です。 > ;; 実は, mime-edit-insert-file で charset の判定が上手く出来なくて, > ;; あの様な事になった訳ですが... [...] >> C-c C-x C-y はまだですね(?)。 > あれ? その様にしたつもりですが. 改めて確認した所, Wanderlust だと > -insert-message で呼ばれる inserter が, draft バッファで呼ばれる事 > を仮定しているので上手く行かない様ですが, メッセージが挿入されれば > ちゃんと動く筈です. T-gnus の場合も message-mode のバッファで呼ばれることを仮定して いるのが原因でした。単にそのバッファの message-parameter-alist というローカル変数を別バッファに移せばいいんですが、こんなやり方 で一般化できるでしょうか。あまり美しくない気はしますが。 (defun mime-edit-insert-message-1 (inserter &optional message) (let ((msg (progn (funcall inserter message) (prog1 (buffer-substring (mark t) (point)) (delete-region (mark t) (point)))))) (mime-edit-insert-attached-part "message" "rfc822" (with-current-buffer (mime-edit-create-attached-entity-buffer) (insert msg) (goto-char (point-min)) (insert "Content-Type: message/rfc822\n\n") (mime-open-entity 'buffer (current-buffer)))))) それにしても >> message/rfc822 パートを挿入するときデコードして表示する計画はありま >> すか? これ↑が実現されているのには感服いたしました。 > Wanderlust でも C-c C-x C-m だと出来ますね. T-gnus は mime-edit-mail-inserter-alist を定義していないのでだめ でしたが、Wanderlust は...そうか...こうやっているのか...。 From lapis-lazuli ＠ pop06.odn.ne.jp Tue Oct 25 22:38:56 2005 From: lapis-lazuli ＠ pop06.odn.ne.jp (Hiroya Murata) Date: Tue, 25 Oct 2005 22:38:56 +0900 Subject: mime-edit =?ISO-2022-JP?B?GyRCJE4zSEQlGyhC?= In-Reply-To: References: Message-ID: In the message [emacs-mime-ja : No.02002] on Tue, 25 Oct 2005 11:13:35 +0900, Hiroya Murata wrote: > ;; 実体の参照に text-property を使っている関係で, wl-draft-save で > ;; 添付パートが消えちゃってます. 使ってみようと言う方は注意して下 > ;; さい. 取り敢えず, この問題を解消する為のパッチです. -- Hiroya Murata (村田 浩也) PGP fingerprint: 53B6 1B4A 8193 A2D4 1526 BC9E 9AEF 2F6D 249D 5F17 -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: wl-draft.el.patch 型: application/octet-stream サイズ: 2673 バイト 説明: 無し URL: From lapis-lazuli ＠ pop06.odn.ne.jp Sat Oct 29 15:10:57 2005 From: lapis-lazuli ＠ pop06.odn.ne.jp (Hiroya Murata) Date: Sat, 29 Oct 2005 15:10:57 +0900 Subject: mime-edit =?ISO-2022-JP?B?GyRCJE4zSEQlGyhC?= In-Reply-To: References: Message-ID: In the message [emacs-mime-ja : No.02002] on Tue, 25 Oct 2005 11:13:35 +0900, Hiroya Murata wrote: > 以前は出来ていた, 特定の coding-system + 改行コードでエンコードさ > れたテキストファイルをそのままの状態で送信する事が出来なくなってい > ます. charset は, 手でタグを編集する事で変更出来ますが, text パー > トの改行コードは必ず, CRLF に正規化されてしまう事になります. mime-edit-insert-file で挿入した場合は編集不可とし, emy から拝借し て, mime-edit-insert-text-file を追加しました. ついでに, charset の自動判定処理も拝借してしまいました. (改行コードの正規化も) > 一応考えているのは, 編集不可パートの表示/非表示の切り替えコマンド > でしょうか. それとタグの編集を一切禁止している為, > Content-Description の追加や Content-Disposition の編集が出来ない > ので, その辺をなんとかしないと使い辛いと思っています. mime-edit-(show|hide|toggle)-attached-part を追加しました. 適当な 空きがなかったので, キーアサインはしていません. また, 編集不可パー トのタグであっても, Content-Type の部分は, 編集出来る様にしました. Content-Description 等を手で追加する事が可能です. > あれ? その様にしたつもりですが. 改めて確認した所, Wanderlust だと > -insert-message で呼ばれる inserter が, draft バッファで呼ばれる事 > を仮定しているので上手く行かない様ですが, メッセージが挿入されれば > ちゃんと動く筈です. Wanderlust でも C-c C-x C-m だと出来ますね. 山岡さんの案をお借りして, C-c C-x C-y を動く様にしました. 本来なら inserter の I/F を変えたい所ですが... ;; elmo-mime.el へのパッチは以前のものをそのまま使用して下さい. -- Hiroya Murata (村田 浩也) PGP fingerprint: 53B6 1B4A 8193 A2D4 1526 BC9E 9AEF 2F6D 249D 5F17 -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: mime-edit.el.patch.gz 型: application/octet-stream サイズ: 7441 バイト 説明: 無し URL: -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: wl-draft.el.patch.gz 型: application/octet-stream サイズ: 1068 バイト 説明: 無し URL: