RFC标准是否要求将MIME附件的文件名值封装在引号中? [英] Do RFC standards require the filename value for MIME attachment to be encapsulated in quotes?

问题描述

我有两个冲突的代码段.一个产生:

I have two conflicting sections of code. One produces:

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"

不带引号的代码将导致接收应用程序出现意外行为.是否需要报价?

The one without quotes is resulting in unexpected behavior by a receiving application. Are quotes required?

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

In RFC 2183 I don't see an explicit requirement:

在[RFC 822]的扩展BNF表示法中，内容处置
标头字段定义如下:

In the extended BNF notation of [RFC 822], the Content-Disposition
header field is defined as follows:

 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

也许我还是瞎子.有人可以确认吗?

Perhaps I'm blind though. Can someone please confirm?

推荐答案

BNF下面是这段内容:

Just below the BNF is this passage:

定义了扩展令牌"，参数"，"tspecials"和值"根据[RFC 2045](在定义中引用了[RFC 822]其中一些标记)."quoted-string"和"DIGIT"在[RFC 822].

`Extension-token', `parameter', `tspecials' and `value' are defined according to [RFC 2045] (which references [RFC 822] in the definition of some of these tokens). `quoted-string' and `DIGIT' are defined in [RFC 822].

2045在5.1节中有此定义(但是描述了 Content-type:):

2045 has this definition in section 5.1 (which however describes 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 的文件名；但是如果它包含任何 tspecials (或控制字符或空格)，则必须将其引号毕竟.

So a filename which is a token does not need to be quoted; but if it contains any of the tspecials (or control characters or whitespace), you need to quote it after all.

只是为了专门解决下划线问题，它不是一个字符，不需要根据RFC引用 (它不是控件，空格，也不是作为 tspecials之一枚举)，但事情万物皆有可能，最好以引用为宜，以防万一.(我们将其称为反Postel吗?对所传输的内容过于保持僵化，对认为明显无效的输入不要太宽容.)

Just to specifically address the case of underscore, it is not a character which requires quoting according to the RFC (it's not control, whitespace, or enumerated as one of the tspecials), but the way things are in the wild, you are probably better off quoting everything just in case. (Shall we call this anti-Postel? Be unduly conervative about what you transmit, and don't be too liberal in what you think you can infer about obviously invalid input.)

顺便说一句，电子邮件中的MIME文件名实际上完全是Wild West.许多流行的应用程序只是忽略了RFC2231，而是在这里改用RFC2047编码，或者不使用编码，或者完全使用他们自己的临时我认为这可能有用，没有人抱怨"组合.

As a bit of an aside, MIME filenames in email are in practice completely the Wild West; a lot of popular applications simply ignore RFC2231 and use RFC2047 encoding here instead, or no encoding, or completely their own ad hoc "I thought this might work and nobody has complained" concoctions.

这篇关于RFC标准是否要求将MIME附件的文件名值封装在引号中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！