Я пытаюсь реализовать основной синтаксический анализатор MIME для multipart/related
в C++ / QT.
До сих пор я писал некоторый основной код синтаксического анализатора для заголовков, и я читаю RFCs, чтобы понять, как сделать все максимально близко к спецификации. К сожалению, существует часть в RFC, который смущает меня немного:
От раздела RFC882 3.1.1:
Каждое поле заголовка может быть просмотрено как единственная, логическая строка символов ASCII, включив имя поля и полевое тело. Для удобства часть полевого тела этого концептуального объекта может быть разделена на многолинейное представление; это называют, "сворачиваясь". Общее правило состоит в том, что везде, где может быть линейный пробел (НЕ просто LWSP-символы), CRLF, сразу сопровождаемый ПО КРАЙНЕЙ МЕРЕ одним LWSP-символом, может вместо этого быть вставлен. Таким образом, одна строка
Хорошо, таким образом, я просто анализирую поле заголовка и если CRLF следует с линейным пробелом, я просто concat те, которые полезным способом для приведения к единственной строке заголовка. Давайте продолжим двигаться...
От раздела RFC2045 5.1:
В Увеличенной нотации BNF RFC 822 значение поля заголовка Типа контента определяется следующим образом:
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*
Хорошо. Таким образом, кажется, хотите ли Вы указать a Content-Type
заголовок с параметрами, просто сделайте это как это:
Content-Type: multipart/related; foo=bar; something=else
... и свернутая версия того же заголовка была бы похожа на это:
Content-Type: multipart/related;
foo=bar;
something=else
Корректный? Хороший. Когда я продолжал читать RFCs, я столкнулся со следующим в Разделе 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
заголовок? Это имеет много параметров, но не все имеют a""; как разделитель параметра.
Возможно, я просто не считал RFCs правильно, но если мои работы синтаксического анализатора строго как спецификация определяют, type
и start-info
параметры привели бы к единственной строке или хуже, ошибка синтаксического анализатора.
Парни, какова Ваша мысль об этом? Просто опечатка в RFCs? Или я пропускал что-то?
Спасибо!
Это опечатка в примерах. Параметры всегда должны быть правильно разделены точкой с запятой, даже если они свернуты. Свертывание не предназначено для изменения семантики заголовка, а только для обеспечения удобочитаемости и для учета систем, которые имеют ограничения на длину строки.
Вполне возможно, что это опечатка, но в целом (и по опыту) вы должны быть в состоянии справиться с подобными вещами и "на природе". В частности, почтовые клиенты различаются дико в своей способности генерировать корректные сообщения и следовать всем соответствующим спецификациям (если что, в мире электронной почты/SMTP все еще хуже, чем в мире WWW!)