Re: [Evolution] Attachment names with =?ISO-8859-1?Q?=E1=F3=E9=ED=F1?= screwed up

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,

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:
3. Outlook
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.


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:


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


Attachment: rfc2184.diff
Description: Text document

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]