Тип носителя (ранее известный как тип MIME ) [1] представляет собой идентификатор, состоящий из двух частей, для форматов файлов и содержимого формата, передаваемых через Интернет . Их назначение в чем-то похоже на расширения файлов, поскольку они определяют предполагаемый формат данных. Управление по присвоению номеров Интернета (IANA) является официальным органом по стандартизации и публикации этих классификаций. Типы мультимедиа были первоначально определены в документе «Запрос комментариев» RFC 2045 (MIME), часть первая: формат тел интернет-сообщений (ноябрь 1996 г.) в ноябре 1996 г. как часть спецификации MIME (многоцелевые расширения почты Интернета) для обозначения типа содержимого сообщения электронной почты . и вложения; [2] отсюда и оригинальное название MIME-тип . Типы мультимедиа также используются другими интернет-протоколами, такими как HTTP [3] и форматами файлов документов, такими как HTML , [4] для аналогичных целей.
Тип носителя состоит из типа и подтипа , который далее структурируется в дерево . Тип носителя может дополнительно определять суффикс и параметры :
mime-type = тип "/" [ дерево "." ] подтип [ суффикс "+" ] * [ ";" параметр ];
Например, HTML-файл может иметь обозначение text/html; charset=UTF-8
. В этом примере text
— тип, html
— подтип и charset=UTF-8
необязательный параметр, указывающий кодировку символов.
Типы, подтипы и имена параметров не чувствительны к регистру. Значения параметров обычно чувствительны к регистру, но могут интерпретироваться без учета регистра в зависимости от предполагаемого использования. [2]
Часть «тип» определяет широкое использование типа носителя. По состоянию на ноябрь 1996 года зарегистрированными типами были: application
, audio
, image
, message
, multipart
и text
. [2] К декабрю 2020 года зарегистрированные типы включали вышеперечисленные, а также , и . [1]video
font
example
model
Неофициальный широко используемый тип верхнего уровня — chemical
. [5] [6] [7]
Подтип обычно состоит из медиа-формата, но он может или должен также содержать другой контент, например префикс дерева, производителя, продукт или суффикс, в соответствии с различными правилами в деревьях регистрации.
Все типы носителей должны быть зарегистрированы с использованием процедур регистрации IANA. Для повышения эффективности и гибкости процесса регистрации типов носителей различные структуры подтипов могут быть зарегистрированы в деревьях регистрации, отличающихся использованием префиксов деревьев. На данный момент созданы следующие деревья: стандартное (без префикса), поставщик ( vnd.
префикс), личное или тщеславное ( prs.
префикс), незарегистрированное ( x.
префикс). Эти деревья регистрации были впервые определены в ноябре 1996 года (устаревший RFC 2048 — в настоящее время RFC 6838). Новые деревья регистрации могут быть созданы IETF Standards Action для внешней регистрации и управления известными постоянными организациями (например, научными обществами).
Дерево стандартов не использует префикс дерева. Примеры: text/javascript
, image/png
. [8]
Регистрации в дереве стандартов должны быть либо связаны со спецификациями IETF, одобренными непосредственно IESG, либо зарегистрированы признанной IANA организацией, связанной со стандартами.
Дерево поставщиков включает типы носителей, связанные с общедоступными продуктами. Он использует vnd.
префикс дерева. Примеры: application/vnd.ms-excel
, application/vnd.oasis.opendocument.text
.
Термины «поставщик» и «производитель» считаются эквивалентными в контексте. Отраслевые консорциумы, а также некоммерческие организации могут регистрировать типы носителей в дереве поставщиков. Регистрацию в дереве поставщиков может создать любой, кому необходимо обмениваться файлами, связанными с каким-либо программным продуктом или набором продуктов. Однако регистрация принадлежит поставщику или организации, производящей программное обеспечение, использующее регистрируемый тип, и этот поставщик или организация могут в любое время заявить о своем праве на регистрацию, сделанную третьей стороной.
Личное или тщеславное дерево включает типы мультимедиа, связанные с непублично доступными продуктами или экспериментальными типами мультимедиа. Он использует prs.
префикс дерева. Примеры: audio/prs.sid
, image/prs.btif
.
Незарегистрированное дерево включает типы носителей, предназначенные исключительно для использования в частных средах и только при активном согласии обменивающихся ими сторон. Он использует x.
префикс дерева. Примеры: application/x.foo
, video/x.bar
. Типы носителей в этом дереве зарегистрировать невозможно.
Первоначально этот тип был определен в RFC 1590 (опубликован в сентябре 1993 г.) с использованием префикса x-
или X-
. В RFC 2048 (опубликованном в ноябре 1996 г.) был введен x.
префикс, но не рекомендуется использовать незарегистрированное дерево, поскольку теперь доступны новые личные деревья и деревья поставщиков с упрощенными требованиями к регистрации. Текущий RFC 6838 (опубликованный в январе 2013 г.) содержит ту же рекомендацию, но подтипы с префиксом x-
или X-
больше не считаются членами этого дерева.
Типы носителей, которые получили широкое распространение (с подтипом с префиксом x-
или X-
) без регистрации, должны быть, если возможно, перерегистрированы с использованием соответствующего подтипа с префиксом. Если это невозможно, тип носителя может быть зарегистрирован в дереве стандартов после утверждения как рецензентом типов носителей, так и IESG, с его подтипом без префикса. application/x-www-form-urlencoded
является примером широко распространенного типа, который в конечном итоге был зарегистрирован с этим x-
префиксом. [9]
Суффикс — это дополнение к определению типа носителя, позволяющее дополнительно указать базовую структуру этого типа носителя, что позволяет выполнять общую обработку на основе этой структуры и независимо от конкретной семантики конкретного типа. Типы носителей, использующие именованный структурированный синтаксис, "+"suffix
при регистрации должны использовать соответствующий номер IANA, зарегистрированный для этого структурированного синтаксиса. Незарегистрированные суффиксы использовать нельзя (с января 2013 г.). Процедуры регистрации структурированных синтаксических суффиксов определены в RFC 6838. [8]
Суффикс +xml был определен с января 2001 года (RFC 3023 [10] ) и был формально включен в исходное содержимое реестра структурированных синтаксических суффиксов вместе с +json
, +ber
, +der
, +fastinfoset
, +wbxml
и +zip
в январе 2013 года (RFC 6839). Последующие дополнения включают +gzip
, +cbor
, +json-seq
, и +cbor-seq
. [11]
Из реестра IANA: [1]
application/json
application/ld+json
( JSON-LD )application/msword
(.doc)application/pdf
application/sql
application/vnd.api+json
application/vnd.microsoft.portable-executable
(.efi, .exe, .dll)application/vnd.ms-excel
(.xls)application/vnd.ms-powerpoint
(.ppt)application/vnd.oasis.opendocument.text
(.odt)application/vnd.openxmlformats-officedocument.presentationml.presentation
(.pptx)application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
(.xlsx)application/vnd.openxmlformats-officedocument.wordprocessingml.document
(.docx)application/x-www-form-urlencoded
application/xml
application/zip
application/zstd
(.zst)audio/mpeg
audio/ogg
image/avif
image/jpeg
(.jpg, .jpeg, .jfif, .pjpeg, .pjp) [12]image/png
image/svg+xml
(.svg)image/tiff
(.tif)model/obj
(.obj)multipart/form-data
text/plain
text/css
text/csv
text/html
text/javascript
(.js)text/xml
Mailcap (происходит от фразы «почтовые возможности») — это тип метафайла, используемый для настройки того, как приложения, поддерживающие MIME, такие как почтовые клиенты и веб-браузеры, отображают файлы различных типов MIME. Формат mailcap определен в RFC 1524 «Механизм настройки агента пользователя для информации о формате мультимедийной почты», но не определен как стандарт Интернета. Он поддерживается большинством систем Unix.
Строки могут быть комментариями, начинающимися с символа #, или mime-типом, за которым следует описание того, как обращаться с этим mime-типом.
Связанный файл — это файл mime.types , который связывает расширения имени файла с типом MIME . Если тип MIME установлен правильно, в этом нет необходимости, но типы MIME могут быть установлены неправильно или установлены в общий тип, такой как application/octet-stream
, и mime.types позволяет в этих случаях использовать расширение. Аналогичным образом, поскольку многие файловые системы не хранят информацию о типе MIME, а вместо этого полагаются на расширение имени файла, файл mime.types часто используется веб-серверами для определения типа MIME.
При просмотре файла эти два параметра работают вместе следующим образом: mime.types
связывают расширение с типом MIME, а mailcap
тип MIME связывают с программой.
В системах типа UNIX файл mime.types обычно расположен по адресу и/или, а формат таков, что каждая строка представляет собой разделенный пробелами список типов MIME, за которым следует ноль или более расширений. Например, тип HTML можно связать с расширениями и следующей строкой:/etc/mime.types
$HOME/.mime.types
.htm
.html
текст/html html html
Файл mime.types относится к Netscape , где использовался другой формат; [13] он использовал пары ключ-значение и список расширений, разделенных запятыми, вместе со стандартным заголовком , состоящим из определенного комментария, который идентифицирует файл как файл mime.types, а именно:
#--Информация MIME Netscape Communications Corporation# Не удаляйте приведенную выше строку. Он используется для идентификации типа файла.тип=текст/html exts=htm,html
В [RFC2046] указано, что типы носителей (ранее известные как типы MIME) и подтипы носителей будут назначаться и перечисляться IANA.