|
|
RFC 2047 (and RFC 1522, too) says in section 6.2:
"When displaying a particular header field that contains multiple
encoded-words, any linear-white-space that separates a pair of
adjacent encoded-words is ignored."
VM 7.19, however, will display white space between encoded words.
For example, the following header line:
To: =?ISO-8859-1?Q?Ulrich_M=FClle?=
=?ISO-8859-1?Q?r?= <ulm@xxxxxxxxxxxxxxxx>
will be displayed as:
To: Ulrich Mülle
r <ulm@xxxxxxxxxxxxxxxx>
while according to RFC 2047, section 6.2, it should be decoded as:
To: Ulrich Müller <ulm@xxxxxxxxxxxxxxxx>
One could argue (and I would agree) that the MUA of the sender,
Mozilla 1.7.8, is broken and should not insert white space at this
point. In spite of this, the encoding in the first example is valid
and VM should be able to decode it correctly.
The following patch fixes the problem:
--- vm-mime.el~ 2006-02-06 14:34:09.000000000 +0100
+++ vm-mime.el 2006-02-06 14:38:45.000000000 +0100
@@ -697,7 +697,8 @@
(defun vm-decode-mime-message-headers (m)
(let ((case-fold-search t)
(buffer-read-only nil)
- charset need-conversion encoding match-start match-end start end)
+ charset need-conversion encoding match-start match-end start end
+ previous-end)
(save-excursion
(goto-char (vm-headers-of m))
(while (re-search-forward vm-mime-encoded-word-regexp (vm-text-of m) t)
@@ -713,6 +714,11 @@
(not (setq need-conversion
(vm-mime-can-convert-charset charset))))
nil
+ ;; suppress whitespace between encoded words.
+ (and previous-end
+ (string-match "\\`[ \t\n]*\\'"
+ (buffer-substring previous-end match-start))
+ (setq match-start previous-end))
(delete-region end match-end)
(condition-case data
(cond ((string-match "B" encoding)
@@ -730,6 +736,7 @@
charset start end)))
(vm-mime-charset-decode-region charset start end)
(goto-char end)
+ (setq previous-end end)
(delete-region match-start start))))))
(defun vm-decode-mime-encoded-words ()
|
|