Формат файла — это стандартный способ кодирования информации для хранения в компьютерном файле . Он определяет, как биты используются для кодирования информации на цифровом носителе. Форматы файлов могут быть как проприетарными , так и бесплатными .
Некоторые форматы файлов предназначены для очень специфических типов данных: например, файлы 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. текст . Хотя эта стратегия была полезна для опытных пользователей, которые могли легко понимать и манипулировать этой информацией, она часто сбивала с толку менее технических пользователей, которые могли случайно сделать файл непригодным для использования (или «потерять» его), неправильно переименовав его.
Это привело к тому, что большинство версий 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.
Метод магических чисел дает лучшие гарантии того, что формат будет определен правильно, и часто позволяет определить более точную информацию о файле. Поскольку достаточно надежные тесты «магических чисел» могут быть довольно сложными, и каждый файл должен быть эффективно проверен на соответствие всем возможным возможностям в магической базе данных, этот подход относительно неэффективен, особенно для отображения больших списков файлов (в отличие от имен файлов и метаданных). основанные методы должны проверять только один фрагмент данных и сопоставлять его с отсортированным индексом). Кроме того, данные необходимо считывать из самого файла, что увеличивает задержку по сравнению с метаданными, хранящимися в каталоге. Если типы файлов не поддаются распознаванию таким образом, система должна вернуться к метаданным. Однако для программы это лучший способ проверить, имеет ли файл, который ей было поручено обработать, правильный формат: хотя имя файла или метаданные могут быть изменены независимо от его содержимого, не пройдя хорошо продуманный тест магических чисел. это верный признак того, что файл либо поврежден, либо имеет неправильный тип. С другой стороны, действительный магический номер не гарантирует, что файл не поврежден или имеет правильный тип.
Так называемые строки шебанга в файлах сценариев представляют собой особый случай магических чисел. Здесь магическое число — это удобочитаемый текст, который идентифицирует конкретный интерпретатор команд и параметры, которые необходимо передать интерпретатору команд.
Другая операционная система, использующая магические числа, - это AmigaOS , где магические числа назывались «Magic Cookies» и были приняты в качестве стандартной системы для распознавания исполняемых файлов в формате исполняемого файла Hunk , а также для того, чтобы отдельные программы, инструменты и утилиты могли автоматически обрабатывать свои сохраненные файлы данных. или любые другие типы файлов при сохранении и загрузке данных. Затем эта система была дополнена стандартной системой распознавания типов данных 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 использует аналогичную систему, состоящую из 12-битного числа, которое можно найти в таблице описаний — например, шестнадцатеричное число является «псевдонимом» PoScript , представляя файл PostScript .R*chFF5
Унифицированный идентификатор типа (UTI) — это метод, используемый в macOS для уникальной идентификации «типизированных» классов объектов, таких как форматы файлов. Он был разработан Apple в качестве замены OSType (коды типа и создателя).
UTI — это строка Core Foundation , которая использует строку обратного DNS . Некоторые распространенные и стандартные типы используют домен, называемый public (например, public.png для изображения переносимой сетевой графики ), в то время как другие домены могут использоваться для сторонних типов (например, com.adobe.pdf для переносимого формата документа ). 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. Первая часть указывает на организацию/разработчика (это число представляет собой значение в базе данных компании/организации по стандартизации), а две следующие цифры определяют тип файла в шестнадцатеричном формате . Последняя часть состоит из обычного расширения имени файла или международного стандартного номера файла, дополненного нулями слева. Например, спецификация файла 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 ( отличительными правилами кодирования ) (которые первоначально были описаны в CCITT X.409:1984 и, следовательно, предшествовали IFF). ) и Формат обмена структурированными данными (SDXF) .
Действительно, любой формат данных должен каким-то образом определять значимость его составных частей, и встроенные граничные маркеры являются очевидным способом сделать это:
Это еще один расширяемый формат, который очень похож на файловую систему ( документы OLE — это настоящие файловые системы), где файл состоит из «записей каталога», которые содержат расположение данных внутри самого файла, а также его подписи (и в некоторых случаях случаях его типа). Хорошими примерами этих типов файловых структур являются образы дисков , исполняемые файлы , документы OLE TIFF , библиотеки .
Некоторые форматы файлов, такие как ODT и DOCX, основанные на PKZIP , разбиты на части и содержат каталог. [ нужна цитата ]
Структура формата файлов на основе каталогов легче поддается модификации, чем неструктурированные или фрагментированные форматы. [ нужна цитата ] Природа этого типа формата позволяет пользователям тщательно создавать файлы, которые заставляют программное обеспечение для чтения делать то, чего авторы формата никогда не планировали. Примером этого является почтовая бомба . Форматы файлов на основе каталогов также используют значения, указывающие на другие области файла, но если какое-либо более позднее значение данных указывает на данные, которые были прочитаны ранее, это может привести к бесконечному циклу для любого программного обеспечения чтения, которое предполагает, что входной файл действителен и слепо следует за циклом. [ нужна цитата ]
