Jump to content

Формат файла

(Перенаправлено из двоичной подписи )
Duration: 13 seconds.
wav-файл: 2,1 мегабайта.
Duration: 20 seconds.
ogg-файл: 154 килобайта.

Формат файла — это стандартный способ кодирования информации для хранения в компьютерном файле . Он определяет, как биты используются для кодирования информации на цифровом носителе . Форматы файлов могут быть как проприетарными , так и бесплатными .

Некоторые форматы файлов предназначены для очень специфических типов данных: PNG например, файлы хранят растровые изображения с использованием сжатия данных без потерь . Однако другие форматы файлов предназначены для хранения нескольких различных типов данных: формат Ogg может выступать в качестве контейнера для различных типов мультимедиа , включая любую комбинацию аудио и видео , с текстом или без него (например, субтитры ), а также метаданные. . Текстовый файл может содержать любой поток символов, включая возможные управляющие символы , и кодируется одной из различных схем кодировки символов . Некоторые форматы файлов, такие как HTML , масштабируемая векторная графика и исходный код компьютерного программного обеспечения, представляют собой текстовые файлы с определенным синтаксисом , который позволяет использовать их для определенных целей.

Технические характеристики

[ редактировать ]

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

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

патентное право, а не авторское право Для защиты формата файла чаще используется . Хотя патенты на форматы файлов напрямую не разрешены законодательством США, некоторые форматы кодируют данные с использованием запатентованных алгоритмов . Например, до 2004 года использование сжатия в формате GIF требовало использования запатентованного алгоритма, и хотя владелец патента изначально не защищал свой патент, позже он начал взимать роялти . Это привело к значительному сокращению использования GIF-файлов и частично стало причиной развития альтернативного формата PNG . Однако срок действия патента GIF истек в США в середине 2003 года, а во всем мире — в середине 2004 года.

Определение типа файла

[ редактировать ]

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

Расширение имени файла

[ редактировать ]

Одним из популярных методов, используемых во многих операционных системах, включая Windows , macOS , CP/M , DOS , VMS и VM/CMS , является определение формата файла на основе окончания его имени, точнее, букв, следующих за окончательным именем. период. Эта часть имени файла называется расширением имени файла . Например, документы HTML идентифицируются по именам, оканчивающимся на .html (или .htm ) и изображения GIF от .гиф . В исходной FAT файловой системе имена файлов были ограничены восьмизначным идентификатором и трехзначным расширением, известным как имя файла 8.3 . Существует ограниченное количество трехбуквенных расширений, из-за чего одно и то же расширение может использоваться более чем одной программой. Многие форматы по-прежнему используют трехсимвольные расширения, хотя современные операционные системы и прикладные программы больше не имеют этого ограничения. Поскольку стандартного списка расширений не существует, одно и то же расширение может использоваться более чем в одном формате, что может сбить с толку как операционную систему, так и пользователей.

Одним из артефактов этого подхода является то, что систему можно легко обмануть и заставить воспринимать файл как другой формат, просто переименовав его — HTML- например, файл можно легко рассматривать как обычный текст , переименовав его из имя_файла.html в имя файла.txt . Хотя эта стратегия была полезна для опытных пользователей, которые могли легко понимать и манипулировать этой информацией, она часто сбивала с толку менее технических пользователей, которые могли случайно сделать файл непригодным для использования (или «потерять» его), неправильно переименовав его.

Это привело к тому, что большинство версий Windows и Mac OS скрывали расширение при перечислении файлов. Это предотвращает случайное изменение типа файла пользователем и позволяет опытным пользователям отключать эту функцию и отображать расширения.

Однако сокрытие расширения может привести к появлению двух или более одинаковых имен файлов в одной папке. Например, логотип компании может понадобиться как в формат .eps (для публикации) и Формат .png (для веб-сайтов). Если расширения будут видны, они будут выглядеть как уникальные имена файлов: " CompanyLogo.eps "и" CompanyLogo.png ". С другой стороны, если скрыть расширения, оба будут отображаться как " CompanyLogo », что может привести к путанице.

Скрытие расширений также может представлять угрозу безопасности. [1] Например, злонамеренный пользователь может создать исполняемую программу с невинным именем, например « Праздничное фото.jpg.exe ". The " .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

[ редактировать ]

Mac OS Иерархическая файловая система хранит коды создателя и типа как часть записи каталога для каждого файла. Эти коды называются OSTypes. Эти коды могли представлять собой любую 4-байтовую последовательность, но часто выбирались так, чтобы представление ASCII образовывало последовательность значимых символов, таких как сокращение имени приложения или инициалы разработчика. Например, HyperCard файл стека создателя имеет WILD (от предыдущего названия Hypercard «WildCard») тип и СТАК . Текстовый редактор BBEdit имеет код создателя R*ch ссылаясь на первоначального программиста Рича Сигела . Код типа определяет формат файла, а код создателя указывает программу по умолчанию, с помощью которой он будет открываться при двойном щелчке пользователем. Например, у пользователя может быть несколько текстовых файлов с кодом типа ТЕКСТ , но каждый из них открывается в другой программе из-за разных кодов создателя. Эта функция была предназначена для того, чтобы, например, удобочитаемые текстовые файлы можно было открывать в текстовом редакторе общего назначения, а файлы программирования или HTML-кода открывались в специализированном редакторе или IDE . Однако эта функция часто вызывала путаницу у пользователей, поскольку зачастую невозможно было предсказать, какая программа будет запускаться при двойном щелчке по файлам. ОС RISC использует аналогичную систему, состоящую из 12-битного числа, которое можно найти в таблице описаний, например шестнадцатеричное число. FF5 является "псевдонимом" к PoScript , представляющий файл PostScript .

Идентификаторы универсального типа macOS (UTI)

[ редактировать ]

Унифицированный идентификатор типа (UTI) — это метод, используемый в macOS для уникальной идентификации «типизированных» классов объектов, таких как форматы файлов. Он был разработан Apple в качестве замены OSType (коды типа и создателя).

UTI — это Core Foundation строка , которая использует строку обратного DNS . Некоторые распространенные и стандартные типы используют домен под названием общественность (например, public.png для изображения переносимой сетевой графики ), в то время как другие домены могут использоваться для сторонних типов (например, com.adobe.pdf для формата переносимого документа ). UTI могут быть определены в рамках иерархической структуры, известной как иерархия соответствия. Таким образом, public.png соответствует супертипу public.image , который сам по себе соответствует супертипу общественные.данные . 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 ) описываемого им набора данных.

Расширенные атрибуты OS/2

[ редактировать ]

Файловые системы HPFS , FAT12 и FAT16 (но не FAT32) позволяют хранить «расширенные атрибуты» файлов. Они включают произвольный набор троек с именем, кодовым типом значения и значением, причем имена уникальны, а длина значений может достигать 64 КБ. Существуют стандартизированные значения для определенных типов и имен (в OS/2 ). Одним из них является то, что расширенный атрибут «.TYPE» используется для определения типа файла. Его значение включает список одного или нескольких типов файлов, связанных с файлом, каждый из которых представляет собой строку, например «Обычный текст» или «Документ HTML». Таким образом, файл может иметь несколько типов.

Файловая система NTFS также позволяет хранить расширенные атрибуты OS/2 в качестве одного из файловых ответвлений , но эта функция предназначена просто для поддержки подсистемы OS/2 (отсутствует в XP), поэтому подсистема Win32 рассматривает эту информацию как непрозрачную. блок данных и не использует его. Вместо этого он полагается на другие файловые ветки для хранения метаинформации в форматах, специфичных для Win32. Расширенные атрибуты OS/2 по-прежнему могут читаться и записываться программами Win32, но данные должны полностью анализироваться приложениями.

Расширенные атрибуты POSIX

[ редактировать ]

В Unix и Unix-подобных системах файловые системы ext2 , ext3 , ext4 , ReiserFS версии 3, XFS , JFS , FFS и HFS+ позволяют хранить расширенные атрибуты файлов. К ним относится произвольный список строк «имя=значение», имена которых уникальны, а к значению можно получить доступ через связанное с ним имя.

Уникальные идентификаторы местоимений (PUID)

[ редактировать ]

Постоянный уникальный идентификатор PRONOM (PUID) — это расширяемая схема постоянных, уникальных и однозначных идентификаторов форматов файлов, разработанная Национальным архивом Великобритании в рамках службы технического реестра PRONOM . PUID можно выразить как унифицированные идентификаторы ресурсов, используя информация:проном/ пространство имен. еще не широко используется за пределами правительства Великобритании и некоторых программ сохранения цифровых данных Хотя схема PUID , она обеспечивает большую степень детализации, чем большинство альтернативных схем.

Типы MIME широко используются во многих приложениях, связанных с Интернетом , и все чаще в других местах, хотя их использование для информации о типах на диске встречается редко. Они состоят из стандартизированной системы идентификаторов (управляемой IANA ), состоящей из типа и подтипа , разделенных косой чертой — например, текст/html или изображение/гиф . Первоначально они были предназначены для определения типа файла, прикрепленного к электронному письму , независимо от исходной и целевой операционных систем. Типы MIME идентифицируют файлы на BeOS , AmigaOS 4.0 и MorphOS , а также хранят уникальные сигнатуры приложений для запуска приложений. В AmigaOS и MorphOS система типов Mime работает параллельно со специальной системой типов данных Amiga.

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

Идентификаторы формата файлов (FFID)

[ редактировать ]

Идентификаторы формата файлов — это еще один, не широко используемый способ идентификации форматов файлов в зависимости от их происхождения и категории файлов. Он был создан для пакета программного обеспечения 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) .

Действительно, любой формат данных должен каким-то образом определять значимость его составных частей, и встроенные граничные маркеры являются очевидным способом сделать это:

  • Заголовки MIME делают это с помощью метки, разделенной двоеточием, в начале каждой логической строки. Заголовки MIME не могут содержать другие заголовки MIME, хотя содержимое данных некоторых заголовков имеет подразделы, которые можно извлечь с помощью других соглашений.
  • CSV и подобные файлы часто делают это, используя записи заголовков с именами полей и запятыми для обозначения границ полей. Как и MIME, CSV не поддерживает структуры с более чем одним уровнем.
  • XML и его родственники можно условно рассматривать как своего рода формат, основанный на фрагментах, поскольку элементы данных идентифицируются с помощью разметки, похожей на идентификаторы фрагментов. Однако у него есть формальные преимущества, такие как схемы и проверка , а также возможность представлять более сложные структуры, такие как деревья , группы DAG и диаграммы . Если XML считается «блочным» форматом, то SGML и его предшественник IBM GML являются одними из первых примеров таких форматов.
  • JSON похож на XML без схем, перекрестных ссылок или определения значения повторяющихся имен полей и часто удобен для программистов.
  • YAML похож на JSON, но использует отступы для разделения фрагментов данных и стремится быть более удобочитаемым, чем JSON или XML.
  • Буферы протокола , в свою очередь, похожи на JSON, в частности заменяя граничные маркеры в данных номерами полей, которые сопоставляются с именами с помощью некоторого внешнего механизма.

Форматы на основе каталогов

[ редактировать ]

Это еще один расширяемый формат, который очень похож на файловую систему ( документы OLE — это настоящие файловые системы), где файл состоит из «записей каталога», которые содержат расположение данных внутри самого файла, а также его подписи (и в некоторых случаях случаях его типа). Хорошими примерами этих типов файловых структур являются образы дисков , исполняемые файлы , документы OLE TIFF , библиотеки .

Некоторые форматы файлов, такие как ODT и DOCX, основанные на PKZIP , разбиты на части и содержат каталог. [ нужна ссылка ]

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

См. также

[ редактировать ]
  1. ^ Мир ПК (23 декабря 2003 г.). «Советы по Windows: в целях безопасности полезно знать расширения файлов» . Архивировано из оригинала 23 апреля 2008 года . Проверено 20 июня 2008 г.
  2. ^ «Идентификация формата файла» . Архивировано из оригинала 14 августа 2009 г. Проверено 21 июля 2009 г.
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 064275586a4865e975cf7b105da415fe__1722200640
URL1:https://arc.ask3.ru/arc/aa/06/fe/064275586a4865e975cf7b105da415fe.html
Заголовок, (Title) документа по адресу, URL1:
File format - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)