Content type какие бывают

Content-Type

Заголовок-сущность Content-Type используется для того, чтобы определить MIME тип ресурса.

В ответах сервера заголовок Content-Type сообщает клиенту, какой будет тип передаваемого контента. В некоторых случаях браузеры пытаются сами определить MIME тип передаваемого контента, но их реакция может быть неадекватной. Чтобы предотвратить такие ситуации, вы можете установить в заголовке X-Content-Type-Options значение nosniff .

В запросах (таких, как POST или PUT ), клиент сообщает серверу тип отправляемых данных.

Тип заголовка	Entity header
Forbidden header name	нет
CORS-safelisted response-header (en-US)	да

Синтаксис

Content-Type: text/html; charset=utf-8 Content-Type: multipart/form-data; boundary=something

Директивы

MIME тип ресурса или данных.

Директива boundary обязательна для составных сущностей. Она содержит от 1 до 70 символов (не должна заканчиваться пробелом), которые без искажений пройдут через шлюзы email и служит для корректной инкапсуляции всех частей составной сущности.

Примеры

Content-Type в HTML формах

В POST запросе, сгенерированном в результате отправки HTML формы, Content-Type запроса определяется в атрибуте enctype тега .

form action="/" method="post" enctype="multipart/form-data"> input type="text" name="description" value="some text" /> input type="file" name="myFile" /> button type="submit">Submitbutton> form> 

Запрос в этом случае может выглядеть так (менее интересные заголовки опущены):

POST /foo HTTP/1.1 Content-Length: 68137 Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575 -----------------------------974767299852498929531610575 Content-Disposition: form-data; name="description" some text -----------------------------974767299852498929531610575 Content-Disposition: form-data; name="myFile"; filename="foo.txt" Content-Type: text/plain (content of the uploaded file foo.txt) -----------------------------974767299852498929531610575--

Спецификации

Спецификация	Заголовок
RFC 7233, раздел 4.1: Content-Type in multipart	Hypertext Transfer Protocol (HTTP/1.1): Range Requests
RFC 7231, раздел 3.1.1.5: Content-Type	Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

Совместимость с браузерами

BCD tables only load in the browser

Смотрите также

• Accept and Accept-Charset
• Content-Disposition
• 206 Partial Content
• X-Content-Type-Options

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 7 авг. 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:

1. Нестандартные значения (начинающиеся с «X-«) могут быть опредлены по договоренности для двух или более общающихся друг с другом почтовых агентов (программ) без какой-либо внешней регистрации и стандартизации.
2. Новые стандартные значения подтипов должны быть документированы, зарегистрированы и опробованы в IANA, как описано в приложении «E» RFC 1521. Если новй подтип предлагается для широкого использования, формат, описываемый им, должен быть описан в опубликованной спецификации и, возможно, предложен к стандартизации.

Семь предопределенных типов верхнего уровня, более детально, представляют собой следующее:

text — текстовая информация. Основой подтип — «plain» — соответствует обычному неформатировнному тексту и не требует специального программного обеспечения для отображения этого текста за исключением поддержки национальных кодировок. Другие подтипы используются в случае размеченного текста, когда с помощью специальной программы можно улучшить его визуалзацию, но для понимания идеи содержания можно обойтись и без дполнительного ПО. Возможные подтипы могут описывать легкочитаемые форматы различных текстовых процессоров.

multipart — содержимое письма состоит из некоторого множества частей, содержащих данные различных взаимонезависимых типов. Изначально определено четыре подтипа:

1. «mixed» — основной;
2. «alternative» — для представления одних и тех же данных в разных форматах;
3. «parallel» — если разные части документа должны просматриваться одновременно;
4. «digest» — если каждая из частей тела письма имеет тип «message».

message — письмо в письме. Тело, содержащее данные типа «message», само является письмом или частью письма, полностью отформатированного в соответствии со стандартом RFC 822, которое, в свою очередь, может содержать свое собственное поле заголовка «Content-Type».
Подтипы:

1. «rfc822» — основной;
2. «partial» — определен для частично-цитируемых писем для предотвращения фрагментирования тел содержащихся писем в случае слишком большой их общей длины для возможностей почтового транспорта;
3. «External-body» — используется, чтобы указать, что тело письма очень большое и находится вне письма.

image — графические данные. Графика требует соответствующего устройства вывода (графический дисплей, принтер, факс) для отображения своей информации. Изначально определены два подтипа для наиболее распространенных графических форматов — jpeg и gif.

audio — звуковая информация. Требует звуковое устройство (динамик или наушники) для вывода информации. Основной подтип — «basic».

video — видео. Требует специальных аппаратных и программных возможностей для отображения видео-информации. Единстванный изначально определенный подтип — «mpeg».

application — как правило, неинтерпретируемый двоичный код либо информация, предназначенная для обработки почтовой программой.

1. «octet-stream» — основной подтип; предназначен для неинтерпретируемых двоичных данных, для которых рекомендуемым действием является предложение пользователю сохранить в файл на диске.
2. «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» .

Content Type Класс

Некоторые сведения относятся к предварительной версии продукта, в которую до выпуска могут быть внесены существенные изменения. Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, относительно приведенных здесь сведений.

Представляет заголовок типа содержимого протокола MIME.

public ref class ContentType

public class ContentType

type ContentType = class

Public Class ContentType

Наследование
ContentType

Примеры

В следующем примере кода отправляется сообщение электронной почты с вложением ContentDisposition и отображаются свойства вложения.

static void CreateMessageWithAttachment( String^ server ) < // Specify the file to be attached and sent. // This example assumes that a file named Data.xls exists in the // current working directory. String^ file = L"data.xls"; // Create a message and set up the recipients. MailMessage^ message = gcnew MailMessage( L"jane@contoso.com",L"ben@contoso.com",L"Quarterly data report.",L"See the attached spreadsheet." ); // Create the file attachment for this email message. Attachment^ data = gcnew Attachment(file, MediaTypeNames::Application::Octet); // Add time stamp information for the file. ContentDisposition^ disposition = data->ContentDisposition; disposition->CreationDate = System::IO::File::GetCreationTime( file ); disposition->ModificationDate = System::IO::File::GetLastWriteTime( file ); disposition->ReadDate = System::IO::File::GetLastAccessTime( file ); // Add the file attachment to this email message. message->Attachments->Add( data ); //Send the message. SmtpClient^ client = gcnew SmtpClient( server ); // Add credentials if the SMTP server requires them. client->Credentials = CredentialCache::DefaultNetworkCredentials; client->Send( message ); // Display the values in the ContentDisposition for the attachment. ContentDisposition^ cd = data->ContentDisposition; Console::WriteLine( L"Content disposition" ); Console::WriteLine( cd ); Console::WriteLine( L"File ", cd->FileName ); Console::WriteLine( L"Size ", cd->Size ); Console::WriteLine( L"Creation ", cd->CreationDate ); Console::WriteLine( L"Modification ", cd->ModificationDate ); Console::WriteLine( L"Read ", cd->ReadDate ); Console::WriteLine( L"Inline ", cd->Inline ); Console::WriteLine( L"Parameters: ", cd->Parameters->Count ); IEnumerator^ myEnum1 = cd->Parameters->GetEnumerator(); while ( myEnum1->MoveNext() ) < DictionaryEntry^ d = safe_cast(myEnum1->Current); Console::WriteLine( L" = ", d->Key, d->Value ); > data->~Attachment(); client->~SmtpClient(); > 

public static void CreateMessageWithAttachment(string server) < // Specify the file to be attached and sent. // This example assumes that a file named Data.xls exists in the // current working directory. string file = "data.xls"; // Create a message and set up the recipients. MailMessage message = new MailMessage( "jane@contoso.com", "ben@contoso.com", "Quarterly data report.", "See the attached spreadsheet."); // Create the file attachment for this email message. Attachment data = new Attachment(file, MediaTypeNames.Application.Octet); // Add time stamp information for the file. ContentDisposition disposition = data.ContentDisposition; disposition.CreationDate = System.IO.File.GetCreationTime(file); disposition.ModificationDate = System.IO.File.GetLastWriteTime(file); disposition.ReadDate = System.IO.File.GetLastAccessTime(file); // Add the file attachment to this email message. message.Attachments.Add(data); //Send the message. SmtpClient client = new SmtpClient(server); // Add credentials if the SMTP server requires them. client.Credentials = CredentialCache.DefaultNetworkCredentials; try < client.Send(message); >catch (Exception ex) < Console.WriteLine("Exception caught in CreateMessageWithAttachment(): ", ex.ToString()); > // Display the values in the ContentDisposition for the attachment. ContentDisposition cd = data.ContentDisposition; Console.WriteLine("Content disposition"); Console.WriteLine(cd.ToString()); Console.WriteLine("File ", cd.FileName); Console.WriteLine("Size ", cd.Size); Console.WriteLine("Creation ", cd.CreationDate); Console.WriteLine("Modification ", cd.ModificationDate); Console.WriteLine("Read ", cd.ReadDate); Console.WriteLine("Inline ", cd.Inline); Console.WriteLine("Parameters: ", cd.Parameters.Count); foreach (DictionaryEntry d in cd.Parameters) < Console.WriteLine("= ", d.Key, d.Value); > data.Dispose(); > 

Комментарии

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

Синтаксис заголовка Content-Type описан в rfc 2045, раздел 5.1. RFC 2046 содержит подробные сведения о типах носителей MIME и их параметрах. Эти RFC доступны по адресу https://www.ietf.org.

Конструкторы

Инициализирует новый экземпляр по умолчанию класса ContentType.

Инициализирует новый экземпляр класса ContentType, используя указанную строку.

Свойства

Возвращает или задает значение параметра границы, который содержится в заголовке Content-Type, представляемом данным экземпляром.

Возвращает или задает значение параметра кодировки, который содержится в заголовке Content-Type, представляемом данным экземпляром.

Возвращает или задает значение типа мультимедиа, которое содержится в заголовке Content-Type, представляемом данным экземпляром.

Возвращает или задает параметр имени, который содержится в заголовке Content-Type, представляемом данным экземпляром.

Возвращает словарь, который содержит параметры заголовка Content-Type, представляемого данным экземпляром.

Методы

Определяет, равен ли заголовок Content-Type указанного объекта ContentType заголовку Content-Type данного объекта.

Определяет хэш-код указанного объекта ContentType.

Возвращает объект Type для текущего экземпляра.

Создает неполную копию текущего объекта Object.

Возвращает строковое представление этого объекта ContentType.

Content type какие бывают

+7 499 350 77 10
+7 499 322 88 70

• Переподготовка
• Системный анализ
• Архитектура
• Интеграция
• Базы данных
• Бизнес-анализ
• Продуктовый дизайн

Глава 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: расширяемый язык разметки