Я пытаюсь реализовать базовый синтаксический анализатор MIME для multipart/related в C ++ / Qt.
До сих пор я писал некоторый основной код синтаксического анализатора для заголовков, и я читаю RFC, чтобы получить представление о том, как сделать все максимально приближенным к спецификации. К сожалению, в RFC есть часть, которая меня немного смущает:
С RFC882 Раздел 3.1.1:
Каждое поле заголовка можно рассматривать как одну логическую строку
Символы ASCII, содержащие имя поля и тело поля.
Для удобства полевая часть этого концептуального
сущность может быть разбита на многострочное представление; этот
называется "складной". Общее правило таково, что везде
может быть линейно-пробелом (НЕ просто LWSP-символами), CRLF
сразу за ним по крайней мере один LWSP-символ может быть вместо
вставлено. Таким образом, единственная строка
Хорошо, поэтому я просто анализирую поле заголовка, и если CRLF следует с линейным пробелом, я просто конкатюрирую его полезным способом, чтобы получить одну строку заголовка. Давайте продолжим ...
С RFC2045 Раздел 5.1:
В расширенной нотации BNF RFC 822 поле заголовка 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? Или я что-то пропустил?
Спасибо!