RFC 标准是否要求将 MIME 附件的文件名值封装在引号中？

Question

我有两个相互冲突的代码部分。一种产生：

Content-Type: text/html; name=foo_foo2.blah
Content-Disposition: attachment; filename=foo_foo2.blah

另一个产生：

Content-Type: text/html; name="foo_foo2.blah"
Content-Disposition: attachment; filename="foo_foo2.blah"

没有引号的会导致接收应用程序出现意外行为。是否需要报价？

在RFC 2183 中，我没有看到明确的要求：

在 [RFC 822] 的扩展 BNF 符号中，Content-Disposition
头域定义如下：

 disposition := "Content-Disposition" ":"
                disposition-type
                *(";" disposition-parm)

 disposition-type := "inline"
                   / "attachment"
                   / extension-token
                   ; values are not case-sensitive

 disposition-parm := filename-parm
                   / creation-date-parm
                   / modification-date-parm
                   / read-date-parm
                   / size-parm
                   / parameter

 filename-parm := "filename" "=" value

 creation-date-parm := "creation-date" "=" quoted-date-time

 modification-date-parm := "modification-date" "=" quoted-date-time

 read-date-parm := "read-date" "=" quoted-date-time

 size-parm := "size" "=" 1*DIGIT

 quoted-date-time := quoted-string
                  ; contents MUST be an RFC 822 `date-time'
                  ; numeric timezones (+HHMM or -HHMM) MUST be used

或许我是瞎子吧。有人可以确认吗？

Answer 1

BNF 正下方是这段话：

“扩展令牌”、“参数”、“tspecials”和“值”是根据 [RFC 2045] 定义的（在这些令牌的定义中引用了 [RFC 822]）。`quoted-string' 和 `DIGIT' 在 [RFC 822] 中定义。

2045 在第 5.1 节中有这个定义（但是它描述了Content-type:）：

  value := token / quoted-string

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

 tspecials :=  "(" / ")" / "<" / ">" / "@" /
               "," / ";" / ":" / "\" / <">
               "/" / "[" / "]" / "?" / "="
               ; Must be in quoted-string,
               ; to use within parameter values

所以token不需要引用a 的文件名；但如果它包含任何tspecials（或控制字符或空格），你毕竟需要引用它。

只是为了具体解决下划线的情况，它不是一个需要根据 RFC引用的字符（它不是控制、空格或枚举为其中之一tspecials），但事情的发展方式，你可能会更好引用一切以防万一。（我们可以称其为反 Postel 吗？对您传输的内容过于保守，并且对于您认为可以推断明显无效输入的内容不要过于自由。）

顺便说一句，电子邮件中的 MIME 文件名实际上完全是狂野的西部；许多流行的应用程序简单地忽略 RFC2231 并在此处使用 RFC2047 编码，或者不编码，或者完全是他们自己的临时“我认为这可能有效，没有人抱怨”混合物。