Question

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

到目前为止，我一直在为头文件编写一些基本的解析器代码，我正在阅读RFC，以便了解如何尽可能接近规范来完成所有操作。不幸的是，RFC中有一部分让我感到困惑：

来自RFC882第3.1.1节：

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

好吧，所以我简单地解析一个头字段，如果一个CRLF跟随线性空格，我只是以有用的方式连接它们以产生一个标题行。我们继续......

来自RFC2045第5.1节：

在RFC 822的Augmented 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世界更糟糕）狂野。< / p>

MIME RFC“Content-Type”参数混淆？不清楚RFC规范

2 个答案: