User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 Build Identifier: 3.6.3 Similar to bug 328628 and bug 481821 - both of which are marked as resolved, even though this issue exists in the latest release of Bugzilla 3.6. If I upload a filename with non-ASCII characters and then try to download it, the "save as" dialog shows a quoted-printable UTF-8 character sequence instead of the non-ASCII characters. This behavior varies slightly depending on the browser. Firefox has no problems. Both Internet Explorer (including IE8) and Safari show the quoted-printable string. Chrome just gives up and tries to download as "attachment.cgi". Reproducible: Always Steps to Reproduce: 1. Try to download the attachment for this bug. (Don't use Firefox, it behaves correctly.) Actual Results: Internet Explorer tries to download as: =_UTF-8_Q_=D0=A2=D0=B5=D0=BA=D1=81=D1=82=D0=BE=D0=B2=D1=8B=D0=B9=20=D0=B4=D0=BE=D0=BA=D1=83=D0=BC=D0=B5=D0=BD=D1=82_=.htm Expected Results: It should have tried to download as: Текстовый документ.xxx The attachment data is not lost. Only the filename is incorrect, which is a big inconvenience for non-English users.
Created attachment 498270 [details] Filename with Russian characters Borrowed the attachment from bug 328628 for demonstration purposes.
confirmed for b.m.o and Internet Explorer 8.0.7600.16385 Firefox 3.6.13 works as expected
As I have replied at support-webtools ml, this is a well know bug on Internet Explorer as mentioned in http://support.microsoft.com/kb/436616/ja # I could not find English version of this knowledge base. Full resolution for this 'Japanese' multi-byte in utf-8 issue does NOT exist. (Quick hack described in that kb for ASP.Net system does not solve in some situation.) I propose INVALID for this :-p
If this is a browser bug, then yes, I'm not sure we can do a lot about it.
I think what we can do here is sniff the UA and encode the filename differently depending on which browser is in use. That's going to be the only solution that I can think of that will actually end up working across all browsers. I saw a link (I think that glob found it?) that had a table that showed which browsers supported which encoding methods. It'd be great to have that link again.
i think max it talking about http://greenbytes.de/tech/tc2231/
Bug 1096394 contains a patch which correctly implements RFC 6266. Either nE0sIghT (the original author of the patch) or I will update it and attach it here for review.
Created attachment 8739258 [details] [diff] [review] patch, v1
Comment on attachment 8739258 [details] [diff] [review] patch, v1 Review of attachment 8739258 [details] [diff] [review]: ----------------------------------------------------------------- r=dkl
To ssh://email@example.com/bugzilla/bugzilla.git f97a463..437d7e2 master -> master
Created attachment 8812752 [details] [diff] [review] For people wanting an immediate patch on 5.0.3 For people wanting an immediate patch on 5.0.3 This was quite important for my organisation, so i limited the changes to the basic stuff. Both uploading and downloading tested... briefly.
Not sure if this is the correct place to ask, however 'For the people wanting an immediate patch on 5.0.3' how do we install the fix exactly? Running 5.3 (Windows box with Apache) and have an issue where some attachments when downloading through IE show the UTF 8 encode rather than the actual file name. FF doesn't have the issue. It sounds like the issue described here.