18

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

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

来自RFC882第 3.1.1 节：

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

好的，所以我只是解析一个标题字段，如果 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，但如果我的解析器严格按照规范定义的方式工作，typeandstart-info参数将导致单个字符串或更糟，导致解析器错误。

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

谢谢！

4

2 回答 2

17

It is a typo in the examples. Parameters must always be delimited with semicolons correctly, even when folded. The folding is not meant to change the semantics of a header, only to allow for readability and to account for systems that have line length restrictions.

于 2010-08-25T23:17:04.330 回答
1

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

于 2010-06-16T06:26:43.813 回答