MIME-типы в HTML


У ниверсальные атрибуты, события и MIME-типы файлов

Универсальные атрибуты

accesskey — активирует ссылку сочетанием клавиш. Например, для . в IE, Chrome и Safari это будет Alt + W .
Значения: латиница и цифры.
Используется для тегов: a, area, button, input, label, legend, textarea (не допустимы в HTML5)
для новых тегов html5: article, aside, command, datalist, details, embed, figcaption, figure, footer, header, hgroup, keygen, mark, meter, nav, output, progress, rp, rt, ruby, section, source, summary, time.

class — стилевой класс, служит для привязки его к определенным тегам. Имя стилевого класса позволяет однозначно идентифицировать такие теги. К тегу можно применять более одного класса, указав их через пробел, тогда заданные стили оформления складываются.
Значения: латиница, цифры, дефисы и нижние подчеркивания, причем, первый символ — только буква или цифра.
Используется практически для любых тегов.

contenteditable — разрешает или запрещает режим редактирования элемента пользователем.
Значения: false — нет, true — разрешено.
Используется для большинства тегов и новых тегов html5 (см. атрибут accesskey).

contextmenu — добавляет к элементу контекстное меню.
Значения: одинаковое с атрибутом id тега menu.
Используется для большинства тегов и новых тегов html5 (см. атрибут accesskey).

dir — правильное направление отображения контента на иностранных языках.
Значения: ltr — слева направо (по умолчан.), true — справа налево.
Используется практически для любых тегов.

draggable — перетаскивание отдельных элементов веб-страницы пользователем, например, выбранных товаров в тележку покупок в интернет-магазине и др. Требует дополнительных скриптов.
Значения: false — нет, true — разрешено.
Используется для новых тегов html5 (см. атрибут accesskey).

hidden — делает элемент на странице визуально отсутствующим, но доступным для скриптов.
Значения: -.
Используется практически для любых тегов.

id — именованный стиль, связывает тег с заданными стилями оформления. Похож на атрибут class, но в отличии от него, он должен быть уникальным в пределах веб-страницы, т.е. единственным. В противном случае, нужно использовать стилевые классы.
Значения: латиница, цифры, дефисы и нижние подчеркивания, причем, первый символ — только буква или цифра.
Используется практически для любых тегов.

lang — предоставление информации об элементах контента на иностранном языке, может использоваться речевыми браузерами, в XHTML используется атрибут xml:lang.
Значения: код языка, например: ru или en.
Используется практически для любых тегов.

spellchek — проверка правописания браузером.
Значения: no — нет, yes — разрешено.
Используется практически для любых тегов.

style — задает стилевое оформление элемента, используя свойства CSS. Использовать атрибут style нужно крайне аккуратно, а лучше пользоваться «нормальным» CSS.
Пример:

.
Используется практически для любых тегов.

tabindex — последовательность переходов по ссылкам от меньшего значения к большему, если пользователь применяет клавишу Tab .
Значения: любое целое число.

title — отображает заголовок ссылки или краткое описание элемента, при наведении на него курсора — появляется всплывающая подсказка с нужным текстом.
Значения: текст.
Используется практически для любых тегов.

События

onabort — наступает при прерывании загрузки элемента.
onafterprint — наступает после печати документа (новый).
onbeforeonload — наступает после загрузки документа (новый).
onbeforeprint — наступает перед печатью документа (новый).
onblur — наступает при потере элементом фокуса ввода: активного состояния.
oncanplay — наступает при загрузки, необходимой для воспроизведения элемента (новый).
oncanplaythrough — наступает при загрузки, необходимой для воспроизведения элемента целиком, без прерывания (новый).
onchange — наступает при изменении значения в поле ввода или области редактирования.
onclick — наступает при клике на элементе левой кнопки мыши.
oncontextmenu — наступает при вызове контекстного меню (новый).
ondblclick — наступает при двойном клике на элементе.
ondrag — наступает при перетаскивании элемента (новый).
ondragend — наступает после прекращения перетаскивания элемента (новый).
ondragenter — наступает, если перетаскиваемый элемент располагается на определенном местоназначении (новый).
ondragleave — наступает, если перетаскиваемый элемент покидает определенное местоназначение (новый).
ondragstart — наступает при начале перетаскивания элемента (новый).
ondrop — наступает, если перетаскиваемый элемент помещен в определенное местоназначение (новый).
ondurationchange — наступает при изменении размера элемента воспроизведения (новый).
onemptied — наступает при недоступности элемента воспроизведения (новый).
onended — наступает после окончания воспроизведения элемента полностью (новый).
onerror — наступает при ошибке загрузки элемента.
onfocus — наступает при получении элементом фокуса ввода.
onformchange — наступает при изменении содержимого в поле ввода или области редактирования (новый).
onforminput — наступает при вводе содержимого в поле ввода или области редактирования (новый).
onhaschange — наступает при изменении содержимого документа (новый).
oninput — наступает при вводе содержимого в элемент (новый).
onkeydown — наступает при нажатии произвольной клавиши.
onkeypress — наступает при нажатии буквенной или цифровой клавиши между событиями onkeydown и onkeyup.
onkeyup — наступает при отпускании ранее нажатой клавиши.
onload — наступает после загрузки элемента или документа.
onloadeddata — наступает при загрузке данных (новый).
onloadedmetadata — наступает при загрузке метаданных элемента воспроизведения (новый).
onloadstart — наступает при начале загрузки элемента (новый).
onmessage — наступает при получении сообщения документом (новый).
onmousedown — наступает при нажатии левой кнопки мыши.
onmousemove — наступает при движении курсора над элементом.
onmouseout — наступает после передвижения курсора за пределы элемента.
onmouseover — наступает при удержании курсора на элементе.
onmouseup — наступает после отпускания ранее нажатой левой кнопки мыши.
onmousewheel — наступает при использовании колеса прокрутки мыши (новый).
onoffline — наступает при отключении документа от Сети (новый).
ononline — наступает при подключении документа к Сети (новый).
onpagehide — наступает при скрытии окна браузера (новый).
onpageshow — наступает при отображении окна браузера (новый).
onpause — наступает при паузе в воспроизведении элемента (новый).
onplay — наступает при готовности элемента к воспроизведению (новый).
onplaying — наступает при начале воспроизведения элемента (новый).
onpopstate — наступает при изменении истории браузера (новый).
onprogress — наступает при определении метаданных элемента воспроизведения (новый).
onratechange — наступает при изменении скорости воспроизведения элемента (новый).
onreadystatechange — наступает при изменении состояния элемента воспроизведения (новый).
onredo — наступает при переходе на следующую страницу в истории браузера (новый).
onreset — наступает при сбросе данных в поле ввода.
onresize — наступает при изменении размеров окна браузера.
onscroll — наступает при использовании полос прокрутки элемента (новый).
onselect — наступает при выделении содержимого в поле ввода или области редактирования.
onsubmit — наступает при отправке данных формы.
ontimeupdate — наступает при перемотке элемента воспроизведения (новый).
onundo — наступает при переходе на предыдущую страницу в истории браузера (новый).
onunload — наступает при закрытии окна браузера (новый).
onvolumechange — наступает при изменении уровня громкости элемента воспроизведения (новый).
onwaiting — наступает при остановке воспроизведения элемента (новый).

MIME-типы

В таблице приводятся MIME-типы наиболее употребимых типов файлов:

Список MIME-типов

MIME (Multipurpose Internet Mail Extension, Многоцелевые расширения почты Интернета) — спецификация для передачи по сети файлов различного типа, таких как музыкальные и видео записи, архивы данных и изображения вместе с аннотациями и др.
Касательно языка программирования HTML, данная спецификация используется для управления отправкой форм и других информационных объектов, с возможностью их размещения на веб странице.

Синтаксис

Структура MIME-типа очень проста, она состоит из типа и подтипа, две строки, разделенные слешем (/). Пробелы не допускаются. Тип представляет собой категорию и может быть дискретным или многоцелевым типом. Подтип является специфическим для каждого типа.

MIME-тип нечувствителен к регистру, но традиционно пишется в нижнем регистре.

MIME-типы в HTML

Указание media-типа используется для передачи сведений о формате тела сообщения в HTTP протоколе. Клиенты (просмотрщики) используют media-типы в своих заголовках Accept для того, чтобы сообщить, в каких форматах они предпочитают принимать данные. Серверы используют media-типы в заголовках Content-Type, чтобы сообщить клиенту о том, в каком формате передается прилагаемое содержимое: то ли это HTML, который нужно форматировать, то ли это GIF или JPEG, требующий визуализации, то ли это данные в формате PDP, для которого нужно открывать внешнюю программу просмотра или использовать дополнительное приложение.

Media-типы Internet, используемые в HTTP, очень напоминают типы MIME. MIME (Multipurpose Internet Mail Extension — многоцелевые расширения электронной почты для Internet) разработаны как метод передачи присоединенных данных по Internet средствами электронной почты. Как и MIME, media-тип указывается в формате тип/подтип. Символ * используется как метасимвол; например, следующий заголовок клиента означает, что принимаются документы во всех форматах: Следующий заголовок клиента означает, что принимаются все типы формата text независимо от подтипа:

Серверы и CGI-программы должны проверять данные о принимаемых типах, содержащиеся в заголовке Accept, и по возможности выдавать данные соответствующего типа. Большинство серверов определяют формат документа по суффиксу имени файла. Например, файлы с расширениями .htm и .html — это файлы в формате HTML, поэтому сервер посылает такой документ с типом text/html в заголовке Content-Type. При вызове CGI-программы серверу неизвестен формат возвращаемых данных, поэтому программа должна сообщить тип содержимого. По этой причине каждая CGI-программа должна включать в результат своей работы заголовок Content-Type, например: В следующей таблице перечислены общепринятые media-типы, а также суффиксы имен файлов, распознаваемые большинством серверов. Большинство серверов можно легко настроить так, чтобы они распознавали и другие суффиксы.

Стандартные типы

Тип передачи данных клиенту от сервера выбирается по префиксу файла при настройке WWW сервера. По умолчанию, если префикс файла не задан или отсутствует принудительное указание типа файла, то задается

WWW сервер при передаче файлов клиенту по умолчанию использует следующие основные MIME типы передачи файлов (Content-Type), определяемые префиксом файла, которые обрабатывает просмотрщик (см. полный список установок MIME-types по умолчанию).

Замечание: Отметим, что согласно протоколу HTTP значение Content-Type, которое выдал сервер является приоритетным по сравнению со значением, установленным на машине клиента (хотя MSIE это замечание игнорирует).

Дополнительные типы

Дополнительные типы задаются исходя из возможностей сервера.

Поддержка технологии SSI
Технология SSI Server Side Includes Позволяет создавать документы методом сборки из отдельных файлов и исполняемых программ перед отправкой их клиенту. Этот дополнительный тип передачи данных устанавливается атрибутом Тип файла по умолчанию .shtml (.sht для MS Windows)
или Тип файла по умолчанию .shtml3
для отработки команд Server Side Includes, которые определены в стандарте языка HTML 3.0.

Передача запросов и ответов к активным программам
Если активная программа (CGI Script) расположена не в директории CGI_BIN , то запрос к ней сопровождается атрибутом Тип файла по умолчанию .cgi
задается командой

Передача запросов и ответов к активным картинкам
Обработка запросов к активным картинкам может производится как клиентом (Client S > Федотов А.М. Введение в Internet
Документация по Интернет технологиям

Начало создания курса: Mondy, 19-Aug-1996 10:12:15 NOVST
Дата последней модификации: Monday, 08-May-2000 19:45:28 NOVST
© 1996 — 2003, А.М.Федотов
© 1996 — 2003, Институт вычислительных технологий СО РАН, Новосибирск

Media типы и подтипы (MIME-Types)

Указание media-типа используется для передачи сведений о формате содержимого в HTTP-транзакциях. Клиенты используют media-типы в своих заголовках Accept для того, чтобы сообщить, в каких форматах они предпочитают принимать данные. Серверы используют media-типы в заголовках Content-Type, чтобы сообщить клиенту о том, в каком формате передается прилагаемое содержимое: то ли это HTML, который нужно форматировать, то ли это GIF или JPEG, требующий визуализации, то ли это данные в формате PDP, для которого нужно открывать внешнюю программу просмотра или использовать дополнительное приложение.

Media-типы Internet, используемые в HTTP, очень напоминают типы MIME. MIME (Multipurpose Internet Mail Extension — многоцелевые расширения электронной почты для Internet) разработаны как метод передачи присоединенных данных по Internet средствами электронной почты. Как и MIME, media-тип указывается в формате тип/подтип. Символ * используется как метасимвол; например, следующий заголовок клиента означает, что принимаются документы во всех форматах:

Следующий заголовок клиента означает, что принимаются все типы формата text независимо от подтипа:

Серверы и CGI-программы должны проверять данные о принимаемых типах, содержащиеся в заголовке Accept, и по возможности выдавать данные соответствующего типа. Большинство серверов определяют формат документа по суффиксу имени файла. Например, файлы с расширениями .htm и .html — это файлы в формате HTML, поэтому сервер посылает такой документ с типом text/html в заголовке Content-Type. При вызове CGI-программы серверу неизвестен формат возвращаемых данных, поэтому программа должна сообщить тип содержимого. По этой причине каждая CGI-программа должна включать в результат своей работы заголовок Content-Type, например:

Илон Маск рекомендует:  Что такое код asp aspthreadgateloadhigh

MIME-типы в HTML

Согласно RFC 2045, RFC 2046, RFC 4288, RFC 4289 и RFC 4855 . [2] выделяются следующие базовые типы передачи данных

Проверить информацию.

  • application
  • audio
  • example
  • image
  • message
  • model
  • multipart
  • text
  • v > application
  • application/atom+xml : Atom
  • application/EDI-X12 : EDI X12 (RFC 1767)
  • application/EDIFACT : EDI EDIFACT (RFC 1767)
  • application/json : JavaScript Object Notation JSON (RFC 4627)
  • application/javascript : JavaScript (RFC 4329)
  • application/octet-stream : (RFC 2046) [3]
  • application/ogg : Ogg (RFC 5334)
  • application/pdf : Portable Document Format, PDF (RFC 3778)
  • application/postscript : PostScript (RFC 2046)
  • application/soap+xml : SOAP (RFC 3902)
  • application/x-woff : Web Open Font Format
  • application/xhtml+xml : XHTML (RFC 3236)
  • application/xml-dtd : DTD (RFC 3023)
  • application/xop+xml :XOP
  • application/zip : ZIP[4]
  • application/x-gzip : Gzip
  • application/x-bittorrent : Torrent

audio

  • audio/basic : mulaw аудио, 8 кГц, 1 канал (RFC 2046)
  • audio/L24 : 24bit Linear PCM аудио, 8-48 кГц, 1-N каналов (RFC 3190)
  • audio/mp4 : MP4
  • audio/mpeg : MP3 или др. MPEG (RFC 3003)
  • audio/ogg : OggVorbis, Speex, Flac или др. аудио (RFC 5334)
  • audio/vorbis : Vorbis (RFC 5215)
  • audio/x-ms-wma : Windows Media Audio[5]
  • audio/x-ms-wax : Windows Media Audio перенаправление
  • audio/vnd.rn-realaudio : RealAudio[6]
  • audio/vnd.wave : WAV(RFC 2361)
  • audio/webm : WebM

image

message

  • message/http (RFC 2616)
  • message/imdn+xml : IMDN (RFC 5438)
  • message/partial : E-mail (RFC 2045 и RFC 2046)
  • message/rfc822 : E-mail; EML файлы, MIME файлы, MHT файлы, MHTML файлы (RFC 2045 и RFC 2046)

model

  • model/example : (RFC 4735)
  • model/iges : IGS файлы, IGES файлы (RFC 2077)
  • model/mesh : MSH файлы, MESH файлы (RFC 2077), SILO файлы
  • model/vrml : WRL файлы, VRML файлы (RFC 2077)
  • model/x3d+binary : X3DISO стандарт для 3D компьютерной графики, X3DB файлы
  • model/x3d+vrml : X3DISO стандарт для 3D компьютерной графики, X3DV VRML файлы
  • model/x3d+xml : X3DISO стандарт для 3D компютерной графики, X3D XML файлы

multipart

  • multipart/mixed : MIMEE-mail (RFC 2045 и RFC 2046)
  • multipart/alternative : MIMEE-mail (RFC 2045 и RFC 2046)
  • multipart/related : MIMEE-mail (RFC 2387 и используемое MHTML (HTML mail))
  • multipart/form-data : MIME Webform (RFC 2388)
  • multipart/signed : (RFC 1847)
  • multipart/encrypted : (RFC 1847)

video

  • application/vnd.oasis.opendocument.text : OpenDocument[12]
  • application/vnd.oasis.opendocument.spreadsheet : OpenDocument[13]
  • application/vnd.oasis.opendocument.presentation : OpenDocument[14]
  • application/vnd.oasis.opendocument.graphics : OpenDocument[15]
  • application/vnd.ms-excel : Microsoft Excel файлы
  • application/vnd.openxmlformats-officedocument.spreadsheetml.sheet : Microsoft Excel 2007 файлы
  • application/vnd.ms-powerpoint : Microsoft Powerpoint файлы
  • application/vnd.openxmlformats-officedocument.presentationml.presentation : Microsoft Powerpoint 2007 файлы
  • application/msword : Microsoft Word файлы
  • application/vnd.openxmlformats-officedocument.wordprocessingml.document : Microsoft Word 2007 файлы
  • application/vnd.mozilla.xul+xml : MozillaXUL файлы
  • application/vnd.google-earth.kml+xml : KML файлы (например, для Google Earth)
  • application/x-www-form-urlencoded Form Encoded Data [16]
  • application/x-dvi : DVI
  • application/x-latex : LaTeX файлы
  • application/x-font-ttf : TrueType (не зарегистрирован MIME-тип, но наиболее часто используемый)
  • application/x-shockwave-flash : Adobe Flash[17] и [18]
  • application/x-stuffit : StuffIt
  • application/x-rar-compressed : RAR
  • application/x-tar : Tarball
  • text/x-jquery-tmpl : jQuery
  • application/x-javascript :

x-pkcs

  • application/x-pkcs12 : p12 файлы
  • application/x-pkcs12 : pfx файлы
  • application/x-pkcs7-certificates : p7b файлы
  • application/x-pkcs7-certificates : spc файлы
  • application/x-pkcs7-certreqresp : p7r файлы
  • application/x-pkcs7-mime : p7c файлы
  • application/x-pkcs7-mime : p7m файлы
  • application/x-pkcs7-signature : p7s файлы

Правая Скобка ]

Энциклопедия веб разработчика. Все что интересно HTML, CSS, PHP, MySQL и не только !

HTML типы носителей MIME

Типы носителей MIME (Multipurpose Internet Mail Extension) были первоначально разработаны для того, чтобы электронные письма могли включать информацию отличную от обычного текста. Типы носителей MIME указывают на следующее:

  • Как различные части сообщения, такие как текст и вложения, объединяются в сообщение.
  • Способ, в котором указывается каждая часть сообщения.
  • То, как различные элементы кодируются для передачи, так что даже программное обеспечение, которое было разработано для работы только с текстом ASCII, может обрабатывать сообщение.

Теперь типы MIME предназначены не только для электронной почты; они были приняты веб-серверами как способ сообщить веб-браузерам, какой тип материалов им отправляется, чтобы они могли правильно справляться с такого рода сообщениями.
Типы содержимого MIME состоят из двух частей:

Основной Тип отделяется от Подтипа символом косой черты. Например, text / html для HTML.
Основные типы −

Например, основной текстовый тип содержит типы текстовых файлов, таких как —

  • text/plain для текстовых файлов
  • text/html для файлов HTML
  • text/rtf для текстовых файлов с использованием расширенного текстового форматирования

Официально предполагается, что типы MIME назначаются и перечисляются Органом по присвоению номеров в Интернете (IANA).
Многие из популярных типов MIME в этом списке (все начинаются с «x-«) не назначены IANA и не имеют официального статуса. Вы можете увидеть список официальных типов MIME на http://www.iana.org/assignments/media-types/. Те кому предшествует .vnd, зависят от производителя.
При указании типа MIME поля типа content можно также указать набор символов для используемого текста. Если Вы не указываете набор символов, по умолчанию используется US-ASCII.

Составные типы носителей MIME
Ниже приведены подтипы для составных −

alternative appledouble byteranges
digest encrypted form-data
header-set mixed parallel
related report signed
voice-messagerelated &nsbp; &nsbp;

Типы видео-носителей MIME
Подтипы для видео —

BMPEG MP4V-ES vnd.mpegurl
BT656 MPV vnd.nokia.interleaved-multimedia
CelB mpeg vnd.objectvideo
DV mpeg4-generic vnd.sealed.mpeg1
H261 nv vnd.sealed.mpeg4
H263 parityfec vnd.sealed.swf
H263-1998 pointer vnd.sealedmedia.softseal.mov
H263-2000 quicktime vnd.vivo
JPEG SMPTE292M x-sgi-movie
MP1S vnd.fvt x-msvideo
MP2P vnd.motorola.video
MP2T vnd.motorola.videop


Типы носителей MIME-изображений

bmp cgm g3fax
gif ief jpeg
naplps png prs.btif
prs.pti t38 vnd.fujixerox.edmics-rlc
tiff-fx vnd.cns.inf2 vnd.djvu
vnd.dwg vnd.dxf vnd.fastbidsheet
vnd.fpx vnd.fst vnd.fujixerox.edmics-mmr
vnd.xiff tiff vnd.microsoft.icon
vnd.mix vnd.ms-modi vnd.sealedmedia.softseal.gif
vnd.net-fpx vnd.sealed.png vnd.sealedmedia.softseal.jpg
vnd.svf vnd.wap.wbmp vnd.globalgraphics.pgb

Типы носителей MIME-модели

iges vnd.gdl vnd.parasolid.transmit.binary
mesh vnd.gs-gdl vnd.parasolid.transmit.text
vnd.dwf vnd.gtw vnd.vtu
vnd.flatland.3dml vnd.mts vrml

Типы носителей приложений MIME

activemessage andrew-inset
applefile atomicmail
batch-SMTP beep+xml
cals-1840 cnrp+xml
commonground cpl+xml
cybercash dca-rft
dec-dx dicom
dvcs EDI-Consent
EDIFACT eshop
font-tdpfr http
hyperstudio iges
index index.cmd
index.obj index.response
index.vnd iotp
ipp isup
mac-binhex40 macwriteii
marc mathematica
mpeg4-generic msword
news-message-id news-transmission
ocsp-request ocsp-response
octet-stream oda
ogg parityfec
pdf pgp-encrypted
pgp-keys pgp-signature
pidf+xml pkcs10
pkcs7-mime pkcs7-signature
pkix-cert pkixcmp
pkix-crl pkix-pkipath
postscript prs.alvestrand.titrax-sheet
prs.cww prs.nprend
prs.plucker qsig
reginfo+xml remote-printing
riscos rtf
sdp set-payment
set-payment-initiation set-registration
set-registration-initiation sgml
sgml-open-catalog sieve
slate timestamp-query
timestamp-reply tve-trigger
vemmi vnd.3gpp.pic-bw-large
vnd.3gpp.pic-bw-small vnd.3gpp.pic-bw-var
vnd.3gpp.sms vnd.3M.Post-it-Notes
vnd.accpac.simply.aso vnd.accpac.simply.imp
vnd.acucobol vnd.acucorp
vnd.adobe.xfdf vnd.aether.imp
vnd.amiga.ami vnd.anser-web-certificate-issue-initiation
vnd.audiograph vnd.anser-web-funds-transfer-initiation
vnd.blueice.multipass vnd.bmi
vnd.businessobjects vnd.canon-cpdl
vnd.canon-lips vnd.cinderella
vnd.claymore vnd.commerce-battelle
vnd.commonspace vnd.cosmocaller
vnd.contact.cmsg vnd.criticaltools.wbs+xml
vnd.ctc-posml vnd.cups-postscript
vnd.cups-raster vnd.cups-raw
vnd.curl vnd.cybank
vnd.data-vision.rdz vnd.dna
vnd.dpgraph vnd.dreamfactory
vnd.dxr vnd.ecdis-update
vnd.ecowin.chart vnd.ecowin.filerequest
vnd.ecowin.fileupdate vnd.ecowin.series
vnd.ecowin.seriesrequest vnd.ecowin.seriesupdate
vnd.enliven vnd.epson.esf
vnd.epson.msf vnd.epson.quickanime
vnd.epson.salt vnd.epson.ssf
vnd.ericsson.quickcall vnd.eudora.data
vnd.fdf vnd.ffsns
vnd.fints vnd.FloGraphIt
vnd.framemaker vnd.fsc.weblaunch
vnd.fujitsu.oasys vnd.fujitsu.oasys2
vnd.fujitsu.oasys3 vnd.fujitsu.oasysgp
vnd.fujitsu.oasysprs vnd.fujixerox.ddd
vnd.fujixerox.docuworks vnd.fujixerox.docuworks.binder
vnd.fut-misnet vnd.genomatix.tuxedo
vnd.grafeq vnd.groove-account
vnd.groove-help vnd.groove-identity-message
vnd.groove-injector vnd.groove-tool-message
vnd.groove-tool-template vnd.groove-vcard
vnd.hbci vnd.hhe.lesson-player
vnd.hp-HPGL vnd.hp-hpid
vnd.hp-hps vnd.hp-PCL
vnd.hp-PCLXL vnd.httphone
vnd.hzn-3d-crossword vnd.ibm.afplinedata
vnd.ibm.electronic-media vnd.ibm.MiniPay
vnd.ibm.modcap vnd.ibm.rights-management
vnd.ibm.secure-container vnd.informix-visionary
vnd.intercon.formnet vnd.intertrust.digibox
vnd.intertrust.nncp vnd.japannet-registration-wakeup
vnd.intu.qfx vnd.ipunplugged.rcprofile
vnd.irepository.package+xml vnd.is-xpr
vnd.japannet-directory-service vnd.japannet-jpnstore-wakeup
vnd.japannet-payment-wakeup vnd.japannet-registration
vnd.intu.qbo vnd.japannet-setstore-wakeup
vnd.japannet-verification vnd.japannet-verification-wakeup
vnd.jisp vnd.kde.karbon
vnd.kde.kchart vnd.kde.kformula
vnd.kde.kivio vnd.kde.kontour
vnd.kde.kpresenter vnd.kde.kspread
vnd.kde.kword vnd.kenameaapp
vnd.kidspiration vnd.koan
vnd.liberty-request+xml vnd.llamagraphics.life-balance.desktop
vnd.lotus-1-2-3 vnd.llamagraphics.life-balance.exchange+xml
vnd.lotus-approach vnd.lotus-freelance
vnd.lotus-notes vnd.lotus-organizer
vnd.lotus-screencam vnd.lotus-wordpro
vnd.mcd vnd.mediastation.cdkey
vnd.meridian-slingshot vnd.micrografx.flo
vnd.micrografx.igx vnd.mif
vnd.minisoft-hp3000-save vnd.mitsubishi.misty-guard.trustweb
vnd.Mobius.DAF vnd.Mobius.DIS
vnd.Mobius.MBK vnd.Mobius.MQY
vnd.Mobius.MSL vnd.Mobius.PLC
vnd.Mobius.TXF vnd.mophun.application
vnd.mophun.certificate vnd.motorola.flexsuite
vnd.motorola.flexsuite.adsi vnd.motorola.flexsuite.fis
vnd.motorola.flexsuite.gotap vnd.motorola.flexsuite.kmr
vnd.motorola.flexsuite.ttc vnd.motorola.flexsuite.wem
vnd.mozilla.xul+xml vnd.ms-artgalry
vnd.ms-asf vnd.mseq
vnd.ms-excel vnd.msign
vnd.ms-lrm vnd.ms-powerpoint
vnd.ms-project vnd.ms-tnef
vnd.ms-works vnd.ms-wpl
vnd.musician vnd.music-niff
vnd.nervana vnd.netfpx
vnd.noblenet-directory vnd.noblenet-sealer
vnd.noblenet-web vnd.novadigm.EDM
vnd.novadigm.EDX vnd.novadigm.EXT
vnd.obn vnd.osa.netdeploy
vnd.palm vnd.paos.xml
vnd.pg.format vnd.picsel
vnd.pg.osasli vnd.powerbuilder6
vnd.powerbuilder6-s vnd.powerbuilder7
vnd.powerbuilder75 vnd.powerbuilder75-s
vnd.powerbuilder7-s vnd.previewsystems.box
vnd.publishare-delta-tree vnd.pvi.ptid1
vnd.pwg-multiplexed [RFC3391] vnd.pwg-xhtml-print+xml
vnd.Quark.QuarkXPress vnd.rapid
vnd.s3sms vnd.sealed.doc
vnd.sealed.eml vnd.sealed.mht
vnd.sealed.net vnd.sealed.ppt
vnd.sealed.xls vnd.sealedmedia.softseal.html
vnd.sealedmedia.softseal.pdf vnd.shana.informed.interchange
vnd.shana.informed.formdata vnd.shana.informed.formtemplate
vnd.seemail vnd.shana.informed.package
vnd.smaf vnd.sss-cod
vnd.sss-dtf vnd.sss-ntf
vnd.street-stream vnd.svd
vnd.swiftview-ics vnd.triscape.mxs
vnd.trueapp vnd.truedoc
vnd.ufdl vnd.uiq.theme
vnd.uplanet.alert vnd.uplanet.alert-wbxml
vnd.uplanet.bearer-choice vnd.uplanet.bearer-choice-wbxml
vnd.uplanet.cacheop vnd.uplanet.cacheop-wbxml
vnd.uplanet.channel vnd.uplanet.channel-wbxml
vnd.uplanet.list vnd.uplanet.listcmd
vnd.uplanet.listcmd-wbxml vnd.uplanet.list-wbxml
vnd.uplanet.signal vnd.vcx
vnd.vectorworks vnd.vidsoft.vidconference
vnd.visio vnd.visionary
vnd.vividence.scriptfile vnd.vsf
vnd.wap.sic vnd.wap.slc
vnd.wap.wbxml vnd.wap.wmlc
vnd.wap.wmlscriptc vnd.webturbo
vnd.wqd vnd.wrq-hp3000-labelled
vnd.wt.stf vnd.wv.csp+xml
vnd.wv.csp+wbxml vnd.wv.ssp+xml
vnd.xara vnd.xfdl
vnd.yamaha.hv-dic vnd.yamaha.hv-script
vnd.yamaha.hv-voice vnd.yamaha.smaf-audio
vnd.yamaha.smaf-phrase vnd.yellowriver-custom-menu
watcherinfo+xml whoispp-query
whoispp-response wita
wordperfect5.1 x400-bp
x-debian-package x-java
x-javascript x-gzip
x-msaccess x-msexcel
x-mspowerpoint x-rpm
x-zip xhtml+xml
xml xml-dtd
xml-external-parsed-entity zip

Типы носителей сообщений MIME

CPIM http s-http
delivery-status news sip
disposition-notification partial sipfrag
external-body rfc822

Типы текстовых носителей MIME

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

MIME (Multipurpose Internet Mail Extensions)

MIME
Protocol stack
Purpose Передача различных типов данных по электронной почте
Developer(s) IETF (Internet Engineering Task Force)
Introduced 1991 ; 28 years ago ( 1991 )
OSI layer Уровень представления
RFC(s) RFC 1341, RFC 1342, RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289, RFC 2049, RFC 2045, RFC 1521, RFC 1522, RFC 2183, RFC 2231, RFC 6152, RFC 3030, RFC 2822, RFC 2387, RFC 2388, RFC 6522, RFC 1847, RFC 3156, RFC 7578, RFC 2616

MIME (англ. Multipurpose Internet Mail Extensions — многоцелевые расширения интернет-почты) — стандарт, описывающий передачу различных типов данных по электронной почте (позволяющий вставлять изображения, звуки и текст в сообщение), который впервые был предложен Bell Communications в 1991 году. Также является спецификацией для кодирования информации и форматирования сообщений таким образом, чтобы их можно было пересылать по Интернету. Первоначально он был определен RFC 1341 и RFC 1342 в июне 1992 года. Используя заголовки, MIME описывает тип содержимого сообщения и используемую кодировку. [Источник 1]

MIME добавляет следующие функции в службу электронной почты:

  • Возможность отправлять несколько вложений одним сообщением;
  • Длина сообщений не ограничена;
  • Использование наборов символов, отличных от кода ASCII;
  • Использование разнообразного текста (макеты, шрифты, цвета и т. д.)
  • Двоичные вложения (исполняемые файлы, изображения, аудио- или видеофайлы и т. д.), которые при необходимости могут быть разделены. [Источник 2]

MIME указан в шести связанных RFC-стандартах: RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 и RFC 2049 с интеграцией с электронной почтой SMTP, подробно описанной в RFC 1521 и RFC 1522.

Хотя MIME был разработан в основном для SMTP, типы контента, определенные стандартами MIME, также важны в протоколах связи вне электронной почты, таких как HTTP для World W >[Источник 3] .

Содержание

Заголовки MIME

MIME-Version

Наличие этого заголовка указывает, что сообщение имеет формат MIME. Обычно это значение «1.0», поэтому этот заголовок отображается так:

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

Content-Type

Этот заголовок указывает тип мультимедийного содержимого сообщения, состоящего из типа и подтипа, например: Content-Type: text/plain Благодаря использованию типа multipart, MIME даёт возможность почтовым сообщениям иметь части, расположенные в древовидной структуре, где листовые узлы являются любым многокомпонентным типом содержимого, а не листовые узлы являются любым типом из множества многокомпонентных типов. Этот механизм поддерживает:

  • Простые текстовые сообщения с использованием текста или простой части (значение по умолчанию для «Content-Type:»);
  • Текст и вложения (многокомпонентный / смешанный с текстом / простой частью и другими не текстовыми частями). Сообщение MIME, включающее прикрепленный файл, обычно указывает исходное имя файла с заголовком «Content-disposition:», поэтому тип файла указывается как по типу содержимого MIME, так и по обычному (для ОС) расширению имени файла;
  • Ответ с оригиналом прилагается (многокомпонентный / объединённый с текстом / простая часть и оригинальное сообщение как часть message / rfc822);
  • Альтернативный контент, такой как сообщение, отправленное как в обычном текстовом формате, так и в другом формате, таком как HTML (многокомпонентные / альтернативные с тем же содержимым, в текстовых / обычных и текстовых / html-формах);
  • Изображения, аудио, видео и приложения (например, изображения / jpeg, аудио / mp3, видео / mp4 и приложения / msword и т. д.);
  • и др.

Content-Disposition

Исходные спецификации MIME описывали только структуру почтовых сообщений. Они не затрагивали проблему стилей презентации. Поле заголовка Content-Disposition было добавлено в RFC 2183 для определения стиля представления. Часть MIME может иметь:

  • встроенную функцию для отображения местоположения контента, т.е. когда сообщение выводится на экран, местонахождение содержимого должно выводиться автоматически;
  • в случае, если имеется какое-то вложение, то местонахождение контента может не выводится автоматически, а требовать для этого произвести определённые действия.

В дополнение к стилю представления данный заголовок также предоставляет поля для указания имени файла, даты создания и даты изменения, которые могут использоваться почтовым агентом читателя для хранения вложения. Следующий пример взят из RFC 2183, где определяется заголовок:

Имя файла может быть закодировано в соответствии с RFC 2231.

По состоянию на 2010 год, большинство пользователей почтовых программ не полностью соблюдают это предписание. Широко используемый почтовый клиент Mozilla Thunderbird сам принимает решения о том, какие части MIME должны отображаться автоматически, игнорируя заголовки содержимого в сообщениях. До версии 3 Thunderbird также отправлял новые составленные сообщения с встроенным местоположением контента для всех частей MIME. Большинство пользователей не знают, как установить местоположение контента для вложений. Многие почтовые пользовательские агенты также отправляют сообщения с именем файлам в строке с именем параметра в заголовке content-type вместо параметра имени файла заголовка content-disposition. Эта практика не приветствуется — имя файла должно быть указано либо через параметр имени файла, либо через имя файла и параметры имени.

В HTTP заголовок Content-Disposition: attachment используется для указания представления клиенту тела ответа в виде загружаемого файла. Обычно при получении такого ответа веб-браузер предлагает пользователю сохранить его содержимое в виде файла, а не отображать его как страницу в окне браузера с параметром имени файла, предлагающим имя файла по умолчанию (это полезно для динамически сгенерированного содержимого, при котором извлечение имени файла из URL-адреса может быть бессмысленным или сложным для пользователя).

Content-Transfer-Encoding

В июне 1992 года MIME определил набор методов для представления двоичных данных в форматах, отличных от текстового формата ASCII. Кодирование передачи содержимого (Content-Transfer-Encoding): заголовок MIME имеет двустороннее значение:

  • Он указывает, использовалась ли схема кодирования из двоичного кода в текст поверх исходной кодировки, как указано в заголовке Content-Type:
  1. Если такой способ кодирования двоичного кода в текст использовался, он указывает, какой именно.
  2. Если нет, он предоставляет описательную метку для формата содержимого, в отношении наличия 8-битного или двоичного содержимого.

RFC и список кодов передачи IANA определяют значения, указанные ниже, которые не чувствительны к регистру. Стоит отметить, что ‘7bit’, ‘8bit’ и ‘binary’ означают, что кодировка от двоичного кода к тексту не использовалась поверх исходной кодировки. В этих случаях заголовок фактически является избыточным для декодирования тела сообщения, но он может быть полезен в качестве индикатора того, какой тип объекта отправляется. Значения ‘quoted-printable’ и ‘base64’ указывают клиенту электронной почты, что используется схема кодирования двоичного текста в текст, и для того, чтобы сообщение могло быть прочитано с его оригинальной кодировкой (например, UTF-8), необходимо соответствующее начальное декодирование.

  • Подходит для использования с обычным SMTP:


  1. 7bit — до 998 октетов на строку кодового диапазона 1..127 с CR и LF (коды 13 и 10 соответственно) разрешено появляться только как часть конца строки CRLF. Это значение по умолчанию.
  2. Quoted-printable — используется для кодирования произвольных октетных последовательностей в форму, которая удовлетворяет правилам 7bit. Был разработан, чтобы быть понятным и эффективным в использовании для простого пользователя. Используется для текстовых данных, состоящих в основном из символов US-ASCII, но также содержащих небольшую часть байтов со значениями вне этого диапазона.
  3. Base64 — используется для кодирования произвольных октетных последовательностей в форму, которая удовлетворяет правилам 7bit. Предназначен для работы с не текстовыми 8-битными и двоичными данными. Иногда используется для текстовых данных, которые часто используют символы, отличные от US-ASCII.
  • Подходит для использования с SMTP-серверами, поддерживающими расширение 8BITMIME SMTP (RFC 6152):
  1. 8bit — до 998 октетов на строку с CR и LF (коды 13 и 10 соответственно) разрешено появляться только как часть конца строки CRLF.
  • Подходит для использования с серверами SMTP, которые поддерживают расширение BINARYMIME SMTP (RFC 3030):
  1. Binary — любая последовательность октетов.

Не определено кодирование, которое явно предназначено для отправки произвольных двоичных данных через SMTP с расширением 8BITMIME. Таким образом, если BINARYMIME не поддерживается, иногда полезно использовать base64 или quoted-printable (с их ассоциированной неэффективностью). Это ограничение не распространяется на другие виды использования MIME, такие как веб-службы с MIME-приложениями или MTOM.

Закодированные слова

Начиная с RFC 2822, соответствующие заголовки и значения заголовка сообщения должны быть символами ASCII. Значения, которые содержат данные, отличные от ASCII, должны использовать синтаксис закодированного слова MIME (RFC 2047) вместо строковой буквы. Этот синтаксис использует строку символов ASCII, указывающую как исходную кодировку символов, так и кодировку передачи содержимого, используемую для отображения байтов кодировки в символы ASCII. Например, » =? кодировка ? кодирование ? закодированный текст ?= «.

  • Кодирование может быть любым набором символов, зарегистрированным в IANA. Обычно это будет та же самая кодировка, что и для тела сообщения.
  • Кодирование может быть либо « Q », обозначающим Q-кодирование, которое аналогично кодировке quoted-printable, либо « B », обозначающее кодирование base64.
  • Зашифрованный текст — это текст, закодированный в формате Q или base64.
  • Длина закодированного слова не должна превышать 75 символов, включая кодировку, закодированный текст и разделители. Если хочется закодировать больше текста, чем можно поместить в закодированное слово из 75 символов, можно использовать несколько закодированных слов (разделенных CRLF SPACE).

Различия между кодированием Quoted-printable и Q-кодированием

Коды ASCII для вопросительного знака («?») и знака равенства («=») могут быть представлены не напрямую, поскольку они используются для ограничения кодированного слова. Код ASCII для пространства не может быть представлен напрямую, потому что это может привести к тому, что более старые парсеры будут беспорядочно делить закодированное слово. Чтобы сделать кодировку меньше и чтобы её было проще читать, используют символ подчёркивания для представления кода ASCII для пространства, создающего побочный эффект, который не может быть представлено напрямую. Использование закодированных слов в некоторых частях заголовков накладывает дополнительные ограничения на то, какие символы могут быть представлены непосредственно.

Например, Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?= Это можно перевести как: «Subject:¡Hola, señor!»

Формат кодированного слова не используется для имен заголовков (например, Subject). Эти имена заголовков всегда пишутся на английском языке в исходном сообщении. При просмотре сообщения с почтовым клиентом, отличным от английского, имена заголовков обычно переводится клиентом на нужный язык.

Многокомпонентные сообщения

Многокомпонентное сообщение MIME содержит границу в заголовке «Content-Type:»; Эта граница, которая не должна встречаться ни в одной из частей, помещается между частями, а в начале и в конце тела сообщения следующим образом:

Каждая часть состоит из собственного заголовка содержимого (ноль или более полей Content-header) и тела. Многостраничный контент может быть вложенным. Кодирование передачи содержимого многокомпонентного типа всегда должно быть «7bit», «8bit» или «binary», чтобы избежать осложнений, которые могли бы возникнуть из-за нескольких уровней декодирования. Многокомпонентный блок в целом не имеет кодировки. Не-ASCII-символы в заголовках элементов обрабатываются системой Encoded-Word, а в телах деталей могут быть заданы кодировки, если это необходимо для их типа содержимого.

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

Подтипы многокомпонентного сообщения

Стандарт MIME определяет различные подтипы multipart-сообщений, которые определяют характер частей сообщения и их взаимосвязь друг с другом. Подтип указан в заголовке «Content-Type» для всего сообщения. Например, для многокомпонентного MIME-сообщения, использующего подтип дайджест, его Content-Type будет установлен как «multipart/digest». RFC первоначально определил 4 подтипа: смешанный, дайджест, альтернативный и параллельный. Минимально совместимое приложение должно поддерживать смешанный тип и тип дайджест. Другие подтипы являются необязательными. Приложения должны обрабатывать не распознанные подтипы как «multipart/mixed». Дополнительные подтипы, такие как подпись и данные формы, с тех пор были отдельно определены в других документах RFC. Ниже приведен список наиболее часто используемых подтипов. Он не является исчерпывающим.

Смешанный

Multipart/mixed используется для отправки файлов с различными заголовками Content-Type в очереди (или вложениями). При отправке изображений или других легко читаемых файлов большинство почтовых клиентов будут отображать их в строке (если иное не указано в заголовке «Content-disposition»). В противном случае он будет предлагать их как вложения. Тип контента по умолчанию для каждой части — «text/plain». Определено в RFC 2046, раздел 5.1.3.

Дайджест

Multipart/digest — это простой способ отправки нескольких текстовых сообщений. По умолчанию для каждого компонента используется тип содержимого message/rfc822. Определено в RFC 2046, раздел 5.1.5.

Сообщение

Message/rfc822 содержит сообщение электронной почты, включая любые заголовки. Это используется для дайджестов, а также для пересылки электронной почты. Определено в RFC 2046.

Альтернативный

Подтип multipart/alternative указывает, что каждая часть является «альтернативной» версией того же (или подобного) контента, каждый в другом формате, обозначенном его заголовком «Content-Type». Порядок частей является важным. RFC1341 утверждает, что, в общем случае, пользовательские агенты, создающие multipart/alternative объекты, должны размещать части в порядке возрастания предпочтений, то есть с предпочтительным последним форматом. Затем системы могут выбрать «лучшее» представление, которое они способны обрабатывать. Это будет последняя часть, которую система может понять, хотя на это могут влиять и другие факторы. Поскольку клиент вряд ли захочет отправить версию, которая менее верна, чем версия простого текста, эта структура сначала поместит версию простого текста (если она присутствует). Это облегчает жизнь пользователям клиентов, которые не понимают многокомпонентных сообщений. Чаще всего multipart/alternative используется для электронной почты с двумя частями, одним простым текстом (text/plain) и одним HTML (text/html). Текстовая часть обеспечивает обратную совместимость, в то время как часть HTML позволяет использовать форматирование и гиперссылки. Большинство почтовых клиентов предлагают пользователю вариант использования обычного текста поверх HTML. Это пример того, как локальные факторы могут влиять на то, как приложение выбирает «лучшую» часть отображаемого сообщения. Хотя предполагается, что каждая часть сообщения представляет один и тот же контент, стандарт не требует, чтобы это применялось каким-либо образом. В свое время фильтры защиты от нежелательной почты рассматривали только текстовую/обычную часть сообщения (text/plain), поскольку ее легче анализировать, чем часть text/html. Но в конечном итоге спамеры воспользовались этим, создав сообщения с безобидным текстом/простой частью и рекламой в части text/html. Программное обеспечение для защиты от спама в конечном итоге подхватило этот трюк, штрафуя сообщения с очень разным текстом в multipart/alternative сообщении. Определено в RFC 2046, раздел 5.1.4.

Связанный

Компонент multipart/related используется, чтобы указать, что каждая часть сообщения является компонентом одного целого. Это делается для составных объектов, состоящих из нескольких взаимосвязанных компонентов — надлежащее отображение не может быть достигнуто путем индивидуального отображения составных частей. Сообщение состоит из корневой части (по умолчанию первой), которая ссылается на другие части в очереди, которая, в свою очередь, может ссылаться на другие части. Части сообщения обычно ссылаются на заголовок части «Content-ID». Синтаксис ссылки не указан и вместо этого продиктован кодировкой или протоколом, используемым в части. Одним из распространенных вариантов использования этого подтипа является отправка веб-страницы с изображениями в одном сообщении. Корневая часть будет содержать HTML-документ и использовать теги изображений для ссылки на изображения, хранящиеся в последних частях. Определено в RFC 2387.

Отчёт

Multipart / report — это тип сообщения, который содержит данные, отформатированные для чтения почтовым сервером. Он разделяется между текстом/обычным (или другим содержимым, легко читаемым) и сообщением/статусом доставки, который содержит данные, отформатированные для почтового сервера для чтения. Определено в RFC 6522.


Подписанный

Multipart/signed используется для присоединения цифровой подписи к сообщению. Он имеет ровно две части тела: часть тела и подпись. Вся часть тела, включая заголовки mime, используется для создания части подписи. Возможны многие типы сигнатур, например «application/pgp-signature» (RFC 3156) и «application/pkcs7-signature» (S/MIME). Определено в RFC 1847, Раздел 2.1.

Зашифрованные

Сообщение multipar /encrypted состоит из двух частей. Первая часть содержит управляющую информацию, необходимую для дешифрования второй части приложения/октетного потока. Подобно подписанным сообщениям, существуют различные реализации, которые идентифицируются по отдельным типам контента для элемента управления. Наиболее распространенными типами являются «application/pgp-encrypted» (RFC 3156) и «application/pkcs7-mime» (S/MIME). Определено в RFC 1847, раздел 2.2.

Form-Data

Как следует из названия, multipart/form-data используется для выражения значений, представленных через форму. Первоначально определенный как часть HTML 4.0 наиболее часто используется для отправки файлов через HTTP. Определено в RFC 7578 (ранее RFC 2388).

Смешанно-заменяемый

Тип содержимого multipart/x-mixed-replace был разработан как часть технологии, имитирующей технологию push и потоки через HTTP. Все части сообщения со смешанной заменой имеют одинаковое смысловое значение. Тем не менее, каждая часть аннулирует — «заменяет» — предыдущие части, как только они получены полностью. Клиенты должны обрабатывать отдельные части сразу после их прибытия и не должны дожидаться завершения всего сообщения. Первоначально разработанная Netscape, все еще поддерживается Mozilla, Firefox, Chrome, Safari и Opera, но традиционно игнорируется Microsoft. Он широко используется в IP-камерах в качестве типа MIME для потоков MJPEG.

Byteranges

Параметр multipart/byterange используется для представления несмежных диапазонов байтов одного сообщения. Он используется HTTP, когда сервер возвращает несколько байтовых диапазонов и определен в RFC 2616.

Тест Марка Криспина

Марк Криспин, автор протокола IMAP, написал тест для проверки корректности обработки MIME. Тест представляет собой письмо в формате mbox с таким содержанием: «Это сумасшедшее письмо! В нём около 30 вложенных друг в друга частей. Очень хороший тест». [Источник 4]

Список MIME типов для всех типов файлов

При загрузке файла на сайт WordPress проверят миме-тип файла. Иногда полезно знать как конкретно называется mime тип файла у определенного расширения файла. К примеру .zip файл может иметь разные MIME типы, в зависимости от сервера на котором работает код.

Список ниже поможет быстро собрать нужные варианты MIME-типов для любого формата файла.

В WordPress такой список значительно меньше и найти его можно в описании wp_get_mime_types()

Типы MIME

По сети передаются самые разные данные: Web-страницы, графические изображения, аудио- и видеофайлы, архивы, исполняемые файлы и пр. Эти данные предназначены разным программам. К тому же, с разными данными программа, принявшая их, может поступить по-разному. Так, Web-обозреватель при получении Web- страницы или графического изображения отобразит их на экране, а при получении архива или исполняемого файла — откроет или сохранит его на диске.

Всем передаваемым по сети данным присваивается особое обозначение, однозначно указывающее на их природу, — тип MIME (Multipurpose Internet Mail Extensions, многоцелевые расширения почты Интернета). Тип MIME присваивает данным про- грамма, их отправляющая, например, Web-сервер. А принимающая программа (тот же Web-обозреватель) по типу MIME принятых данных определяет, поддерживает ли она эти данные, и, если поддерживает, что с ними делать.

Web-страница имеет тип MIME text/html. Графическое изображение формата GIF имеет тип MIME image/gif. Тип MIME исполняемого файла — application/ x-msdownload, а архива ZIP — application/x-zip-compressed. Свои типы MIME имеют и мультимедийные файлы.

Вот о мультимедийных файлах и их типах MIME мы и поговорим.

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

В табл. 4.2 перечислены типы MIME форматов мультимедийных файлов, поддерживаемых Web-обозревателями на данный момент.

Таблица 4.2. Типы MIME форматов мультимедийных файлов, поддерживаемых современными Web-обозревателями

Как видим, один формат файлов может иметь несколько типов MIME. Обычно выбирается самый первый из списка как самый предпочтительный.

Вооружившись необходимой теорией, приступим к практике. Сейчас мы выясним, как HTML 5 позволит нам поместить аудио или видео на Web-страницу.

MIME-типы в HTML

Стандарт MIME, или в нотации Internet RFC-1341, RFC-1521 , предназначен для описания тела почтового сообщения Internet. Предшественником MIME является стандарт почтового сообщения ARPA (RFC822). Стандарт RFC822 был разработан для обмена текстовыми сообщениями. С момента опубликования стандарта возможности аппаратных средств и телекоммуникаций ушли далеко вперед и стало ясно, что многие типы информации, которые широко используются в сети невозможно передать по почте без специальных ухищрений. Так в тело сообщения нельзя включить графику, аудио, видео и другие типы информации. RFC822 не дает возможностей для передачи даже текстовой информации, которую нельзя реализовать в семибитовой кодировке ASCII. Естественно, что при использовании RFC822 не может быть и речи о передаче размеченного текста для отображения его различными стилями. Ограничения RFC822 становятся еще более очевидными, когда речь заходит об обмене сообщениями в разных почтовых системах. Например, для приема/передачи сообщений из/в X.400, который позволяет иметь двоичные данные в теле сообщения, ограничения старого стандарта могут стать фатальными, так как не спасает старый испытанный способ кодировки информации процедурой uuencode, так как эти данные могут быть по-различному проинтерпретированы в X.400 и программе рассылки почты в Internet (mail-agent). Расширением стандарта RFC-1341 является стандарт RFC-1521 , который добавляет некоторые новые типы данных и поля тела сообщения.

В некотором смысле стандарт MIME ортогонален стандарту RFC822. Если последний подробно описывает в заголовке почтового сообщения текстовое тело письма и механизм его рассылки, то MIME, главным образом, сориентирован на описание в заголовке письма структуры тела почтового сообщения и возможности составления письма из информационных единиц различных типов.

В стандарте зарезервировано несколько способов представления разнородной информации. Для этой цели используются специальные поля заголовка почтового сообщения:

  • поле версии MIME, которое используется для идентификации сообщения, подготовленного в новом стандарте;
  • поле описания типа информации в теле сообщения, которое позволяет обеспечить правильную интерпретации данных;
  • поле типа кодировки информации в теле сообщения, указывающее на тип процедуры декодирования;
  • два дополнительных поля, зарезервированных для более детального описания тела сообщения.

Стандарт MIME разработан как расширяемая спецификация, в которой подразумевается, что число типов данных будет расти по мере развития форм представления данных. При этом следует учитывать, что анархия типов (безграничное их увеличение) тоже не допустима. Каждый новый тип в обязательном порядке должен быть зарегистрирован в IANA (Internet Assigned Numbers Authority). Остановимся подробнее на форме и назначении полей, определяемых стандартом.

Поле типа кодирования почтового сообщения (Content-Transfer-Encoding).
Многие данные передаются по почте в их исходном виде. Это могут быть 7bit символы, 8bit символы, 64base символы и т.п. Однако при работе в разнородных почтовых средах необходимо определить механизм их представления в стандартном виде — US-ASCII. Для этого существуют процедуры кодирования такого сорта данных. Наиболее широко применяемая — uuencode. Для того, чтобы при получении данные были бы правильно распакованы и введено в стандарт поле «Сontent-Transfer-Encoding». Синтаксис этого поля следующий:

Каждая из альтернатив применяется в своем подходящем случае. Альтернативы «8bit», «7bit», «BINARY» реально никакого преобразования не требуют, так как почта передается байтами и SMTP не делает различия между ними. Однако они введены для строгости описания типов. «BASE64» обычно используется в связке с типом «text/ISO-8859-1», «x-token» позволяет пользователю описать свою процедуру преобразования.

Поле версии MIME (MIME-Version)

Поле версии указывается в заголовке почтового сообщения и позволяет определить программе рассылки почты, что сообщение подготовлено в стандарте MIME. Формат поля выглядит как:

Поле версии указывается в общем заголовке почтового сообщения и относится ко всему сообщению целиком. Здесь уместно отметить, что в отличие от стандарта RFC822, стандарт MIME позволяет перемешивать поля заголовка сообщения с телом сообщения. Поэтому все поля делятся на два класса: общие поля заголовка, которые записываются в начале почтового сообщения и частные поля заголовка, которые относятся только к отдельным частям составного сообщения и записываются перед ними.

Поле типа содержания тела почтового сообщения (Content-Type)

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

  1. текст (text);
  2. смешанный тип (multipart);
  3. почтовое сообщение (message);
  4. графический образ (image);
  5. аудио информация (audio);
  6. фильм или видео (v > Остановимся подробнее на каждом из типов, разрешенных стандартом MIME.

«Text&quot.
Этот тип указывает на то, что в теле сообщения содержится текст. Основным подтипом типа «text» является «plain», что обозначает так называемый планарный текст. Понятие планарного текста появилось в связи с тем, что существует еще размеченный текст, т.е. текст со встроенными в него символами управления отображением, и гипертекст, т.е. текст, который можно просматривать не последовательно, а произвольно, следуя гипертекстовым ссылкам. Для обозначения размеченного текста используют подтип «richtext», а для обозначения гипертекста подтип «html». Вообще говоря, «html» — это специальный вид размеченного текста, который используется для представления гипертекстовой информации в системе World W > «Richtext» определяет текст со встроенными в него специальными управляющими последовательностями, которые в соответствии со стандартом языка разметки документов SGML называются тагами. Таги представляют из себя последовательность символов типа » «. «Строка-символов» определяет управляющее действие. Таги делятся на таги начала элемента текста (» «) и таги конца элемента текста (» «). В качестве примера такой разметки можно привести следующий фрагмент текста:

В этом фрагменте означает выделение «жирным» шрифтом, — курсив, — мелкий шрифт, — знак » , новая строка как .

Специальный тип разметки задается подтипом «html». Это так называемый гипертекст. Разметка гипертекста строится по тому же принципу как и в тексте типа «richtext».Однако применяются таги, позволяющие описать гипертекстовые ссылки. К таким тагам относятся » . «, , . Таг » . определяет следующий фрагмент текста, который будет просматриваться. При этом текст между тагом начала и тагом конца будет выделен в программе просмотра цветом или другим способом и используется как контекстная гипертекстовая ссылка. Таг задет встроенный в текст документа графический образ. В некотором смысле этот таг аналогичен «multipart», который разрешает комбинировать сообщение из нескольких фрагментов разного типа. Таг определяет «якорь», т.е. место внутри документа, на которое можно сослаться как на метку. В качестве примера такой разметки текста можно привести следующий фрагмент:

«Multipart».
Этот тип содержания тела почтового сообщения определяет смешанный документ. Смешанный документ может состоять из фрагментов данных разного типа. Данный тип имеет ряд подтипов.

Подтип «mixed» — задает сообщение, состоящее из нескольких фрагментов, которые разделены между собой границей, задаваемой в качестве параметра подтипа. Приведем простой пример:

В данном примере поле «Content-Type» определяет подтип «mixed» и границу между фрагментами, как строку «—simple boundary—«. В начале каждого фрагмента может быть задана своя строка с полем «Content-Type». Как видно из примера, существует два фрагмента, которые не отображаются: преамбула и эпилог, в которые можно поместить комментарии.

Другим подтипом может быть подтип «alternative». Данный подтип позволяет организовать вариабельный просмотр почтового сообщения в зависимости от типа программы просмотра. Приведем пример:

В этом примере для работы с планарным текстом при использовании алфавитно-цифровых программ просмотра предназначен первый фрагмент текста. Для просмотра размеченного текста используется второй фрагмент, для специальной программы просмотра может быть подготовлен специальный вариант (фрагмент 3).

Подтип «digest» предназначен для многоцелевого почтового сообщения, когда различным частям хотят приписать более детальную информацию, чем просто тип:

Приведенный пример показывает как можно воспользоваться подтипом «digest» для рассылки почты разным пользователям и по-разному поводу, используя поля «From:» и «Subject» в качестве частных заголовков.

Подтип «parallel» предназначен для составления такого почтового сообщения, части которого должны отображаться одновременно, что предполагает запуск сразу нескольких программ просмотра. Синтаксис такого сообщения аналогичен рассмотренным выше.

Тип «message».
Данный тип предназначен для работы с обычными почтовыми сообщениями, которые однако не могут быть переданы по почте по разного рода причинам. Эти причины объясняются подтипами данного типа.

Подтип «partial» предназначен для передачи одного большого сообщения по частям для последующей автоматической сборки у получателя.
Этот механизм может пригодиться, когда промежуточные почтовые шлюзы ограничивают индивидуальный размер пересылаемых писем. Т.о., этот подтип говорит о том, что письмо содержит лишь часть большого послания.

Для этого подтипа необходимо указание трех параметров:

  1. «id» — уникальный идентификатор, позволяющий обнаружить остальные части послания.
  2. «number» — целое число, означающее номер части послания.
  3. «total» — целое число, означающее общее количество частей. Требуется лишь в последней части и не обязателен (хотя рекомендуется) для предыдущих частей. Эти параметры могут следовать в произвольном порядке.

При «сборке» таких посланий в пункте назначения должны учитываться следующие правила:

  1. Все поля заголовка части 1, кроме начинающихся с «Content-» и специальных «Message- >Замечание по кодированию тела MIME-письма, заключенного внутри тела message/partial: так как данные типа «message» никогда не могут быть кодированы в Base64 или Quoted-Printable, следующая проблема может возникнуть в случае, если тела писем типа message/partial созданы в системе, поддерживающей 8-битный транспорт. Двоичные данные будут разбиты на несколько message/partial-объектов, каждому из которых требуется транспортировка в двоичном виде. Если бы таким объектам пришлось пройти через шлюз в 7-битную транспортную среду, их невозможно было бы перекодировать в сеимбитную форму без ожидания прибытия всех частей послания, собирания их воедино и затем кодирования целого послания в 7-битную кодировку (base64 или quoted-printable). Поскльку существует вероятность, что разные части пойдут разными путями (через различные шлюзы), то подобное решение не приемлимо. Поэтому MIME определяет, что письма типа message/partial должны иметь 7-битную кодировку и соответствующее ей значение поля content-transfer-encoding. Даже для систем с транспортом, поддерживающим «8-бит» и «binary», запрещается их использование для данных message/partial.

    Многие почтовые агенты могут автоматически фрагментировать большие письма.

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

    Поле заголовка «Encrypted» вышло из употребления, но вышеприведенные правила обеспечивают корректную его интерпретацию, если оно встречается при обработке фрагментов типа message/partial. Приведем пример передачи аудио сообщения разбитого на части:

    Атрибуты подтипа определяют идентификатор сообщения ( > Другим подтипом является «External-Body», который позволяет ссылаться на внешние, относительно сообщения, информационные источники. Этот подтип похож на гипертекстовую ссылку из типа «text». Приведем конкретный пример:

    В данном примере приведено использование «External-Body» и «multipart/alternative». Все сообщение разбито на несколько фрагментов. В каждом из фрагментов находится ссылка на внешний файл. Реально тела почтового сообщения нет (границы программами просмотра не отображаются). Однако если программа просмотра способна работать с внешними протоколами, то можно ссылки разрешить автоматически, запуская соответствующий сервис.

    Единственный всегда обязательный параметр для ‘message/external-body’ — «access-type». Остальные параметры могут быть или не быть обязательными в зависимости от значения параметра «access-type».

    Значение этого параметра — слово, нечувствительное к регистру букв, означающее механизм доступа, с помощью которого файл или данные могут быть получены. Значения могут быть следующими (но не ограничиваются этим рядом): «FTP», «ANON-FTP», «TFTP», «AFS», «LOCAL-FILE» и «MAIL-SERVER». Будущие возможные значения, кроме экспериментальных, начинающихся с «X-«, должны быть зарегистрированы в IANA.

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

    EXPIRATION — Дата (RFC 822 «date-time» синтаксис допускает 4 цифры в этом поле), после которой существование внешних данных не гарантируется.

    SIZE — размер (в байтах) данных. Позволяет получателю решить, расходовать ли ресурсы на считывание внешних данных. Размер указывается для канонической формы данных (то есть, до применения каких-либо преобразований).

    PERMISSION — нечувствительное к регистру букв поле, говорящее о том, ожидается или нет, что клиент может перезаписывать данные. По умолчанию или когда этот параметр имеет значение «read», полагается, что клиент не имеет на это права, и что если данные однажды считаны, то больше они не понадобятся. Если PERMISSION имеет значение «read-write», любая локальная копия может рассматриваться не более как кэш. «read» и «write» — единственные предопределенные значения для PERMISSION.

    Вложенные заголовки во ВСЕХ телах типа message/external-body ДОЛЖНЫ включать поле заголовка Content- >Обозначения, описывающие данные типа external-body, такие как имена файлов или команды mail-сервера, должны быть в символьном наборе US-ASCII.

    Как и для типа message/partial, тело типа message/external-body должно иметь значение content-transfer-encoding «7-bit» (по умолчанию). В частности, даже в системах, поддержиавющих 8-битный транспорт, применение content-transfer-encoding «8-bit» и «binary» запрещено для данных типа message/external-body.

    Илон Маск рекомендует:  Что такое код drop table
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL