If mail with long (longer about than 26 characters in my case) attached file names received, then these attachments shows and saves with additional space in the file name. in examle below correct file name is "Договор 1 на оказание услуг по обработке почвы. Технология. Талдом.docx" it's displays and saves as Договор 1 на оказание у слуг по обработке почвы. Т ехнология. Талдом.docx Reproducible: Always Steps to Reproduce: 1. Receive an message with attached file with long file name 2. Look at file name at the message header or save that file Actual Results: File will be displayed and saved with additional space char in its name. It's look like the reason is here: -----------start source ---------- --------_41_276815178_4760 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="=?UTF-8?B?0JTQvtCz0L7QstC+0YAgMSDQvdCwINC+0LrQsNC30LDQvdC40LUg0YM=?= !!!ADDITIONAL SPACE OCCURS!!! =?UTF-8?B?0YHQu9GD0LMg0L/QviDQvtCx0YDQsNCx0L7RgtC60LUg0L/QvtGH0LLRiy4g0KI=?= !!!ADDITIONAL SPACE OCCURS!!! =?UTF-8?B?0LXRhdC90L7Qu9C+0LPQuNGPLiDQotCw0LvQtNC+0LwuZG9jeA==?=" !!!ADDITIONAL SPACE OCCURS!!! Content-Disposition: attachment; filename="=?UTF-8?B?0JTQvtCz0L7QstC+0YAgMSDQvdCwINC+0LrQsNC30LDQvdC40LU=?= !!!ADDITIONAL SPACE OCCURS!!! =?UTF-8?B?INGD0YHQu9GD0LMg0L/QviDQvtCx0YDQsNCx0L7RgtC60LUg0L/QvtGH0LLRiy4=?= !!!ADDITIONAL SPACE OCCURS!!! =?UTF-8?B?INCi0LXRhdC90L7Qu9C+0LPQuNGPLiDQotCw0LvQtNC+0LwuZG9jeA==?=" Content-Transfer-Encoding: base64 -----------end source ----------
Created attachment 101019 [details] screenshot So, it doesn't look like that when you're selecting the message ?
reading the source, I have : Content-Disposition: attachment; filename*=UTF-8''%D0%94%D0%BE%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%201%20%D0%BD%D0%B0%20%D0%BE%D0%BA%D0%B0%D0%B7%D0%B0%D0%BD%D0%B8%D0%B5%20%D1%83%D1%81%D0%BB%D1%83%D0%B3%20%D0%BF%D0%BE%20%D0%BE%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B5%20%D0%BF%D0%BE%D1%87%D0%B2%D1%8B%2E%20%D0%A2%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F%2E%20%D0%A2%D0%B0%D0%BB%D0%B4%D0%BE%D0%BC%2Edocx Content-Transfer-Encoding: base64 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name*=UTF-8''%D0%94%D0%BE%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%201%20%D0%BD%D0%B0%20%D0%BE%D0%BA%D0%B0%D0%B7%D0%B0%D0%BD%D0%B8%D0%B5%20%D1%83%D1%81%D0%BB%D1%83%D0%B3%20%D0%BF%D0%BE%20%D0%BE%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B5%20%D0%BF%D0%BE%D1%87%D0%B2%D1%8B%2E%20%D0%A2%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F%2E%20%D0%A2%D0%B0%D0%BB%D0%B4%D0%BE%D0%BC%2Edocx
Created attachment 101122 [details] Screenshot with additional spaces Сorrect filename is: Договор 1 на оказание услуг по обработке почвы. Технология. Талдом.
Created attachment 101123 [details] Source screenshot In source i see encoded filename spited into three rows and exactly at breaks occurs additional spaces: -----source---- ------sOA2imNDPik6TVvdYIdSdZP56q77z6Ia-zEBUqmjdMGgRKwkE-1461416403 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="=?UTF-8?B?0JTQvtCz0L7QstC+0YAgMSDQvdCwINC+0LrQsNC30LDQvdC40LUg0YPRgdC7?= =?UTF-8?B?0YPQsyDQv9C+INC+0LHRgNCw0LHQvtGC0LrQtSDQv9C+0YfQstGLLiDQotC1?= =?UTF-8?B?0YXQvdC+0LvQvtCz0LjRjy4g0KLQsNC70LTQvtC8LmRvY3g=?=" Content-Disposition: attachment Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDYiDys8gEAANUJAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC ... -----source----
Created attachment 101124 [details] source screenshot Sorry, #4 comment with wrong attachment. In source i see encoded filename spited into three rows and exactly at breaks occurs additional spaces: -----source---- ------sOA2imNDPik6TVvdYIdSdZP56q77z6Ia-zEBUqmjdMGgRKwkE-1461416403 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="=?UTF-8?B?0JTQvtCz0L7QstC+0YAgMSDQvdCwINC+0LrQsNC30LDQvdC40LUg0YPRgdC7?= =?UTF-8?B?0YPQsyDQv9C+INC+0LHRgNCw0LHQvtGC0LrQtSDQv9C+0YfQstGLLiDQotC1?= =?UTF-8?B?0YXQvdC+0LvQvtCz0LjRjy4g0KLQsNC70LTQvtC8LmRvY3g=?=" Content-Disposition: attachment Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDYiDys8gEAANUJAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC ... -----source----
In KMail 5.4.2 this issue sill present.
Cannot reproduce using KMail git master. Like in Comment 2, files attached to mails created with KMail have their filename encoded in a single line and display and save just fine. Please let us know whether you can still reproduce. It would also be interesting to know which mail application was used to create the message you received. You can also attach a test case to the bug by saving as an mbox file.
Created attachment 128222 [details] achived local-mail folder archived folder contains message with long-named attached files with filenames in English in Russian.
(In reply to xchain from comment #7) > Please let us know whether you can still reproduce. It would also be > interesting to know which mail application was used to create the message > you received. You can also attach a test case to the bug by saving as an > mbox file. I confirm this bug still persist. Please check attached archived local-mail folder contains message with two long-named attachments. Attachmenent with the Russian name have additional spaces while displayed in Kmail, the English one is fine.
Created attachment 128224 [details] Files in Dolphin.png Can you please check attachments of this email? Both of them do not contains spaces. 06.05.2020 01:50, xchain пишет: https://bugs.kde.org/show_bug.cgi?id=362650 xchain <xchain@gmx.net> [1] changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WAITINGFORINFO Status|REPORTED |NEEDSINFO CC| | xchain@gmx.net [1] --- Comment #7 from xchain <xchain@gmx.net> [1] --- Cannot reproduce using KMail git master. Like in Comment 2, files attached to mails created with KMail have their filename encoded in a single line and display and save just fine. Please let us know whether you can still reproduce. It would also be interesting to know which mail application was used to create the message you received. You can also attach a test case to the bug by saving as an mbox file. -- С уважением, Александр Яворский. 1. mailto:xchain@gmx.net
Created attachment 128225 [details] Attachments in KMail.png
Created attachment 128226 [details] ЭтоВложениеСДлиннымИмемФайлаСовсемБезПробеловИЕщёРазЭтоВложениеСДлиннымИмемФайлаСовсемБезПробелов.txt
Created attachment 128227 [details] ThisIsAnAttachmentWithLongFilenameWithNoSpaceasAtAllAndOnceAgaingThisIsAnAttachmentWithLongFilenameWithNoSpaceasAtAll.txt
Thanks! With your test case it's much easier to reproduce the bug. Findings: - When hovering over the filename, the statusbar does _not_ show any spaces. - Saving a single attachment or all attachments at once also does _not_ result in any spaces. - Everything inside QWebEngine's view incorrectly shows spaces for the first attachment, but not for the second. Spaces are also present when selecting and copying the text. - When saving the files, attaching them to a new mail in KMail and saving as a draft, everything works fine when viewing the result. Thus KMail only has problems understanding the filename format created in Thunderbird. So, in general this should work now (certainly better than in 2016), but there are still some viewing-related cases for mails created in e.g. Thunderbird where this is still broken.
Content-Disposition: attachment; filename*0*=UTF-8''%D0%AD%D1%82%D0%BE%D0%92%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD; filename*1*=%D0%B8%D0%B5%D0%A1%D0%94%D0%BB%D0%B8%D0%BD%D0%BD%D1%8B%D0%BC; filename*2*=%D0%98%D0%BC%D0%B5%D0%BC%D0%A4%D0%B0%D0%B9%D0%BB%D0%B0%D0%A1; filename*3*=%D0%BE%D0%B2%D1%81%D0%B5%D0%BC%D0%91%D0%B5%D0%B7%D0%9F%D1%80; filename*4*=%D0%BE%D0%B1%D0%B5%D0%BB%D0%BE%D0%B2%D0%98%D0%95%D1%89%D1%91; filename*5*=%D0%A0%D0%B0%D0%B7%D0%AD%D1%82%D0%BE%D0%92%D0%BB%D0%BE%D0%B6; filename*6*=%D0%B5%D0%BD%D0%B8%D0%B5%D0%A1%D0%94%D0%BB%D0%B8%D0%BD%D0%BD; filename*7*=%D1%8B%D0%BC%D0%98%D0%BC%D0%B5%D0%BC%D0%A4%D0%B0%D0%B9%D0%BB; filename*8*=%D0%B0%D0%A1%D0%BE%D0%B2%D1%81%D0%B5%D0%BC%D0%91%D0%B5%D0%B7; filename*9*=%D0%9F%D1%80%D0%BE%D0%B1%D0%B5%D0%BB%D0%BE%D0%B2%2E%74%78%74 IAo= it's stored as it. I need to investigate how it's saved in kmail
Content-Disposition: attachment; filename*=UTF-8''%D0%AD%D1%82%D0%BE%D0%92%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5%D0%A1%D0%94%D0%BB%D0%B8%D0%BD%D0%BD%D1%8B%D0%BC%D0%98%D0%BC%D0%B5%D0%BC%D0%A4%D0%B0%D0%B9%D0%BB%D0%B0%D0%A1%D0%BE%D0%B2%D1%81%D0%B5%D0%BC%D0%91%D0%B5%D0%B7%D0%9F%D1%80%D0%BE%D0%B1%D0%B5%D0%BB%D0%BE%D0%B2%D0%98%D0%95%D1%89%D1%91%D0%A0%D0%B0%D0%B7%D0%AD%D1%82%D0%BE%D0%92%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5%D0%A1%D0%94%D0%BB%D0%B8%D0%BD%D0%BD%D1%8B%D0%BC%D0%98%D0%BC%D0%B5%D0%BC%D0%A4%D0%B0%D0%B9%D0%BB%D0%B0%D0%A1%D0%BE%D0%B2%D1%81%D0%B5%D0%BC%D0%91%D0%B5%D0%B7%D0%9F%D1%80%D0%BE%D0%B1%D0%B5%D0%BB%D0%BE%D0%B2%2Etxt => in kmail we don't split it.
Git commit 8538aca194e963f23999edc2e7e7307462c7dcfc by Laurent Montel. Committed on 07/05/2020 at 18:22. Pushed by mlaurent into branch 'release/20.04'. Fix Bug 362650 - an extra space character in attached file names the UTF-8 encoded FIXED-IN: 5.14.2 M +40 -0 autotests/headertest.cpp M +25 -4 src/kmime_header_parsing.cpp https://commits.kde.org/kmime/8538aca194e963f23999edc2e7e7307462c7dcfc
Git commit 4ed66cd8a362a28d3cb25a883df965ac093a6999 by Laurent Montel. Committed on 07/05/2020 at 18:24. Pushed by mlaurent into branch 'master'. Fix Bug 362650 - an extra space character in attached file names the UTF-8 encoded FIXED-IN: 5.14.2 M +40 -0 autotests/headertest.cpp M +25 -4 src/kmime_header_parsing.cpp https://commits.kde.org/kmime/4ed66cd8a362a28d3cb25a883df965ac093a6999
Thank you very much for the swift fix, Laurent! Works great now.