Поле заголовка "Content-Type"
Назначение этого поля - наиболее полное описание данных, содержащихся в теле, с тем, чтобы почтовый агент (программа) получателя могла выбрать соответствующий механизм для их обаботки. Впервые это поле было определено в RFC 1049, но имело более простой синтаксис.
Данное поле включает в себя идентификаторы типа и подтипа, а также может содержать некоторую вспомогательную информацию, которая может потребоваться для конкретного типа данных. После идентификаторов типа и подтипа оставшаяся часть поля - просто набор парамеров, заданных в порядке "атрибут/значение". Набор параметров зависит от типа данных. (В частности, не может быть глобально-значимых параметров, справедливых сразу для всех типов содержимого ьела письма. Глобальные механизмы в MIME-модели реализованы с помощью введения дополнительных полей "Content-*"). Очередность параметров значения не имеет. В числе определенных параметров - "charset", декларирующий символьный набор (кодировку, кодовую страницу - это все синонимы) тела письма. Комментарии допускаются.
Вообще, поле Content-Type самого верхнего уровня используется для объявления общего типа данных, в то время как подтип определяет специальный формат для данных этого типа. Так, значение "image/xyz" поля Content-Type сообщает пользовательской программе, что данные являются графическим изображением (image), даже если эта почтовая программа не имеет понятия о специальном формате "xyz" этой картинки. Но эта информация может быть использована программой, например, чтобы решить, показывать ли пользователю строкоые данные неизвестного подтипа -- показ таких данных может быть оправдан для незнакомых подтипов текста, но не для незнакомых подтипов графики, аудио или видео. По этой причине, данные зарегистрированного подтипа аудио, графики, текста или видео не должны содержать внутри себя части другого подтипа - для содержания в письме данных одного типа, но разных подтипов следует использовать тип "multipart" или "application".
Хотя многие параметры ( модификаторы подтипов) имеют смысл лишь для конкретного типа, некоторые все же являются глобальными в том смысле. что они применимы ко всем типам (например, параметр "boundary" применим только с типом "multipart", а параметр "charset" может использоваться с несколькими типами).
Пока имен типов только семь, и пока этого достаточно. Кроме того, предполагается, что расширение существующего набора поддерживаемых типов данных будет производиться засчет введения новых подтипов этих изначально определенных типов данных. В будущем добавление имен типов верхнего уровня может быть произведено только при принятии новой версии стандарта MIME. Если по какой-либо другой причине в существующей версии используется незарегестрированный тип содежимого, ему должно быть дано имя, начинающееся с "X-", чтобы подчеркнуть его нестандартный статус и заранее предупредить конфликт с официальным именем типа, которое может быть введено позднее.
Правильное заполнение поля Content-Type:
содержимое := "Content-Type" ":" тип "/" подтип *(";" параметр) ; нечувствительное к регистру букв задание типа и подтипа тип := "application" / "audio" / "image" / "message" / "multipart" / "text" / "video" / признак нестандартного типа ; Все значения нечувствительны к регистру букв признак нестандартного типа := x- / iana- iana- := <общепринятый признак расширения, зарегистрированный соответ- ственно приложению "E" RFC 1521>
x- := <Два последовательных символа "X-" или "x-", без пробела или другого символа между ними>
подтип := слово ; регистр безразличен параметр := атрибут "=" значение атрибут := слово ; регистр безразличен значение := слово / строка в кавычках слово := любые ASCII-символы кроме пробелов, Ctrl-последова- тельностей и специальных символов Специальные символы:= "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <">
/ "/" / "[" / "]" / "?" / "=" ; Эти символы используются в строке значений параметров
Здесь набор специальных символов отличается от набора, определенного в RFC 822 только наличием символов "/", "?", "=" и отсутствием символа ".".
Указание подтипа в данном поле является обязательным, т.к. нет подтипов по умолчанию. В отличие от имен типов, подтипов и параметров, значения параметров в общем случае являются чувствительными к регистру букв, но могут быть и нечувствительными - в зависимости от параметра. Например, значения границ multipart-письма являются чувствительными, а значение "access-type" для message/External-body не является.
Существует два приемлимых механизма для введения новых подтипов для поля Content-Type:
Семь предопределенных типов верхнего уровня, более детально, представляют собой следующее:
text -- текстовая информация. Основой подтип - "plain" - соответствует обычному неформатировнному тексту и не требует специального программного обеспечения для отображения этого текста за исключением поддержки национальных кодировок. Другие подтипы используются в случае размеченного текста, когда с помощью специальной программы можно улучшить его визуалзацию, но для понимания идеи содержания можно обойтись и без дполнительного ПО. Возможные подтипы могут описывать легкочитаемые форматы различных текстовых процессоров.
multipart -- содержимое письма состоит из некоторого множества частей, содержащих данные различных взаимонезависимых типов. Изначально определено четыре подтипа:
message -- письмо в письме. Тело, содержащее данные типа "message", само является письмом или частью письма, полностью отформатированного в соответствии со стандартом RFC 822, которое, в свою очередь, может содержать свое собственное поле заголовка "Content-Type".
Подтипы:
- "rfc822" - основной;
- "partial" - определен для частично-цитируемых писем для предотвращения фрагментирования тел содержащихся писем в случае слишком большой их общей длины для возможностей почтового транспорта;
- "External-body" - используется, чтобы указать, что тело письма очень большое и находится вне письма.
image -- графические данные. Графика требует соответствующего устройства вывода (графический дисплей, принтер, факс) для отображения своей информации. Изначально определены два подтипа для наиболее распространенных графических форматов - jpeg и gif.
audio -- звуковая информация. Требует звуковое устройство (динамик или наушники) для вывода информации. Основной подтип - "basic".
video -- видео. Требует специальных аппаратных и программных возможностей для отображения видео-информации. Единстванный изначально определенный подтип - "mpeg".
application -- как правило, неинтерпретируемый двоичный код либо информация, предназначенная для обработки почтовой программой.
Подтипы:
- "octet-stream" - основной подтип; предназначен для неинтерпретируемых двоичных данных, для которых рекомендуемым действием является предложение пользователю сохранить в файл на диске.
- "PostScript" - дополнительный подтип; применяется при пересылке PostScript-документов в теле письма.
По умолчанию, письма, как и в стандарте RFC 822 пишутся простым (неразмеченным) текстом в языковой кодировке US-ASCII, что по спецификации MIME может быть описано как "Content-type: text/plain; charset=us-ascii". Это значение полагается, если поле Content-type не определено. Поэтому почтовая программа получателя может неверно истолковать содержимое письма, если при отправке не было указано поле Content-type, но на самом деле текст письма имеет другую кодировку или даже тип.
При отсутствии поля Content-type или поля MIME-Version в заголовке MIME-письма нельзя быть точно уверенным, что письмо имеет языковую кодировку именно US-ASCII, поскольку могут еще встречаться почтовые программы, не использующие соглашения MIME. Но хотя возможно, что письмо, не содержащее в заголовке полей MIME-Version и Content-Type, может содержать все, что угодно, например, юниксовский tar-архив, сжатый gzip'ом и обработаный uuencode, все же, создателям почтовых программ рекомендуется оставлять этот факт без внимания и ориентироваться на значение по умолчанию, т.е. "text/plain; charset=us-ascii".
Необходимо учесть, что в будущем ожидается заметное увеличение числа регистрированных типов и особенно подтипов содержимого писем. Если почтовая программа встретит неизвестное ей значение поля Content-type, она должна интерпретировать содержимое этого письма как "application/octet-stream" (см.выше).
