From yamaoka ＠ jpl.org  Mon May 10 21:09:58 2004
From: yamaoka ＠ jpl.org (Katsumi Yamaoka)
Date: Mon, 10 May 2004 21:09:58 +0900
Subject: eword sometimes exceeds 76 columns
Message-ID: <b9yhduozdnt.fsf@jpl.org>

Gnus でもヘッダのエンコードには FLIM を使っているんですが[1]、と
きどき RFC2047 の以下の規定が守られないことがあります。

   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.

   While there is no limit to the length of a multiple-line header
   field, each line of a header field that contains one or more
   'encoded-word's is limited to 76 characters.

まあ実害は無いのですが。例です。

Subject: 12345 寿限無寿限無五劫のすり切れ
↓
Subject: 12345 =?iso-2022-jp?B?GyRCPHc4Qkw1PHc4Qkw1OF45ZSROJDkkakBaJGwbKEI=?=

コードを追ってみると、おそらく eword の長さの計算に誤りは無く、
この例では Subject: の直後の空白の幅が単に無視されているように思
えます。以下のパッチはいかがでしょうか?

	* eword-encode.el (mime-encode-header-in-buffer): Don't ignore a
	space char at the beginning of a field body.

--- eword-encode.el~	2004-05-10 11:50:15 +0000
+++ eword-encode.el	2004-05-10 12:02:16 +0000
@@ -689,11 +689,9 @@
       (goto-char (point-min))
       (let ((default-cs (mime-charset-to-coding-system default-mime-charset))
 	    bbeg end field-name)
-	(while (re-search-forward
-		(concat "\\(" std11-field-head-regexp "\\)" " ?")
-		nil t)
-	  (setq bbeg (match-end 1)
-		field-name (buffer-substring (match-beginning 0) (1- (match-end 1)))
+	(while (re-search-forward std11-field-head-regexp nil t)
+	  (setq bbeg (match-end 0)
+		field-name (buffer-substring (match-beginning 0) (1- bbeg))
 		end (std11-field-end))
 	  (and (delq 'ascii (find-charset-region bbeg end))
 	       (let ((method (eword-find-field-encoding-method

eword の長さの計算もエンコード処理の一部だと考えれば、空白文字を
エンコードの対象にするのは無駄ではない気がします。

[1] http://www.jpl.org/elips/Gnus-Tips-ja.html#11
    本日、土屋さんのリポートを受けて改定しました。
-- 
Katsumi Yamaoka <yamaoka ＠ jpl.org>