MIME RFC“Content-Type”参数混淆？不明确的 RFC 规范

Question

我正在尝试在 C++/Qt 中为 multipart/related 实现一个基本的 MIME 解析器。

到目前为止，我一直在为标头编写一些基本的解析器代码，并且我正在阅读 RFC 以了解如何尽可能地接近规范。不幸的是，RFC 中有一部分让我有点困惑：

来自RFC882 第 3.1.1 节：

每个标题字段都可以被视为一个单独的逻辑行 ASCII 字符，包括一个字段名和一个字段体。 为了方便起见，这个概念的场体部分 实体可以拆分为多行表示；这 称为“折叠”。一般规则是，无论在哪里 可能是线性空白（不仅仅是 LWSP 字符），一个 CRLF 紧随其后的至少一个 LWSP-char 可能改为 插入。因此，单行

好的，所以我只是解析一个标题字段，如果 CRLF 后跟线性空格，我只是以一种有用的方式将它们连接起来以产生一个标题行。让我们继续...

来自RFC2045 第 5.1 节：

在 RFC 822 的增强 BNF 表示法中，Content-Type 标头字段 值定义如下：

 content := "Content-Type" ":" type "/" subtype
            *(";" parameter)
            ; Matching of media type and subtype
            ; is ALWAYS case-insensitive.

[...]

 parameter := attribute "=" value

 attribute := token
              ; Matching of attributes
              ; is ALWAYS case-insensitive.

 value := token / quoted-string

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

好的。因此，如果您想指定带有参数的 Content-Type 标头，只需这样做：

Content-Type: multipart/related; foo=bar; something=else

... 和同一个标题的折叠版本如下所示：

Content-Type: multipart/related;
    foo=bar;
    something=else

对吗？好的。在我继续阅读 RFC 时，我在 RFC2387 第 5.1 节（示例）中遇到了以下内容：

 Content-Type: Multipart/Related; boundary=example-1
         start="<950120.aaCC@XIson.com>";
         type="Application/X-FixedRecord"
         start-info="-o ps"

 --example-1
 Content-Type: Application/X-FixedRecord
 Content-ID: <950120.aaCC@XIson.com>

 [data]
 --example-1
 Content-Type: Application/octet-stream
 Content-Description: The fixed length records
 Content-Transfer-Encoding: base64
 Content-ID: <950120.aaCB@XIson.com>

 [data]

 --example-1--

嗯，这很奇怪。你看到Content-Type 标头了吗？它有许多参数，但并非所有参数都有“;”作为参数分隔符。

也许我只是没有正确阅读 RFC，但如果我的解析器严格按照规范定义的方式工作，type 和 start-info 参数将导致单个字符串或更糟，导致解析器错误。

小伙伴们，你们对此有何看法？只是 RFC 中的一个错字？还是我错过了什么？

谢谢！

Answer 1

这是示例中的错字。参数必须始终正确地用分号分隔，即使折叠时也是如此。折叠并不是为了改变标题的语义，只是为了提高可读性并考虑到有行长限制的系统。

Answer 2

很可能是一个错字，但总的来说（根据经验）你应该也能够“在野外”处理这种事情。特别是，邮件客户端在生成有效消息和遵循所有相关规范的能力方面大相径庭（如果有的话，在电子邮件/SMTP 世界中甚至比在 WWW 世界中更糟糕！）