我正在尝试为multipart/related
in 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,但如果我的解析器严格按照规范定义的方式工作,type
andstart-info
参数将导致单个字符串或更糟,导致解析器错误。
小伙伴们,你们对此怎么看?只是 RFC 中的一个错字?还是我错过了什么?
谢谢!