Я пытаюсь реализовать базовый синтаксический анализатор MIME для multipart/related в С++/Qt.
До сих пор я писал базовый код парсера для заголовков, и я читаю RFC, чтобы получить представление о том, как сделать все как можно ближе к спецификации. К сожалению, в RFC есть часть, которая меня немного смущает:
От RFC882 Раздел 3.1.1:
Каждое поле заголовка можно рассматривать как единую логическую строку ASCII-символы, содержащие имя поля и поле-тело. Для удобства полевая часть этого концептуального объект можно разделить на многострочное представление; это называется "складыванием". Общее правило гласит, что везде может быть линейно-белое пространство (не просто LWSP-символы), CRLF сразу же после чего следует, что один LWSP- char может быть вставлено. Таким образом, единственная строка
Хорошо, поэтому я просто разбираю поле заголовка, и если 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="<[email protected]>";
type="Application/X-FixedRecord"
start-info="-o ps"
--example-1
Content-Type: Application/X-FixedRecord
Content-ID: <[email protected]>
[data]
--example-1
Content-Type: Application/octet-stream
Content-Description: The fixed length records
Content-Transfer-Encoding: base64
Content-ID: <[email protected]>
[data]
--example-1--
Хм, это странно. Вы видите заголовок Content-Type? У него есть ряд параметров, но не у всех есть ";" как разделитель параметров.
Возможно, я просто не читал RFC правильно, но если мой парсер работает строго так, как указано спецификацией, параметры type и start-info приведут к одной строке или, что еще хуже, ошибке парсера.
Ребята, что вы думаете об этом? Просто опечатка в RFC? Или я что-то пропустил?
Спасибо!
Это опечатка в примерах. Параметры всегда должны быть разделены точками с запятой правильно, даже когда они сложены. Сгибание не предназначено для изменения семантики заголовка, только для обеспечения удобочитаемости и учета систем с ограничениями длины строки.
Вполне возможно, опечатка, но в целом (и из опыта) вы также сможете справиться с такими вещами "в дикой природе". В частности, почтовые клиенты сильно отличаются своей способностью генерировать достоверные сообщения и следовать всем соответствующим спецификациям (во всяком случае, это еще хуже в мире электронной почты /SMTP, чем в мире WWW!)