Интегрированные сети ISDN

         

Поле заголовка Content-Type


4. Поле заголовка Content-Type



Задачей поля Content-Type является описание информации, содержащейся в теле сообщения. Этого описания должно быть достаточно, чтобы принимающий агент пользователя был способен воспринять и отобразить полученные данные. Значение этого поля называется типом среды.

Поле заголовка Content-Type было первым, определенным в документе RFC-1049. В RFC-1049 использовался более простой и менее мощный синтаксис, который, в прочем, вполне согласуется с регламентациями MIME.

Поле заголовка Content-Type специфицирует природу данных в теле объекта, сообщая тип среды и идентификаторы субтипа, а также предоставляя вспомогательную информацию, которая может требоваться для определенного типа среды. После типа среды и имен субтипов может следовать набор параметров, который описывается в нотации атрибут = значение. Порядок параметров не имеет значения. Тип среды верхнего уровня используется для декларирования общего типа данных, в то время как субтип определяет специфический формат информации. Таким образом, типа среды "image/xyz" достаточно, чтобы сообщить агенту пользователя, что данные представляют собой изображение, даже если агент пользователя не имеет представления о формате изображения "xyz". Такая информация может использоваться, например, для того чтобы решить, следует ли показывать пользователю исходные данные нераспознанного субтипа. Такая операция разумна для нераспознанного субтипа текста, но бессмысленна для изображения или звука. По этой причине, зарегистрированные субтипы текста, изображения, аудио и видео не должны содержать вложенной информации другого типа. Такой составной формат должен быть представлен с использованием "multipart" или "application" типов.

Параметры являются модификаторами субтипа среды и по этой причине не могут существенно влиять на природу содержимого. Набор значимых параметров зависит от типа и субтипа среды. Большинство параметров связано с одним специфическим субтипом.
Однако тип среды верхнего уровня может определить параметры, которые применимы к любому субтипу данного типа. Параметры могут быть необходимы для определенных типов и субтипов, могут они быть и опционными. Реализации MIME должны игнорировать любые параметры, если их имена не распознаны.

Например, параметр "charset" применим к любому субтипу "текста", в то время как параметр "boundary" необходим для любого субтипа типа среды "multipart". Не существует параметров, применимых для всех типов среды.

Исходный набор из семи типов среды верхнего уровня определен в документе RFC 2046. Пять из них являются дискретными типами. Остальные два являются составными типами, чье содержимое требует дополнительной обработки процессорами MIME.

Этот набор типов среды верхнего уровня является замкнутым. Предполагается, что необходимые расширения набора могут осуществляться за счет введения субтипов к существующим базовым типам. В будущем, расширение базового набора допустимо лишь при смене стандарта. Если необходим какой-то новый базовый тип среды, его имя должно начинаться с "X-", что указывает на то, что он не является стандартным.



4.1. Синтаксис поля заголовка Content-Type



В нотации BNF, значение поля заголовка Content-Type определяется следующим образом:



content := "Content-Type" ":" type "/" subtype *(";" parameter) ; Распознавание типа и субтипа среды всегда не зависит от регистра, в котором они напечатаны.
type := discrete-type / composite-type  
discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token  
composite-type := "message" / "multipart" / extension-token  
extension-token := ietf-token / x-token  
ietf-token :=  
x-token :=  
subtype := extension-token / iana-token  
iana-token :=  
parameter := attribute "=" value  
attribute := token ; Распознавание атрибутов не зависит от регистра, в котором они напечатаны.
value := token / quoted-string  
token := 1*  
tspecials := "(" / ")" / "" / "@" / "," / ";" / ":" / "\" / "/" / "[" / "]" / "?" / "=" ; Должно представлять собой строку в кавычках
<


/p> Заметим, что определение "tspecials" совпадает с определением "specials" в RFC 822 с добавлением трех символов "/", "?" и "=" и удалением "." (точка).

Заметим также, что спецификация субтипа является MANDATORY - она не может быть удалена из поля заголовка Content-Type. Не существует субтипов по умолчанию. Тип, субтип и имена параметров не зависят от регистра, в которых они напечатаны. Например, TEXT, Text и TeXt являются эквивалентными типами среды верхнего уровня. Значения же параметров в норме чувствительны к регистру, в котором они напечатаны, но иногда интерпретируются без учета регистра в зависимости от приложения. (Например, границы типа multipart являются чувствительными к регистру, а параметр "access-type" для сообщения message/External-body не чувствителен.)

Обратите внимание, что значение строки в кавычках не включает в себя сами кавычки. В полях заголовка в соответствии с RFC 822 допускаются комментарии. Таким образом, две приведенные ниже формы являются эквивалентными.

Content-type: text/plain; charset=us-ascii (Plain text)

Content-type: text/plain; charset="us-ascii".

Предполагается, что имена субтипов при их применении не вызовут конфликтов. Так недопустимо, чтобы в различных приложениях "Content-Type: application/foobar" означало различные вещи. Существует два приемлемых механизма определения новых субтипов среды.

  1. Частные значения (начинающиеся с "X-") могут быть определены для двух взаимодействующих агентов без официальной регистрации или стандартизации.


  2. Новые стандартные значения должны регистрироваться IANA, как это описано в RFC 2048.




4.2. Значения по умолчанию Content-Type



Сообщения по умолчанию без MIME-заголовка Content-Type согласно протоколу должны содержать простой текст с символьным набором ASCII, который может быть специфицирован явно.

Content-type: text/plain; charset=us-ascii

Это значение подразумевается, если не специфицировано поле заголовка Content-Type.Рекомендуется, чтобы это значение по умолчанию использовалось в случае, когда встретилась нераспознанное значение поля заголовка Content-Type. В присутствии поля заголовка MIME-Version и отсутствии поля Content-Type, принимающий агент пользователя может также предположить, что отправитель предлагает простой текст в ASCII-кодировке. Простой ASCII-текст может предполагаться в отсутствии MIME-Version или в присутствии синтаксически некорректного поля заголовка Content-Type, хотя это может и не совпадать с намерениями отправителя.




Содержание раздела