From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Konstantin Newsgroups: gmane.emacs.bugs Subject: bug#74624: 29.4.50; Gnus cannot parse some filenames(UTF8) in an attachment Date: Sun, 01 Dec 2024 10:52:30 +0300 Organization: Home Message-ID: <87bjxvsuv5.fsf@localdomain> References: <87v7w44srm.fsf@localdomain> <86ed2s7kxp.fsf@gnu.org> <875xo3q5tg.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26327"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 74624@debbugs.gnu.org To: Visuwesh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 01 08:54:25 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tHeme-0006jx-Lg for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Dec 2024 08:54:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tHemN-0005uX-Sc; Sun, 01 Dec 2024 02:54:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tHemJ-0005u5-GX for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2024 02:54:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tHemJ-0007Dn-3e for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2024 02:54:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=8NicyL+SOomDlvN6yb2AXSZn7X5mUPDOKRdhzSAtyEI=; b=AGnz3M9YEeZUTuV3FikL5db9DBLsZKefir89AlzOqf8v1U12tLvEq+BXyx2l95zfC2NA3ru5mLFj19z1nbHazO6uzzNUdMNwu4Vx/yyBGj3DqBvTSypBp5IPK7H7ucmmgI0yKK3e97Gmj88rAyp7pLJx9TMuz6qT2omGzU2YjnOuAD7bbOMiQxJngC4vQhgI63lcfM0UcqRN1uGgGeOstCqD5S4wZ0Og5i5h5g2mGHdC5f9jFlnpDKVftTFlNuNNdwsF4rQHxTnWM8NdpWQISNpHTKdI3wpV8V/JEHVjZMx8ixUx4qC6k85kGDz2rZ6s7A+fdJp+yUV7csReThiKew==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tHemI-0000ll-Mp for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2024 02:54:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Konstantin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Dec 2024 07:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74624 X-GNU-PR-Package: emacs Original-Received: via spool by 74624-submit@debbugs.gnu.org id=B74624.17330395922860 (code B ref 74624); Sun, 01 Dec 2024 07:54:02 +0000 Original-Received: (at 74624) by debbugs.gnu.org; 1 Dec 2024 07:53:12 +0000 Original-Received: from localhost ([127.0.0.1]:50131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHelT-0000k3-Br for submit@debbugs.gnu.org; Sun, 01 Dec 2024 02:53:11 -0500 Original-Received: from forward502d.mail.yandex.net ([178.154.239.210]:44708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHelR-0000jf-EM for 74624@debbugs.gnu.org; Sun, 01 Dec 2024 02:53:10 -0500 Original-Received: from mail-nwsmtp-smtp-production-main-19.klg.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-19.klg.yp-c.yandex.net [IPv6:2a02:6b8:c42:3143:0:640:c03:0]) by forward502d.mail.yandex.net (Yandex) with ESMTPS id 81D2160F5F; Sun, 1 Dec 2024 10:52:33 +0300 (MSK) Original-Received: by mail-nwsmtp-smtp-production-main-19.klg.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id VqXxb5ZOneA0-bPROPQPD; Sun, 01 Dec 2024 10:52:33 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1733039553; bh=8NicyL+SOomDlvN6yb2AXSZn7X5mUPDOKRdhzSAtyEI=; h=Cc:Message-ID:References:Date:In-Reply-To:Subject:To:From; b=Yq6DsfyZ3bqvWoO3IVGU9V3Ny0ESBhcH+W5Rv4ttkWxum2fODykvkDsgDEYjJJlg8 vxL2Bbk8GPE9quhauhr2j0foSsxlIj2t2IXII/7R8j6ssmDnQlOuFpgNUmI1utcxs6 9EhhyLgCLCWbUrp4il0RgDRo7B1mK5/V8xy18tLg= Authentication-Results: mail-nwsmtp-smtp-production-main-19.klg.yp-c.yandex.net; dkim=pass header.i=@yandex.ru In-Reply-To: <875xo3q5tg.fsf@gmail.com> (Visuwesh's message of "Sun, 01 Dec 2024 11:54:11 +0530") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:296222 Archived-At: Visuwesh writes: > [=E0=AE=9A=E0=AE=A9=E0=AE=BF =E0=AE=A8=E0=AE=B5=E0=AE=AE=E0=AF=8D=E0=AE= =AA=E0=AE=B0=E0=AF=8D 30, 2024] Eli Zaretskii wrote: > >>> From: Konstantin >>> Date: Sat, 30 Nov 2024 18:59:25 +0300 >>>=20 >>> >From time to time i get emails with attachments from my colleges, whic= h they send from >>> "Roundcube" web-interface.=20 >>>=20 >>> Often, i cannot open these attachments by =3DRET=3D(gnus-article-press-= button) >>> or save them =3Do=3D(gnus-mime-save-part) with correct name. >>> (interestingly =3DX-m=3D(gnus-summary-save-parts) works correctly) >>>=20 >>> The reason is gnus cannot parse correctly some attached filenames. >>>=20 >>> The example of such attachment (I took it from gnus-summary-show-raw-ar= ticle) >>>=20 >>> --=3D_d38c0abddd645077f401d42fa430d9d5 >>> Content-Transfer-Encoding: base64 >>> Content-Type: application/vnd.openxmlformats-officedocument.wordprocess= ingml.document; >>> name=3D"=3D?UTF-8?Q?=3DD0=3D9E=3DD0=3DB1=3DD0=3DB7=3DD0=3DBE=3DD1=3D80= _2024_=3D28=3DD0=3DBD=3DD0=3DB0_=3D2Ed?=3D >>> =3D?UTF-8?Q?ocx?=3D" >>> Content-Disposition: attachment; >>> filename*0*=3DUTF-8''%D0%9E%D0%B1%D0%B7%D0%BE%D1%80%202024%20%28%D0%BD= %D0; >>> filename*1*=3D%B0%20.docx; >>> size=3D10 >>>=20 >>> c2Rmc2FmYXNmCg=3D=3D >>> --=3D_d38c0abddd645077f401d42fa430d9d5-- >>>=20 >>> I have tried to examine the reason. As i see it,=20=20 >>> gnus-data for such attachment is formed incorrectly: >>>=20 >>> (# >>> ("application/vnd.openxmlformats-officedocument.word..." >>> (name . "=D0=9E=EF=B8=8F=D0=B1=D0=B7=D0=BE=D1=80 2024 (=D0=BD=D0= =B0 .docx")) >>> base64 nil >>> ("attachment" (size . "10") >>> (filename . "=D0=9E=EF=B8=8F=D0=B1=D0=B7=D0=BE=D1=80 2024 (=D0=BD\= 320")) nil nil nil) >>>=20 >>> One can see that the filename is broken. >>> It should be "=D0=9E=EF=B8=8F=D0=B1=D0=B7=D0=BE=D1=80 2024 (=D0=BD=D0= =B0 .docx" just like the name. >> >> It looks like Gnus fails to decipher the file name when it is split in >> the middle of a UTF-8 sequence. >> >> I don't know Gnus. If you can help me by showing where the value of >> 'gnus-data property is calculated, I might be able to find the bug and >> suggest a fix. > > 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*=3DUTF-8''%D0%9E%D0%B1%D0%B7%D0%BE%D1%80%202024%20%28%D0= %BD%D0; > filename*1*=3D%B0%20.docx; > size=3D10 > > 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.