--- Begin Message ---
|
Subject: |
29.4.50; Gnus cannot parse some filenames(UTF8) in an attachment |
|
Date: |
Sat, 30 Nov 2024 18:59:25 +0300 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) |
>From time to time i get emails with attachments from my colleges, which they
>send from
"Roundcube" web-interface.
Often, i cannot open these attachments by =RET=(gnus-article-press-button)
or save them =o=(gnus-mime-save-part) with correct name.
(interestingly =X-m=(gnus-summary-save-parts) works correctly)
The reason is gnus cannot parse correctly some attached filenames.
The example of such attachment (I took it from gnus-summary-show-raw-article)
--=_d38c0abddd645077f401d42fa430d9d5
Content-Transfer-Encoding: base64
Content-Type:
application/vnd.openxmlformats-officedocument.wordprocessingml.document;
name="=?UTF-8?Q?=D0=9E=D0=B1=D0=B7=D0=BE=D1=80_2024_=28=D0=BD=D0=B0_=2Ed?=
=?UTF-8?Q?ocx?="
Content-Disposition: attachment;
filename*0*=UTF-8''%D0%9E%D0%B1%D0%B7%D0%BE%D1%80%202024%20%28%D0%BD%D0;
filename*1*=%B0%20.docx;
size=10
c2Rmc2FmYXNmCg==
--=_d38c0abddd645077f401d42fa430d9d5--
I have tried to examine the reason. As i see it,
gnus-data for such attachment is formed incorrectly:
(#<buffer *mm*-480444>
("application/vnd.openxmlformats-officedocument.word..."
(name . "Обзор 2024 (на .docx"))
base64 nil
("attachment" (size . "10")
(filename . "Обзор 2024 (н\320")) nil nil nil)
One can see that the filename is broken.
It should be "Обзор 2024 (на .docx" just like the name.
I have attached the example of the mail(one can open it with nndoc)
Please, could you fix this bug.
mail.test
Description: Binary data
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#74624: 29.4.50; Gnus cannot parse some filenames(UTF8) in an attachment |
|
Date: |
Sun, 01 Dec 2024 10:17:33 +0200 |
> From: Konstantin <reich-cv@yandex.ru>
> Cc: Eli Zaretskii <eliz@gnu.org>, 74624@debbugs.gnu.org
> Date: Sun, 01 Dec 2024 10:52:30 +0300
>
>
> Visuwesh <visuweshm@gmail.com> writes:
>
> > The decoding of the filename in the Content-Disposition header is done
> > in mm-dissect-buffer by calling mail-header-parse-content-disposition.
> > Specifically, rfc2231-parse-string. The following patch fixes the issue
> > on my end:
> >
> > diff --git a/lisp/mail/rfc2231.el b/lisp/mail/rfc2231.el
> > index 33324cafb5b..632e270a922 100644
> > --- a/lisp/mail/rfc2231.el
> > +++ b/lisp/mail/rfc2231.el
> > @@ -193,7 +193,7 @@ rfc2231-parse-string
> > (push (list attribute value encoded) cparams))
> > ;; Repetition of a part; do nothing.
> > ((and elem
> > - (null number))
> > + (null part))
> > )
> > ;; Concatenate continuation parts.
> > (t
> >
> > NUMBER is the variable used during the parsing portion of the function
> > in the big condition-case form above the cl-loop form which the patch
> > modifies. In the header below
> >
> > Content-Disposition: attachment;
> >
> > filename*0*=UTF-8''%D0%9E%D0%B1%D0%B7%D0%BE%D1%80%202024%20%28%D0%BD%D0;
> > filename*1*=%B0%20.docx;
> > size=10
> >
> > the function first parses filename*0* and here NUMBER is 0, then
> > filename*1* and here NUMBER is 1. By the time it finishes parsing size,
> > NUMBER is set to nil. The loop should use the value of NUMBER pushed to
> > PARAMETERS as the 3rd element (referred to as `part' by the cl-loop
> > form) instead of whatever value NUMBER happened to be when we parsed the
> > last element.
>
> Thank you,
>
> indeed the patch fixes this bug.
Thanks, installed on the emacs-30 branch, and closing the bug.
--- End Message ---