On 27 May 2001 18:03:12 -0700, Richard Zach wrote:
Note that RFC 2183 does not require (ie, it doesn't say SHOULD or MUST) that the filename attribute be used as the basis for the name of the saved file.Oops, what I meant to say was: 2183 doesn't require that the filename attribute be used as the saved filename, but recommends that it be used as the BASIS for the filename and that the filename be changed according to avoid file name conflicts, enusre legal filename on local filesystem, etc. RFC 2184 specifies how to deal with long filename parameters and filenames containing non-ascii characters, but Evolution currently neither recognizes nor produces RFC2184-compliant MIME-headers. Here's how different mailers set the filename attribute: 1. Elm and Evolution: filename="áó éíñ.txt" 2. Mozilla: filename="=?iso-8859-1?Q?=E1=F3=20=E9=ED=F1=2Etxt?=" 3. Outlook filename="=?iso-8859-1?B?4fMg6e3xLnR4dA==?=" 4. Pine filename*="X-UNKNOWN''%E1%F3 %E9%ED%F1.txt" 1 is illegal since it contains 8-bit characters, which can't occur in a quoted-text string. 2 and 3 are legal, but don't have the right semantics: if an attribute value starts and ends with "'s, it's a quoted-string, and so "=?iso-8859-1?B?4fMg6e3xLnR4dA==?=" refers to the string
actually, 2 and 3 are NOT legal.
=?iso-8859-1?B?4fMg6e3xLnR4dA==?= and not the intended áó éíñ.txt 4 is legal, but not RFC 2184-compliant, since extended-value isn't supposed to have any quotes around it, or spaces within.
4 isn't "legal" either if you are going strictly by the RFCs. I guess you are using legal and rfc-compliant differently, while I'm using them as if they were the same.
The correct way would be: filename*=X-UNKNOWN''%E1%F3%20%E9%ED%F1.txt
right
Evolution should generate the correct version, and accept the incorrect versions (ie, interpret all versions above as "áó éíñ.txt")
Attached is a patch to make it accept all of the broken versions above,
accept the correct version, and generate the correct version.
It will also accept and correctly combine header such as:
Content-Disposition: attachment;
filename*0*=us-ascii'en'This%20is%20a%20;
filename*1*=simple%20multiline%20test%20;
filename*2="of rfc2184 params"
Note: In testing this, I noticed that the composer's attachment bar does
not correctly render UTF-8 strings.
Zucchi: is it okay to commit this patch? The only part I'm iffy about is
the header_encode_param() function which is kinda dodgy and should
probably use the private tables and such. Also, I'm a bit worried about
the hex-encoding of the unicode char that is > 256 - not sure how that
should be done.
Jeff
Attachment:
rfc2184.diff
Description: Text document