Справочник MIME-типов

MIME-тип (Многоцелевые расширения почты Интернета) — это стандарт для представления природы и формата документа, файла или потока байтов. Браузеры и серверы используют MIME-типы для определения способа обработки файла. Например, когда браузер получает тип image/jpeg, он отображает изображение. MIME-типы описывают, какой контент содержит файл или HTTP-ответ: text/html, application/json, image/png, application/pdf и другие. Они влияют на отображение в браузере, скачивание, API parsing, upload validation, caching и security behavior. Расширение файла и MIME-тип не всегда совпадают, поэтому проверка важна при диагностике сервера, неизвестных файлов и проблем загрузки. Для безопасности MIME-типам нельзя доверять вслепую; нужно сочетать inspection содержимого, правила расширений и явный allowlist.

MIME-типы (Multipurpose Internet Mail Extensions) — это стандартизированные идентификаторы форматов данных, первоначально определённые в RFC 2045/RFC 2046 для почтовых вложений и впоследствии принятые в HTTP (RFC 7231 §3.1.1.5) для согласования веб-контента. MIME-тип имеет структуру type/subtype — тип указывает общую категорию (text, image, audio, video, application, multipart, font, model), а подтип — точный формат (например, text/html, image/png, application/json). Необязательные параметры указываются после точки с запятой (text/html; charset=utf-8). Агентство Internet Assigned Numbers Authority (IANA) ведёт официальный реестр MIME-типов на iana.org/assignments/media-types. Регистрация регламентируется RFC 6838, который определяет процесс рецензирования, требующий документ спецификации, раздел о межоперабельности и соображения безопасности. Незарегистрированные типы могут использовать префикс x- (например, application/x-tar) как соглашение для экспериментальных или вендорных форматов, хотя RFC 6648 рекомендует отказываться от префикса x- в пользу надлежащей регистрации. В HTTP заголовок Content-Type сообщает клиенту, как интерпретировать тело ответа. Сервер, возвращающий Content-Type: image/svg+xml, запускает SVG-рендерер браузера; Content-Type: application/octet-stream вызывает диалог загрузки, поскольку браузер не может определить формат. Браузер также использует информацию о MIME-типе для MIME sniffing — когда сервер опускает Content-Type или отправляет обобщённый тип, браузер может проанализировать первые несколько байтов ответа (магические байты), чтобы угадать фактический формат. Это поведение контролируется заголовком X-Content-Type-Options: nosniff, который отключает угадывание и требует от сервера объявить правильный тип. При загрузке файлов заголовок Accept сообщает серверу, какие MIME-типы клиент ожидает в ответе, а атрибут accept элемента input ограничивает выбор файлов определёнными типами (например, accept="image/png, image/jpeg"). На стороне сервера загруженные файлы следует проверять как по объявленному MIME-типу, так и по сигнатуре файла (магическим байтам), поскольку ни один из них по отдельности не является надёжным — файл с именем image.png и Content-Type: image/png может содержать исполняемый код. Инструмент служит справочником для поиска канонического MIME-типа по расширению файла, охватывая более 100 распространённых форматов в восьми категориях.

• Структура RFC 2046: type/subtype — тип указывает общую категорию контента, а подтип — точный формат; необязательные параметры следуют после точки с запятой (text/html; charset=utf-8) и не чувствительны к регистру по спецификации, хотя строчные буквы являются общепринятым соглашением.
• Регистрация IANA (RFC 6838): новые медиатипы требуют документ спецификации, раздел о соображениях безопасности и примечания о межоперабельности — процесс рецензирования гарантирует, что типы хорошо документированы и конфликты исключены до их включения в реестр.
• Заголовок HTTP Content-Type: сервер объявляет MIME-тип тела ответа; браузер использует его для выбора подходящего рендерера (HTML-парсер, декодер изображений, средство просмотра PDF) или запуска загрузки — некорректный Content-Type является самой частой причиной ошибок «файл загружается вместо отображения».
• MIME sniffing и X-Content-Type-Options: когда Content-Type отсутствует или является обобщённым, браузеры могут анализировать магические байты для определения формата — X-Content-Type-Options: nosniff отключает это поведение и требует точного совпадения Content-Type, что является рекомендацией по безопасности.
• application/octet-stream: обобщённый тип двоичного запасного варианта — браузеры рассматривают его как непрозрачный поток и инициируют загрузку, что делает его наиболее безопасным вариантом по умолчанию, когда сервер не может определить формат, но это препятствует предварительному просмотру иначе отображаемого контента в браузере.
• Проверка загружаемых файлов: атрибут accept элемента input фильтрует выбор файлов на стороне клиента, но проверка на стороне сервера должна проверять как объявленный Content-Type, так и магические байты файла — несовпадение расширения, MIME-типа и сигнатуры файла является тревожным сигналом при загрузке вредоносных файлов.
• Вендорные и экспериментальные типы: соглашение о префиксе x- (application/x-tar, video/x-matroska) предшествует формальному процессу регистрации — RFC 6648 рекомендует при возможности переводить их на надлежащие типы, зарегистрированные в IANA, но многие из них по-прежнему широко используются.