Content type какие бывают
+7 (499) 322 88 70
ok@systems.education
- Переподготовка
- Системный анализ
- Интеграция систем
- Базы данных
- Бизнес-анализ
- Продуктовый дизайн
Глава 3: Форматы данных
Брайан Кукси — опубликовано 22 апреля 2014
Итак, мы узнали, что HTTP является основой API-интерфейсов в интернете и что для их использования нам необходимо знать, как работает HTTP. В этой главе мы исследуем, какие данные предоставляют API, как они форматируются и как HTTP делает это возможным.
Представление данных
При обмене данными с людьми возможности отображения информации ограничиваются только человеческой фантазией. Вспомните пиццерию из предыдущей главы — как она может оформить своё меню? Например, как текстовый список или маркированный список, может быть серией фотографий с подписями или только набором фотографий, на которые показывают посетители, чтобы оформить заказ.
Хорошо продуманный формат помогает целевой аудитории понимать информацию.
Тот же принцип применяется при обмене данными между компьютерами. Один компьютер должен поместить данные в формат, понятный для другого. Обычно это какой-то текстовый формат.
Наиболее распространёнными форматами, встречающимися в современных API, являются JSON (JavaScript Object Notation, нотация объектов JavaScript) и XML (Extensible Markup Language, расширяемый язык разметки) .
JSON
Многие новые API-интерфейсы приняли JSON в качестве формата, потому что он построен на популярном языке программирования Javascript, который повсеместно используется в интернете и применим как на фронте, так и на бэкенде веб-приложения или сервиса. JSON — это очень простой формат, состоящий из двух частей: ключей (keys) и значений (values). Ключи представляют собой свойство, атрибут описываемого объекта. Заказ пиццы может быть объектом. У него есть атрибуты (ключи), такие как тип корочки, начинка и статус заказа. У этих атрибутов есть соответствующие значения (толстое тесто, пепперони и «доставляется»).
Посмотрим, как этот заказ пиццы может выглядеть в JSON:
В приведенном выше примере JSON ключевыми словами являются слова слева: начинка, корочка и статус. Они говорят нам, какие атрибуты содержит заказ пиццы. Значения указаны в частях справа. Это фактические детали заказа.
Рисунок 1. Ключ и значение JSON
Если вы прочитаете строку слева направо, вы получите довольно естественное английское предложение. Взяв, к примеру, первую строчку, мы могли бы прочитать её как «корочка для этой пиццы оригинального стиля». Вторая строка также может быть прочитана — в JSON значение, которое начинается и заканчивается квадратными скобками ([]), представляет собой список значений. Итак, мы читаем вторую строку заказа как «начинки для этого заказа: сыр, пепперони и чеснок».
Иногда вы хотите использовать объект в качестве значения для ключа. Давайте расширим наш заказ пиццы подробностями о клиенте, чтобы вы могли увидеть, как это может выглядеть:
В этой обновленной версии мы видим, что добавлен новый ключ «клиент». Значение этого ключа — это еще один набор ключей и значений, которые предоставляют подробную информацию о клиенте, разместившем заказ. Классный трюк, а?! Это называется Ассоциативным Массивом. Но не пугайтесь технического языка, ведь ассоциативный массив — это просто вложенный объект.
XML
XML существует с 1996 года. С возрастом он стал очень зрелым и мощным форматом данных. Как и JSON, XML предоставляет несколько простых строительных блоков, которые создатели API используют для структурирования своих данных. Основной блок называется
узлом (node).
Давайте посмотрим, как может выглядеть наш заказ пиццы в XML:
original cheese pepperoni garlic cooking
XML всегда начинается с корневого узла, которым в нашем примере с пиццей является «заказ». Внутри заказа находятся ещё несколько «дочерних» узлов. Имя каждого узла сообщает нам атрибут заказа (как и ключ в JSON), а данные внутри представляют собой фактические детали (как и значение в JSON).
Рисунок 2. Узел и значение в XML
Вы также можете вывести предложения на английском языке, читая XML. Глядя на строчку с «корочкой», мы могли прочитать «корочка для пиццы оригинального стиля». Обратите внимание, как в XML каждый элемент в списке начинок обернут узлом. Как видите, формат XML требует гораздо больше текста для передачи, чем JSON.
Как форматы данных используются в HTTP
Теперь, когда мы изучили некоторые доступные форматы данных, нам нужно знать, как использовать их в HTTP. Для этого мы ещё раз поприветствуем одну из основ HTTP: заголовки. В главе 2 мы узнали, что заголовки — это список информации о запросе или ответе. Есть заголовок, указывающий, в каком формате находятся данные: Content-Type .
Когда клиент отправляет заголовок Content-Type в запросе, он сообщает серверу, что данные в теле запроса отформатированы
определённым способом. Если клиент хочет отправить серверу данные в формате JSON, он установит Content-Type на «application/json». Получив запрос и увидев этот Content-Type, сервер сначала проверит, понимает ли он этот формат, и, если да, он будет знать, как читать данные. Аналогичным образом, когда сервер отправляет клиенту ответ, он также устанавливает Content-Type, чтобы сообщить клиенту, как читать тело ответа.
Иногда клиент может общаться только в одном формате данных. Если сервер отправляет обратно что-либо, кроме этого формата, клиент откажется и выдаст ошибку. К счастью, на помощь приходит второй HTTP-заголовок. Клиент может установить заголовок Accept, чтобы сообщить серверу, какие форматы данных он может принимать. Если клиент может общаться только в формате JSON, он может установить для заголовка Accept значение «application/json». И тогда сервер будет отправлять ответы в формате JSON. Если сервер не поддерживает формат, запрашиваемый клиентом, он может отправить клиенту сообщение об ошибке, чтобы сообщить ему, что запрос не будет работать.
С помощью этих двух заголовков, Content-Type и Accept, клиент и сервер могут работать с форматами данных, которые они понимают и должны работать должным образом.
Рисунок 3. Заголовки форматов данных
Краткое содержание главы 3
В этой главе мы узнали, что для того, чтобы два компьютера могли общаться, они должны понимать передаваемый им формат данных. Мы познакомились с двумя распространенными форматами данных, используемыми в API: JSON и XML. Мы также узнали, что HTTP-заголовок Content-Type — это полезный способ указать, какой формат данных отправляется в запросе, а заголовок Accept определяет запрошенный формат для ответа.
- JSON: нотация объектов JavaScript
- Объект: вещь или существительное (человек, заказ пиццы . )
- Ключ: атрибут объекта (цвет, начинка . )
- Значение: значение атрибута (синий, пепперони . )
- Ассоциативный массив: вложенный объект
- XML: расширяемый язык разметки
MIME types
Медиа тип (так же известный как Multipurpose Internet Mail Extensions или MIME тип) является стандартом, который описывает природу и формат документа, файла или набора байтов. Он определён и стандартизирован в спецификации RFC 6838 .
Организация Internet Assigned Numbers Authority (IANA) является ответственной за все официально признанные MIME типы, и вы можете найти самый последний и полный лист MIME типов на их странице Медиа Типов.
Предупреждение: Важно: Для принятия решения о том, как обрабатывать URL, браузеры используют MIME типы, а не расширения файлов, так что серверам необходимо отправлять правильные MIME типы в Content-Type заголовке ответа. При неточном задавании этого заголовка, браузеры с большой вероятностью будут неправильно интерпретировать и обрабатывать содержание файлов, из-за чего сайт будет работать неверно.
Структура MIME типа
Простейший MIME тип состоит из типа и подтипа — двух строк разделённых наклонной чертой ( / ), без использования пробелов.
тип/подтип
Тип представляет общую категорию, в которой находится тип данных, например video или text . Подтип же строго отождествляется с отдельным типом данных, представляемых данным MIME типом. Например, для MIME типа text , подтипы могут быть plain (простой текст), html (HTML source code) или calendar (для iCalendar .ics ).
Необязательный параметр может быть добавлен для указания дополнительных деталей
тип/подтип;параметр=значение
Например, для MIME типов категории text , необязательный параметр charset может быть задан для уточнения кодировки, используемой в документе. Для объявления, что пересылаемый файл имеет кодировку UTF-8, необходимо использовать MIME тип text/plain;charset=UTF-8 . При не указании параметра charset , его значение автоматически будет задано, как ASCII ( US-ASCII ), если в настройках браузера не будет определено иначе.
MIME типы являются нечувствительными к регистру, но традиционно их пишут строчными буквами, за исключением значений параметров.
Типы
Все типы можно разделить на два класса: дискретные и многокомпонентные. Дискретные типы представляют одиночные файлы, например, одиночный текстовый, музыкальный или видео файл. Многокомпонентные типы представляют документы, составленные из нескольких частей, каждая из которых может иметь свой отдельный MIME тип, или они могут заключать в себе несколько отдельных файлов, передаваемых в одном сообщении. Например, многокомпонентные MIME типы используются для передачи нескольких изображений в одном email.
Дискретные типы
В настоящее время на IANA зарегистрированы следующие дискретные типы:
Любой вид бинарных данных, явно не попадающих ни в одну другую группу типов. Данные, которые будут выполняться или как-либо интерпретироваться, или данные для выполнения, которых необходимо отдельное приложение. Для указания базового типа бинарных данных (данных без определённого типа) используют тип application/octet-stream . Другие распространённые примеры включают application/pdf , application/pkcs8 и application/zip .
Аудио или музыкальные данные. Примеры: audio/mpeg , audio/vorbis .
Тип, зарезервированный для написания примеров, отображающих использование MIME типов. Этот тип никогда не должен использоваться вне примеров кода или документации. example может так же использоваться, как подтип.
Данные шрифтов. Распространённые примеры включают font/woff , font/ttf и font/otf .
Изображения или графические данные, включая векторную и растровую графику, а так же анимированные версии форматов неподвижных изображений, таких как GIF (en-US) или APNG. Распространённые примеры включают image/jpeg , image/png , и image/svg+xml .
Данные моделей для 3D объектов или сцен. Примеры: model/3mf и model/vml .
Любые текстовые данные, так или иначе доступные для чтения человеку, а так же исходный код или текстовые данные для программ. Примеры: text/plain , text/csv и text/html .
Видео данные или файлы. Например, MP4 фильмы ( video/mp4 ).
Любые текстовые документы без определённого подтипа стоит отправлять, как text/plain тип. Аналогичным образом, application/octet-stream тип подойдёт бинарным документам при неопределённом или неизвестном подтипе.
Многокомпонентные типы
Многокомпонентные типы описывают категории разграниченных на части документов, где каждая из частей может иметь свой отдельный MIME тип. При работе с электронными письмами, они могут использоваться для описания нескольких отдельных файлов, передаваемых в одном сообщении. Они представляют составные документы.
За исключением multipart/form-data типа, используемого в POST методе HTML форм, и multipart/byteranges типа, используемом в ответе 206 Partial Content для отправки части документа, HTTP никаким особым образом не обрабатывает многокомпонентные типы, и просто отправляет данные в браузер (который, с большой вероятностью, предложит сохранить переданный файл, тоже не зная как его обработать).
Существуют два многокомпонентных типа:
Сообщение, включающее в себя другие сообщения. Этот тип может использоваться, например, для представления сообщения, которое включают в себя другое переадресованное сообщение, как часть данных, или для отправки больших сообщений по частям, как если бы каждое сообщение отправлялось отдельно. Примеры включают message/rfc822 (для переадресованных или цитируемых сообщений) и message/partial для автоматического разделения одного большого сообщения на несколько небольших и их последующей сборки на стороне получателя.
Данные составленные из нескольких компонентов, каждый из которых может иметь отдельный MIME тип. Примеры включают multipart/form-data (для данных созданных с помощью FormData API) и multipart/byteranges (определённого в RFC 7233: 5.4.1 и используемого в ответах HTTP 206 «Partial Content», когда запрашиваемые данные возвращаются по частям в нескольких сообщениях, как например, при использовании заголовка Range ).
Важные для Web-разработчиков MIME типы
application/octet-stream
Этот тип является базовым для бинарных данных. В связи с тем, что он подразумевает неопределённые бинарные данные, браузеры, как правило, не будут пытаться его обработать каком-либо образом, а вызовут для него диалоговое окно «Сохранить Как», как если бы заголовок ответа Content-Disposition имел значение attachment .
text/plain
Этот тип является базовым для текстовых файлов. Несмотря на то, что он означает «неопределённые текстовые данные», браузеры всё равно могут его отображать.
Примечание: text/plain не означает «любой вид текстовых данных». Если браузер ожидает получения какого-то конкретного типа текстовых данных, то с большой вероятностью он не будет считать text/plain подходящим типом. Например, при загрузке text/plain документа через элемент, браузер не будет его признавать правильным CSS файлом и использовать для применения стилей. Только text/css тип должен использоваться для загрузки CSS документов.
text/css
CSS документы, используемые для стилизации web-страниц должны отправляться, как text/css тип. Большинство браузеров не смогут распознавать CSS документы, загруженные с отличным от text/css MIME типом.
text/html
Все HTML данные должны пересылаться с данным типом. Альтернативные MIME типы для XHTML (например, application/xhtml+xml ) почти не используются в настоящее время.
Примечание: Используйте application/xml или application/xhtml+xml , когда вам необходим строгий синтаксический анализ документов, разделы или элементы, не принадлежащие к пространствам имён HTML/SVG/MathML.
text/javascript
Согласно HTML спецификации: при пересылке JavaScript файлов, всегда должен использоваться MIME тип text/javascript .
По исторически сложившимся причинам, MIME Sniffing Standard (стандарт, определяющий, как браузеры должны интерпретировать медиа типы и выяснять, как обрабатывать данные при неправильно заданных медиа типах) позволяет серверам отправлять JavaScript документы, используя один из нижеперечисленных типов:
- application/javascript
- application/ecmascript
- application/x-ecmascript Non-standard
- application/x-javascript Non-standard
- text/javascript
- text/ecmascript
- text/javascript1.0 Non-standard
- text/javascript1.1 Non-standard
- text/javascript1.2 Non-standard
- text/javascript1.3 Non-standard
- text/javascript1.4 Non-standard
- text/javascript1.5 Non-standard
- text/jscript Non-standard
- text/livescript Non-standard
- text/x-ecmascript Non-standard
- text/x-javascript Non-standard
Примечание: Несмотря на то, что некоторые user agent могут поддерживать какие-то из вышеперечисленных типов, вы всегда должны использовать text/javascript . Это единственный MIME тип, который гарантированно будет работать в настоящее время и в будущем.
Иногда вы можете заметить использование text/javascript MIME типа в связке с параметром charset , для уточнения кодировки, в которой был написан файл. Такое определение MIME типа является неправильным, и в большинстве случаев браузеры не станут загружать скрипт, передаваемый с таким типом.
Типы изображений
Файлы, MIME типом которых является image , содержат в себе данные изображений. Подтип определяет, какой конкретный формат изображения представлен в данных.
Лишь несколько типов изображений (en-US) достаточно распространены, чтобы безопасно использоваться на веб-страницах.
Аудио и видео типы
Так же как в случае с изображениями, стандарт HTML не обязывает браузеры поддерживать какие-либо определённые форматы и кодеки для и элементов, так что при их выборе, важно брать в расчёт целевую аудиторию и диапазон браузеров (а так же версии этих браузеров), которые она может использовать.
Наше руководство по медиа форматам (en-US) предоставляет список общепринятых типов, включая информацию об особых случаях при их использовании, их недостатках, совместимости, а так же других деталях.
Руководства по аудио (en-US) и видео (en-US) кодекам перечисляют часто поддерживаемые браузерами кодеки, предоставляя детали по их совместимости и техническую информацию, например как много аудио каналов они поддерживают, какой тип сжатия используют, и так далее. Руководство по используемым в WebRTC кодекам развивает эту тему ещё дальше, конкретно описывая кодеки, поддерживаемые популярными браузерами, так чтобы вы могли выбрать кодеки, которые имеют наилучшую поддержку в диапазоне браузеров по вашему выбору.
Что касается MIME типов для аудио и видео файлов, то чаще всего они указывают на формат контейнера (тип файла). Необязательный параметр codecs может быть добавлен к MIME типу для более точного указания, какой кодек и параметры использовались для пересылаемого файла.
Ниже перечислены наиболее часто используемые на веб-страницах MIME типы. Обратите внимание, что это не полный перечень всех доступных типов. Более полный список поддерживаемых форматов может быть найден в руководстве по медиа форматам (en-US) .
| MIME тип | Аудио или видео тип |
|---|---|
| audio/wave audio/wav audio/x-wav audio/x-pn-wav | Аудио файл WAVE формата. С PCM аудио кодеком (WAVE кодек «1»), считающимся наиболее поддерживаемым, а так же другими, имеющими ограниченную поддержку. |
| audio/webm | Аудио файл формата WebM. С Vorbis и Opus официально поддерживаемыми WebM спецификацией аудио кодеками. |
| video/webm | Видео файл, с возможной аудио дорожкой, формата WebM. С VP8 и VP9, как наиболее распространёнными видео кодеками; Vorbis и Opus, как наиболее распространёнными аудио кодеками. |
| audio/ogg | Аудио файл формата OGG. С Vorbis, как наиболее распространённым аудио кодеком. Хотя на данный момент имеется поддержка и Opus кодека. |
| video/ogg | Видео файл, с возможной аудио дорожкой, в формате OGG. Где Theora – наиболее часто встречающийся видео кодек и Vorbis — наиболее часто встречающийся аудио кодек. Хотя использование кодека Opus становится всё более распространённым. |
| application/ogg | Аудио или видео формата OGG. Где Theora – наиболее часто встречающийся видео кодек и Vorbis — наиболее часто встречающийся аудио кодек. |
multipart/form-data
multipart/form-data тип может быть использован при отправке значений из заполненной HTML Формы на сервер.
Как многокомпонентный тип документа, он состоит из различных частей, разделённых специальной границей (строкой, начинающейся с двух чёрточек — ), где каждая часть представляет собой отдельную сущность и имеет отдельные HTTP заголовки Content-Disposition и Content-Type для загружаемых файлов.
Content-Type: multipart/form-data; boundary=aBoundaryString (other headers associated with the multipart document as a whole) --aBoundaryString Content-Disposition: form-data; name="myFile"; filename="img.jpg" Content-Type: image/jpeg (data) --aBoundaryString Content-Disposition: form-data; name="myField" (data) --aBoundaryString (more subparts) --aBoundaryString--
form action="http://localhost:8000/" method="post" enctype="multipart/form-data"> label>Name: input name="myTextField" value="Test" />label> label>input type="checkbox" name="myCheckBox" /> Checklabel> label >Upload file: input type="file" name="myFile" value="test.txt" />label> button>Send the filebutton> form>
POST / HTTP/1.1 Host: localhost:8000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive Upgrade-Insecure-Requests: 1 Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498 Content-Length: 465 -----------------------------8721656041911415653955004498 Content-Disposition: form-data; name="myTextField" Test -----------------------------8721656041911415653955004498 Content-Disposition: form-data; name="myCheckBox" on -----------------------------8721656041911415653955004498 Content-Disposition: form-data; name="myFile"; filename="test.txt" Content-Type: text/plain Simple file. -----------------------------8721656041911415653955004498--
multipart/byteranges
multipart/byteranges MIME тип используется для отправки данных в браузер по частям.
При отправке кода состояния 206 Partial Content , этот MIME тип будет означать, что документ состоит из нескольких частей, по одной для каждого отдельно запрашиваемого диапазона. Аналогично с остальными многокомпонентными типами, заголовок Content-Type используется для объявления границы boundary , разделяющей документ на отдельные компоненты. Каждый компонент имеет заголовок Content-Type , описывающий тип сегмента данных, и Content-Range (en-US) , описывающий его диапазон.
HTTP/1.1 206 Partial Content Accept-Ranges: bytes Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5 Content-Length: 385 --3d6b6a416f9b5 Content-Type: text/html Content-Range: bytes 100-200/1270 eta http-equiv="Content-type" content="text/html; charset=utf-8" />Важность задания правильного MIME типа
Большинство серверов отправляет ресурсы неопределённого типа, как application/octet-stream MIME тип. Большинство же браузеров, в целях безопасности, не позволяет их никак обрабатывать, вынуждая пользователя сохранять их на жёсткий диск, для дальнейшего использования.
Несколько советов по правильной настройке MIME типов на серверах:
- RAR-сжатые файлы. В этом случае самым правильным вариантом было бы задать тип изначального ресурса; но это не всегда выполнимо, так как .RAR файлы могут хранить в себе несколько типов данных. Тогда, настройте сервер на отправку application/x-rar-compressed MIME типа вместе с RAR ресурсами.
- Аудио и видео. Только ресурсы с правильно заданными MIME типами могут производиться в и элементах. Убедитесь, что вы используете правильные типы для аудио и видео данных (en-US).
- Запатентованные типы файлов. Избегайте использования application/octet-stream при их отправке, так как большинство браузеров не позволит определять способы обработки (например, "Открыть в Word") для этого базового MIME типа. Используйте специальные типы, например application/vnd.mspowerpoint , чтобы позволить пользователям открывать загруженный ресурс в программе по их выбору.
MIME sniffing
В отсутствии заданного MIME типа, или в определённых случаях, когда браузеры полагают, что MIME тип задан неправильно, они могут выполнять MIME sniffing — попытку угадать правильный MIME тип, анализируя характеристики ресурса.
Каждый браузер выполняет MIME sniffing по-своему и при разных условиях (например, Safari будет смотреть на расширение файла, если переданный MIME тип является неподходящим для документа). В этих случаях могут присутствовать опасения по поводу безопасности, так как некоторые MIME типы представляют исполняемые файлы. Сервера имеют возможность предотвращать MIME sniffing, отправляя X-Content-Type-Options заголовок ответа.
Другие методы сообщения о типе ресурса
MIME типы не являются единственным способом сообщения типа документа:
- Суффиксы в названиях файлов могут указывать на тип документа, главным образом на Microsoft Windows. Но не все операционные системы могут считать их имеющими смысл (например, Linux или MacOS). А так же нет никакой гарантии, что они будут указывать на правильный тип.
- Магические числа. Синтаксисы различных форматов позволяют узнавать их тип, через анализ их структуры байтов. Например, GIF файлы начинаются с 47 49 46 38 39 шестнадцатеричного значения ( GIF89 ), а PNG файлы с 89 50 4E 47 ( .PNG ). Опять же, не все типы документов имеют магические числа, так что этот подход так же не надёжен на 100%.
Смотрите также
- Медиа технологии в web (en-US)
- Руководство по медиа типам и форматам в web (en-US)
- Настраивание MIME типов на стороне сервера (en-US)
Found a content problem with this page?
- Edit the page on GitHub.
- Report the content issue.
- View the source on GitHub.
This page was last modified on 18 окт. 2023 г. by MDN contributors.
Your blueprint for a better internet.
Content type какие бывают
Поле заголовка '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- := x- := подтип := слово ; регистр безразличен параметр := атрибут "=" значение атрибут := слово ; регистр безразличен значение := слово / строка в кавычках слово := любые ASCII-символы кроме пробелов, Ctrl-последова- тельностей и специальных символов Специальные символы:= "(" / ")" / "" / "@" / "," / ";" / ":" / "\" / / "/" / "[" / "]" / "?" / "=" ; Эти символы используются в строке значений параметров
Здесь набор специальных символов отличается от набора, определенного в RFC 822 только наличием символов "/", "?", "=" и отсутствием символа ".".
Указание подтипа в данном поле является обязательным, т.к. нет подтипов по умолчанию. В отличие от имен типов, подтипов и параметров, значения параметров в общем случае являются чувствительными к регистру букв, но могут быть и нечувствительными - в зависимости от параметра. Например, значения границ multipart-письма являются чувствительными, а значение "access-type" для message/External-body не является.
Существует два приемлимых механизма для введения новых подтипов для поля Content-Type:
- Нестандартные значения (начинающиеся с "X-") могут быть опредлены по договоренности для двух или более общающихся друг с другом почтовых агентов (программ) без какой-либо внешней регистрации и стандартизации.
- Новые стандартные значения подтипов должны быть документированы, зарегистрированы и опробованы в IANA, как описано в приложении "E" RFC 1521. Если новй подтип предлагается для широкого использования, формат, описываемый им, должен быть описан в опубликованной спецификации и, возможно, предложен к стандартизации.
Семь предопределенных типов верхнего уровня, более детально, представляют собой следующее:
text -- текстовая информация. Основой подтип - "plain" - соответствует обычному неформатировнному тексту и не требует специального программного обеспечения для отображения этого текста за исключением поддержки национальных кодировок. Другие подтипы используются в случае размеченного текста, когда с помощью специальной программы можно улучшить его визуалзацию, но для понимания идеи содержания можно обойтись и без дполнительного ПО. Возможные подтипы могут описывать легкочитаемые форматы различных текстовых процессоров.
multipart -- содержимое письма состоит из некоторого множества частей, содержащих данные различных взаимонезависимых типов. Изначально определено четыре подтипа:
- "mixed" - основной;
- "alternative" - для представления одних и тех же данных в разных форматах;
- "parallel" - если разные части документа должны просматриваться одновременно;
- "digest" - если каждая из частей тела письма имеет тип "message".
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" .
What is a Content Type
Content types also known as MIME type or media types are a two part identifier for file formats. The HTTP header Content-Type is responsible for telling the HTTP client or server what type of data is being sent.
Headers
Two main headers are involved when it comes to content types
- Accept — When a HTTP client requests data from a server it can send a comma separated list of media types. For example the headers value could be text/html, text/plain. This hints to the server what the client is looking for. Basically the client is asking the server to respond with text/html and if it cannot handle that try responding with text/plain. Whether or not the server can handle or will honor this is up to the server.
- Content-Type — The content type header tells the client or server what format the data is being transferred in. If the client asked for text/html and the server handled it properly the data should come back with the Content-Type: text/html header. This header is how your browser knows when to render the html vs just displaying raw text. This is also used for images / files.
Notice the Accept: */*, This means accept any format. The Content-Type: text/html header tells the client the server responded with HTML.
Media Types
- text/plain — Simple Raw text
- text/html — Standard HTML, when a browser gets this media type it knows to render the page as HTML instead of raw text. This includes fetching external files such as javascript, css, and images.
- application/octet-stream — A binary file format often used to download files. If a browser gets this media type it automatically downloads the file instead of trying to display / render it.
- application/json — The JSON data format.
- application/pdf — PDF file.
- image/[png,jpeg,gif] — Standard image formats.