问题描述
我有两个冲突的代码段.一个产生:
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:
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:
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附件的文件名值封装在引号中?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!