引用的 MIME 媒体类型参数是不是允许转义引号？

Posted 2023-03-15

【中文标题】引用的 MIME 媒体类型参数是不是允许转义引号？

【英文标题】：Do quoted MIME media type parameters allow escaped quotes?引用的 MIME 媒体类型参数是否允许转义引号？

【发布时间】：2020-05-06 01:39:25

【问题描述】：

对于 Internet MIME 媒体类型 (RFC 6838)，可以引用参数 (RFC 2045)。例如下面表示foobar的值：

text/plain;test="foobar"

但是我可以在引用的参数中包含转义的引号吗？以下将表示 foo"bar 的值：

text/plain;test="foo\"bar"

如果是这样，那么转义转义字符呢？以下将表示 foo\bar 的值：

text/plain;test="foo\\bar"

任意转义字符怎么办？以下将表示fooxbar 的值，因为转义序列\x 将仅表示x：

text/plain;test="foo\xbar"

同样重要的是，哪个标准定义了这一点？

我猜至少允许转义引号和转义反斜杠，但我很难找到指定的位置。

【问题讨论】：

我希望这些受通用 RFC5322 语法的约束。不过，无论 RFC 怎么说，我都不希望重要的变体在客户端中可靠地工作。

@tripleee 感谢您提到另一个 RFC，但除此之外，我不得不说我看不出您的回答会更加含糊。我的意思是字面意思。您的回复中根本没有任何细节，如果我想让这句话更模糊，我不知道我该怎么做，除了删除实际的 RFC 编号。

那么让我重新表述一下。弄清楚 RFC 究竟规定了什么实际上并没有用处。您需要遵守的de facto 标准是由实施不佳的邮件客户端和浏览器设置的。如果这是您的目标，那么无论 RFC 是否在您身边，我都不希望转义之类的事情能够可靠地工作。你真正希望完成什么？

这类问题并不新鲜。这不是什么奇怪的、不可避免的困境。 1）你从de juro标准所说的开始，如果可以的话，实施。 2）你衡量是否有一些实践或事实上的标准如此重要，以至于它应该与de juro标准背道而驰。我们使用 HTTP、html、CSS 或其他任何东西来做到这一点，而且我们已经这样做了几十年。我的问题只是第一个问题：哪个标准管辖这一点，它说了什么。您可以回答 #2 作为奖励。您表示适用 RFC 5322，但没有告诉我它给出了什么规则。

“搞清楚 RFC 的具体规定并没有实际用处。”我们完全不同意。 RFC 或其他标准是开始的地方。我正在努力寻找开始的地方。我欢迎知道实践的不同之处。但是@tripleee，您既没有告诉我标准是什么，也没有告诉我实践有何不同；相反，您是在抱怨这个问题，并在抱怨所谓的提问是徒劳的。

【参考方案1】：

我还没有一个完整的答案，但我知道WhatWG says 那个MIME 类型参数值必须包含HTTP quoted-string token code points。虽然它提供了自己的定义，但 WhatWG 引用了RFC 7230 § 3.2.6. Field Value Components，它允许几乎任何转义：

quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext         = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text
obs-text       = %x80-FF
quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )

但是它指出：

发送者不应在带引号的字符串中生成带引号的对，除非需要引用 DQUOTE 和该字符串中出现的反斜杠八位字节。

还要注意RFC 5322 § 3.2.1. Quoted characters 也有一些规则。 RFC 6838 管理媒体类型提到了RFC 6532 § 3.2. Syntax Extensions to RFC 5322，尽管在参数值的上下文中没有明确说明。