decoding filenames containing `*'s

[Katsumi Yamaoka <yamaoka@jpl.org>]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

Hi,

ARISAWA Akihiro reported Gnus doesn't decode file names that
attachments specify if there are the asterisk characters which
aren't quoted in those names.  For example, the file attached
below has the name "a*.txt" (you can see it by typing `C-u g').


[-- Attachment #2: a*.txt --]
[-- Type: application/octet-stream, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 59 bytes --]

Another example which has the Japanese file name follows:


[-- Attachment #4: オンライン.txt --]
[-- Type: application/octet-stream, Size: 0 bytes --]



[-- Attachment #5: Type: text/plain, Size: 1424 bytes --]

I've fixed the `rfc2231-parse-string' function in both the trunk
and the v5-10 branch so that they might be decoded.

That the file name "a*.txt" doesn't appear in the former MIME
button is due to a bug of Gnus, because RFC2183 and RFC2045 does
not request that `*'s should be encoded in parameter values.
ARISAWA-san quoted the related specifications as follows:

RFC2183:
========
     filename-parm := "filename" "=" value
[...]
   NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters)
   parameter value containing only non-`tspecials' characters SHOULD be
   represented as a single `token'.  A short parameter value containing
   only ASCII characters, but including `tspecials' characters, SHOULD
   be represented as `quoted-string'.

RFC2045:
========
     value := token / quoted-string

     token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
                 or tspecials>

     tspecials :=  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "\" / <">
                   "/" / "[" / "]" / "?" / "="

As for the latter case, that the Japanese file name isn't decoded
is due to a bug of a certain mailer (he wrote that some version
of Thunderbird does it), since (also he wrote) RFC2231 specifies
that `*'s should be encoded in the `extended-parameter'.  Even
so, because there is no reason that they should not be decoded,
Gnus now decodes such parameter values, though.

Regards,