bug#74624: 29.4.50; Gnus cannot parse some filenames(UTF8) in an attachment

[Eli Zaretskii <eliz@gnu.org>]

> 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.