Формат файла — это стандартный способ кодирования информации для хранения в компьютерном файле . Он определяет, как биты используются для кодирования информации на цифровом носителе . Форматы файлов могут быть либо фирменными , либо свободными .
Некоторые форматы файлов предназначены для очень конкретных типов данных: файлы PNG , например, хранят растровые изображения с использованием сжатия данных без потерь . Другие форматы файлов, однако, предназначены для хранения нескольких различных типов данных: формат Ogg может выступать в качестве контейнера для различных типов мультимедиа , включая любую комбинацию аудио и видео , с текстом или без него (например, субтитры ), и метаданных . Текстовый файл может содержать любой поток символов, включая возможные управляющие символы , и закодирован в одной из различных схем кодирования символов . Некоторые форматы файлов, такие как HTML , масштабируемая векторная графика и исходный код компьютерного программного обеспечения, представляют собой текстовые файлы с определенными синтаксисами , которые позволяют использовать их для определенных целей.
Форматы файлов часто имеют опубликованную спецификацию , описывающую метод кодирования и позволяющую тестировать предполагаемую функциональность программы. Не все форматы имеют свободно доступные документы спецификации, отчасти потому, что некоторые разработчики рассматривают свои документы спецификации как коммерческую тайну , а отчасти потому, что другие разработчики никогда не создают формальный документ спецификации, позволяя прецеденту, установленному другими уже существующими программами, которые используют формат, определять формат через то, как эти существующие программы его используют.
Если разработчик формата не публикует бесплатные спецификации, другой разработчик, желающий использовать этот тип файла, должен либо провести обратную разработку файла, чтобы узнать, как его читать, либо получить документ спецификации у разработчиков формата за плату и подписав соглашение о неразглашении . Последний подход возможен только при наличии формального документа спецификации. Обе стратегии требуют значительного времени, денег или и того, и другого; поэтому форматы файлов с общедоступными спецификациями, как правило, поддерживаются большим количеством программ.
Патентное право, а не авторское право , чаще используется для защиты формата файла. Хотя патенты на форматы файлов напрямую не разрешены законодательством США, некоторые форматы кодируют данные с использованием запатентованных алгоритмов . Например, до 2004 года использование сжатия с форматом файла GIF требовало использования запатентованного алгоритма, и хотя владелец патента изначально не обеспечивал соблюдение своего патента, позже он начал собирать роялти . Это привело к значительному сокращению использования GIF и частично ответственно за разработку альтернативного формата PNG . Однако патент GIF истек в США в середине 2003 года, а во всем мире — в середине 2004 года.
Различные операционные системы традиционно используют разные подходы к определению формата конкретного файла, причем каждый подход имеет свои преимущества и недостатки. Большинству современных операционных систем и отдельных приложений необходимо использовать все следующие подходы для чтения «чужих» форматов файлов, если они не работают с ними полностью.
Одним из популярных методов, используемых многими операционными системами, включая Windows , macOS , CP/M , DOS , VMS и VM/CMS , является определение формата файла на основе окончания его имени, а точнее букв, следующих за последней точкой. Эта часть имени файла известна как расширение имени файла . Например, документы HTML идентифицируются именами, которые заканчиваются на .html (или .htm ), а изображения GIF — на .gif . В исходной файловой системе FAT имена файлов были ограничены восьмисимвольным идентификатором и трехсимвольным расширением, известным как имя файла 8.3 . Существует ограниченное количество трехбуквенных расширений, что может привести к тому, что данное расширение будет использоваться более чем одной программой. Многие форматы по-прежнему используют трехсимвольные расширения, хотя современные операционные системы и прикладные программы больше не имеют этого ограничения. Поскольку стандартного списка расширений не существует, несколько форматов могут использовать одно и то же расширение, что может сбить с толку как операционную систему, так и пользователей.
Одним из артефактов этого подхода является то, что систему можно легко обмануть, заставив ее обрабатывать файл как файл другого формата, просто переименовав его — например, файл HTML можно легко обрабатывать как обычный текст , переименовав его из filename.html в filename.txt . Хотя эта стратегия была полезна для опытных пользователей, которые могли легко понимать и манипулировать этой информацией, она часто сбивала с толку менее технически подкованных пользователей, которые могли случайно сделать файл непригодным для использования (или «потерять» его), неправильно переименовав его.
Это привело к тому, что большинство версий Windows и Mac OS стали скрывать расширение при выводе списка файлов. Это предотвращает случайное изменение пользователем типа файла и позволяет опытным пользователям отключать эту функцию и отображать расширения.
Однако скрытие расширения может создать видимость двух или более одинаковых имен файлов в одной папке. Например, логотип компании может потребоваться как в формате .eps (для публикации), так и в формате .png (для веб-сайтов). При видимых расширениях они будут отображаться как уникальные имена файлов: " CompanyLogo.eps " и " CompanyLogo.png ". С другой стороны, скрытие расширений приведет к тому, что оба файла будут отображаться как " CompanyLogo ", что может привести к путанице.
Скрытие расширений также может представлять угрозу безопасности. [1] Например, злонамеренный пользователь может создать исполняемую программу с невинным именем, таким как « Holiday photo.jpg.exe ». « .exe » будет скрыт, и ничего не подозревающий пользователь увидит « Holiday photo.jpg », которое будет выглядеть как изображение JPEG , обычно неспособное нанести вред машине. Однако операционная система все равно увидит расширение « .exe » и запустит программу, которая затем сможет нанести вред компьютеру. То же самое относится и к файлам только с одним расширением: поскольку оно не отображается пользователю, никакая информация о файле не может быть выведена без явного исследования файла. Чтобы еще больше обмануть пользователей, можно сохранить значок внутри программы, и в этом случае назначение значка некоторыми операционными системами для исполняемого файла ( .exe ) будет переопределено значком, обычно используемым для представления изображений JPEG, что сделает программу похожей на изображение. Расширения также могут быть подделаны: некоторые макровирусы Microsoft Word создают файл Word в формате шаблона и сохраняют его с расширением .doc . Поскольку Word обычно игнорирует расширения и смотрит на формат файла, они будут открываться как шаблоны, выполняться и распространять вирус. [ необходима цитата ] Это представляет практическую проблему для систем Windows, где скрытие расширений включено по умолчанию.
Второй способ определения формата файла — использовать информацию о формате, хранящуюся внутри самого файла, либо информацию, предназначенную для этой цели, либо двоичные строки , которые всегда находятся в определенных местах в файлах некоторых форматов. Поскольку проще всего их найти в начале, такую область обычно называют заголовком файла , если она больше нескольких байт , или магическим числом , если ее длина составляет всего несколько байт.
Метаданные, содержащиеся в заголовке файла , обычно хранятся в начале файла, но могут присутствовать и в других областях, часто включая конец, в зависимости от формата файла или типа содержащихся данных. Символьные (текстовые) файлы обычно имеют символьные заголовки, тогда как двоичные форматы обычно имеют двоичные заголовки, хотя это не правило. Текстовые заголовки файлов обычно занимают больше места, но, будучи читаемыми человеком, их можно легко изучить с помощью простого программного обеспечения, такого как текстовый редактор или шестнадцатеричный редактор.
Помимо идентификации формата файла, заголовки файлов могут содержать метаданные о файле и его содержимом. Например, большинство файлов изображений хранят информацию о формате изображения, размере, разрешении и цветовом пространстве , а также, опционально, информацию об авторе, например, кто создал изображение, когда и где оно было сделано, какая модель камеры и какие фотографические настройки использовались ( Exif ) и т. д. Такие метаданные могут использоваться программным обеспечением, считывающим или интерпретирующим файл во время процесса загрузки и после него.
Заголовки файлов могут использоваться операционной системой для быстрого сбора информации о файле без загрузки всей информации в память, но это использует больше ресурсов компьютера, чем прямое чтение из информации каталога . Например, когда графический файловый менеджер должен отобразить содержимое папки, он должен прочитать заголовки многих файлов, прежде чем он сможет отобразить соответствующие значки, но они будут расположены в разных местах на носителе, поэтому доступ к ним займет больше времени. Папка, содержащая много файлов со сложными метаданными, такими как информация об эскизах, может потребовать значительного времени, прежде чем ее можно будет отобразить.
Если заголовок жестко закодирован в двоичном виде , так что сам заголовок требует сложной интерпретации для распознавания, особенно в целях защиты содержимого метаданных, существует риск, что формат файла может быть неправильно истолкован. Он даже мог быть плохо написан в источнике. Это может привести к повреждению метаданных, что в крайне плохих случаях может даже сделать файл нечитаемым. [ требуется разъяснение ]
Более сложным примером заголовков файлов являются те, которые используются для форматов файлов- оболочек (или контейнеров).
Один из способов включения метаданных типа файла, часто связанных с Unix и его производными, — это сохранение «магического числа» внутри самого файла. Первоначально этот термин использовался для определенного набора 2-байтовых идентификаторов в начале файлов, но поскольку любая двоичная последовательность может рассматриваться как число, любая особенность формата файла, которая уникально его отличает, может использоваться для идентификации. Например, изображения GIF всегда начинаются с представления ASCII либо , GIF87aлибо GIF89a, в зависимости от стандарта, которому они соответствуют. Многие типы файлов, особенно файлы с простым текстом, сложнее обнаружить этим методом. Например, файлы HTML могут начинаться со строки <html>(которая не чувствительна к регистру) или соответствующего определения типа документа , которое начинается с <!DOCTYPE html, или, для XHTML , идентификатора XML , который начинается с <?xml. Файлы также могут начинаться с комментариев HTML, случайного текста или нескольких пустых строк, но при этом быть пригодными для использования HTML.
Подход с использованием магических чисел дает лучшие гарантии того, что формат будет определен правильно, и часто может определить более точную информацию о файле. Поскольку достаточно надежные тесты на «магические числа» могут быть довольно сложными, и каждый файл должен быть эффективно протестирован на все возможности в базе магических чисел, этот подход относительно неэффективен, особенно для отображения больших списков файлов (в отличие от этого, методы на основе имен файлов и метаданных должны проверять только один фрагмент данных и сопоставлять его с отсортированным индексом). Кроме того, данные должны быть считаны из самого файла, что увеличивает задержку по сравнению с метаданными, хранящимися в каталоге. Если типы файлов не поддаются распознаванию таким образом, система должна вернуться к метаданным. Однако это лучший способ для программы проверить, имеет ли файл, который ей было сказано обработать, правильный формат: хотя имя файла или метаданные могут быть изменены независимо от его содержимого, провал хорошо продуманного теста на магические числа является довольно верным признаком того, что файл либо поврежден, либо имеет неправильный тип. С другой стороны, корректное магическое число не гарантирует, что файл не поврежден или имеет правильный тип.
Так называемые строки shebang в файлах скриптов являются особым случаем магических чисел. Здесь магическое число — это текст, который может быть прочитан человеком и который идентифицирует конкретный интерпретатор команд и параметры, которые должны быть переданы интерпретатору команд.
Другая операционная система, использующая магические числа, — AmigaOS , где магические числа назывались «Magic Cookies» и были приняты в качестве стандартной системы для распознавания исполняемых файлов в формате исполняемых файлов Hunk , а также для того, чтобы позволить отдельным программам, инструментам и утилитам автоматически работать с сохраненными файлами данных или любыми другими типами файлов при сохранении и загрузке данных. Затем эта система была улучшена с помощью стандартной системы распознавания Datatype Amiga . Другим методом был метод FourCC , возникший в OSType на Macintosh, позже адаптированный Interchange File Format (IFF) и производными.
Последний способ сохранения формата файла — явное сохранение информации о формате в файловой системе, а не в самом файле.
Этот подход сохраняет метаданные отдельно от основных данных и имени, но также менее переносим , чем расширения имен файлов или «магические числа», поскольку формат должен быть преобразован из одной файловой системы в другую. Хотя это также верно в некоторой степени для расширений имен файлов — например, для совместимости с ограничением MS-DOS на три символа — большинство форм хранения имеют примерно эквивалентное определение данных и имени файла, но могут иметь разное или не иметь представления о дополнительных метаданных.
Обратите внимание, что zip-файлы или архивные файлы решают проблему обработки метаданных. Утилитная программа собирает несколько файлов вместе с метаданными о каждом файле и папках/каталогах, из которых они были получены, в один новый файл (например, zip- файл с расширением .zip ). Новый файл также сжимается и, возможно, шифруется, но теперь его можно передавать как один файл между операционными системами с помощью FTP- передач или отправлять по электронной почте в качестве вложения. В пункте назначения полученный один файл должен быть распакован совместимой утилитой, чтобы быть полезным. Проблемы обработки метаданных решаются таким образом с помощью zip-файлов или архивных файлов.
Иерархическая файловая система Mac OS хранит коды создателя и типа как часть записи каталога для каждого файла. Эти коды называются OSTypes. Эти коды могут быть любой 4-байтовой последовательностью, но часто выбирались так, чтобы представление ASCII формировало последовательность значимых символов, таких как аббревиатура имени приложения или инициалы разработчика. Например, файл « стек» HyperCard имеет создателя WILD ( от предыдущего названия Hypercard, «WildCard») и тип STAK . Текстовый редактор BBEdit имеет код создателя ссылающийся на его оригинального программиста, Рича Сигела. Код типа определяет формат файла, в то время как код создателя определяет программу по умолчанию для его открытия при двойном щелчке пользователем. Например, у пользователя может быть несколько текстовых файлов, все с кодом типа TEXT , но каждый из них открывается в другой программе из-за разных кодов создателя. Эта функция была предназначена для того, чтобы, например, читаемые человеком простые текстовые файлы можно было открывать в текстовом редакторе общего назначения, в то время как файлы программирования или HTML-кода открывались в специализированном редакторе или IDE . Однако эта функция часто была источником путаницы для пользователей, поскольку то, какая программа запустится при двойном щелчке по файлам, часто было непредсказуемо. RISC OS использует похожую систему, состоящую из 12-битного числа, которое можно найти в таблице описаний — например, шестнадцатеричное число «присваивается» PoScript , представляя файл PostScript .R*chFF5
Единый идентификатор типа (UTI) — это метод, используемый в macOS для уникальной идентификации «типизированных» классов сущностей, таких как форматы файлов. Он был разработан Apple в качестве замены OSType (коды типа и создателя).
UTI — это строка Core Foundation , которая использует строку обратного DNS . Некоторые общие и стандартные типы используют домен, называемый public (например, public.png для изображения Portable Network Graphics ), в то время как другие домены могут использоваться для сторонних типов (например, com.adobe.pdf для Portable Document Format ). UTI могут быть определены в иерархической структуре, известной как иерархия соответствия. Таким образом, public.png соответствует супертипу public.image , который сам соответствует супертипу public.data . UTI может существовать в нескольких иерархиях, что обеспечивает большую гибкость.
Помимо форматов файлов, UTI также могут использоваться для других сущностей, которые могут существовать в macOS, включая:
В IBM OS/VS через z/OS каталог VSAM (до каталогов ICF ) и запись тома VSAM в наборе данных тома VSAM (VVDS) (с каталогами ICF) идентифицируют тип набора данных VSAM.
В IBM OS/360 — z/OS блок управления набором данных (DSCB) формата 1 или 7 в таблице содержания тома (VTOC) идентифицирует организацию набора данных ( DSORG ) описываемого им набора данных.
Файловые системы HPFS , FAT12 и FAT16 (но не FAT32) позволяют хранить «расширенные атрибуты» с файлами. Они включают в себя произвольный набор триплетов с именем, закодированный тип для значения и значение, где имена уникальны, а значения могут быть длиной до 64 КБ. Существуют стандартизированные значения для определенных типов и имен (в OS/2 ). Одним из них является то, что расширенный атрибут «.TYPE» используется для определения типа файла. Его значение включает в себя список из одного или нескольких типов файлов, связанных с файлом, каждый из которых является строкой, например «Обычный текст» или «Документ HTML». Таким образом, файл может иметь несколько типов.
Файловая система NTFS также позволяет хранить расширенные атрибуты OS/2, как одну из ветвей файлов , но эта функция присутствует только для поддержки подсистемы OS/2 (отсутствует в XP), поэтому подсистема Win32 рассматривает эту информацию как непрозрачный блок данных и не использует ее. Вместо этого она полагается на другие ветви файлов для хранения метаинформации в специфичных для Win32 форматах. Расширенные атрибуты OS/2 по-прежнему могут читаться и записываться программами Win32, но данные должны быть полностью проанализированы приложениями.
В Unix и Unix-подобных системах файловые системы ext2 , ext3 , ext4 , ReiserFS версии 3, XFS , JFS , FFS и HFS+ позволяют хранить расширенные атрибуты с файлами. Они включают произвольный список строк "имя=значение", где имена уникальны, а доступ к значению можно получить через его связанное имя.
Постоянный уникальный идентификатор PRONOM (PUID) — это расширяемая схема постоянных, уникальных и однозначных идентификаторов для форматов файлов, разработанная Национальным архивом Великобритании в рамках его технической службы реестра PRONOM . PUID могут быть выражены как унифицированные идентификаторы ресурсов с использованием пространства имен info:pronom/ . Хотя схема PUID пока не получила широкого распространения за пределами правительства Великобритании и некоторых программ цифрового сохранения , она обеспечивает большую детализацию, чем большинство альтернативных схем.
Типы MIME широко используются во многих интернет -приложениях и все чаще в других местах, хотя их использование для информации о типах на диске встречается редко. Они состоят из стандартизированной системы идентификаторов (управляемой IANA ), состоящей из типа и подтипа , разделенных косой чертой — например, text/html или image/gif . Первоначально они были предназначены для определения типа файла, прикрепленного к электронному письму , независимо от исходной и целевой операционных систем. Типы MIME идентифицируют файлы в BeOS , AmigaOS 4.0 и MorphOS , а также хранят уникальные подписи приложений для запуска приложений. В AmigaOS и MorphOS система типов MIME работает параллельно с системой типов данных, специфичной для Amiga.
Однако существуют проблемы с типами MIME: несколько организаций и людей создали свои собственные типы MIME, не зарегистрировав их должным образом в IANA, что в некоторых случаях делает использование этого стандарта неудобным.
Идентификаторы форматов файлов — это еще один, не очень широко используемый способ идентификации форматов файлов в соответствии с их происхождением и категорией файла. Он был создан для пакета программного обеспечения Description Explorer. Он состоит из нескольких цифр в форме NNNNNNNNN-XX-YYYYYYY. Первая часть указывает на организацию-источник/поддерживающего (это число представляет собой значение в базе данных компании/организации по стандартизации), а следующие 2 цифры классифицируют тип файла в шестнадцатеричном формате . Последняя часть состоит из обычного расширения имени файла или международного стандартного номера файла, дополненного слева нулями. Например, спецификация файла PNG имеет FFID, 000000001-31-0015948где 31указывает на файл изображения, 0015948является стандартным номером и 000000001указывает на Международную организацию по стандартизации (ISO).
Другой менее популярный способ определения формата файла — это проверка содержимого файла на наличие различимых шаблонов среди типов файлов. Содержимое файла представляет собой последовательность байтов, а байт имеет 256 уникальных перестановок (0–255). Таким образом, подсчет появления шаблонов байтов, который часто называют распределением частоты байтов, дает различимые шаблоны для определения типов файлов. Существует множество схем идентификации типов файлов на основе содержимого, которые используют распределение частоты байтов для построения репрезентативных моделей для типа файла и используют любые статистические и методы добычи данных для определения типов файлов. [2]
Существует несколько типов способов структурирования данных в файле. Наиболее распространённые из них описаны ниже.
Более ранние форматы файлов использовали форматы необработанных данных, которые заключались в прямом сбросе образов памяти одной или нескольких структур в файл.
Это имеет несколько недостатков. Если образы памяти также не имеют зарезервированных мест для будущих расширений, расширение и улучшение этого типа структурированного файла очень сложно. Это также создает файлы, которые могут быть специфичны для одной платформы или языка программирования (например, структура, содержащая строку Pascal, не распознается как таковая в C ). С другой стороны, разработка инструментов для чтения и записи этих типов файлов очень проста.
Ограничения неструктурированных форматов привели к разработке других типов форматов файлов, которые можно было бы легко расширять и в то же время иметь обратную совместимость.
В этом виде файловой структуры каждый фрагмент данных встроен в контейнер, который каким-то образом идентифицирует данные. Область действия контейнера может быть идентифицирована с помощью начальных и конечных маркеров какого-либо типа, явного поля длины где-либо или фиксированных требований определения формата файла.
В течение 1970-х годов многие программы использовали форматы этого общего вида. Например, текстовые процессоры, такие как troff , Script и Scribe , а также файлы экспорта баз данных, такие как CSV . Electronic Arts и Commodore - Amiga также использовали этот тип формата файла в 1985 году с их форматом файла IFF (Interchange File Format).
Контейнер иногда называют «куском» , хотя «кусок» может также подразумевать, что каждый кусок небольшой и/или что куски не содержат другие куски; многие форматы не предъявляют таких требований.
Информация, которая идентифицирует определенный «кусок», может называться по-разному, часто терминами, включая «имя поля», «идентификатор», «метка» или «тег». Идентификаторы часто читаются человеком и классифицируют части данных: например, как «фамилия», «адрес», «прямоугольник», «имя шрифта» и т. д. Это не то же самое, что идентификаторы в смысле ключа базы данных или серийного номера (хотя идентификатор вполне может идентифицировать связанные с ним данные как такой ключ).
При таком типе структуры файла инструменты, которые не знают определенных идентификаторов фрагментов, просто пропускают те, которые они не понимают. В зависимости от фактического значения пропущенных данных это может быть полезным или нет ( CSS явно определяет такое поведение).
Эта концепция неоднократно использовалась в RIFF (эквивалент IFF от Microsoft-IBM), PNG, хранилище JPEG, закодированных потоках и файлах DER ( Distinguished Encoding Rules ) (которые изначально были описаны в CCITT X.409:1984 и, следовательно, появились раньше IFF), а также в формате структурированного обмена данными (SDXF) .
Действительно, любой формат данных должен каким-то образом определять значимость своих составных частей, и встроенные маркеры границ являются очевидным способом сделать это:
Это еще один расширяемый формат, который очень похож на файловую систему ( документы OLE являются фактическими файловыми системами), где файл состоит из «записей каталога», которые содержат местоположение данных внутри самого файла, а также его сигнатуры (и в некоторых случаях его тип). Хорошими примерами таких типов файловых структур являются образы дисков , исполняемые файлы , документы OLE TIFF , библиотеки .
Некоторые форматы файлов, такие как ODT и DOCX, основанные на PKZIP , оба разбиты на фрагменты и содержат каталог. [ необходима цитата ]
Структура формата файла на основе каталога более легко поддается изменениям, чем неструктурированные или фрагментированные форматы. [ требуется цитата ] Природа этого типа формата позволяет пользователям тщательно конструировать файлы, которые заставляют программное обеспечение для чтения делать то, что авторы формата никогда не планировали. Примером этого является zip-бомба . Форматы файлов на основе каталога также используют значения, которые указывают на другие области в файле, но если некоторое более позднее значение данных указывает на данные, которые были прочитаны ранее, это может привести к бесконечному циклу для любого программного обеспечения для чтения, которое предполагает, что входной файл является допустимым, и слепо следует циклу. [ требуется цитата ]
