MIME беспорядок параметра “Типа контента” RFC? Неясная спецификация RFC

Я пытаюсь реализовать основной синтаксический анализатор 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? Или я пропускал что-то?

Спасибо!

17
задан BastiBen 16 June 2010 в 07:13
поделиться

2 ответа

Это опечатка в примерах. Параметры всегда должны быть правильно разделены точкой с запятой, даже если они свернуты. Свертывание не предназначено для изменения семантики заголовка, а только для обеспечения удобочитаемости и для учета систем, которые имеют ограничения на длину строки.

16
ответ дан 30 November 2019 в 14:05
поделиться

Вполне возможно, что это опечатка, но в целом (и по опыту) вы должны быть в состоянии справиться с подобными вещами и "на природе". В частности, почтовые клиенты различаются дико в своей способности генерировать корректные сообщения и следовать всем соответствующим спецификациям (если что, в мире электронной почты/SMTP все еще хуже, чем в мире WWW!)

1
ответ дан 30 November 2019 в 14:05
поделиться
Другие вопросы по тегам:

Похожие вопросы: