Формат файла zip что это

Современное использование

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

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

Множество конкурирующих архиваторов, помимо своего собственного, также поддерживают формат ZIP. Этот способ сжатия также широко используется в других программах и даже в некоторых форматах файлов.

Программа kzip является экстремальным по степени сжатия упаковщиком в формат ZIP и применяется людьми, привязанными к zip-формату (например, для публикации программного обеспечения в вебе или

Источник

Бесплатный архиватор для Windows

Поддержка всех форматов архивации

Выбор темы оформления программы

Полностью бесплатное использование

Сочетание функций и стиля

WindowsZIP – сочетание высокой производительности, небольшого веса и продуманного дизайна. Речь идет об удобной утилите для архивации текстов, музыки, видеороликов, фото, различного софта. Привлекает обширным функционалом и детализированным интерфейсом.

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

Богатый функционал

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

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

Поддержка всех форматов

Посредством менеджера расширения файлов, вы можете выбрать, в каком формате сохранить архив. Доступно более 20 вариаций, включая:

WindowsZIP предусматривает открытие любых архивов, даже которые создавались посредством портативных устройств. Более того вы можете создать и изменить папки на ПК под разные операционные системы, включая Андроид и прочее.

Источник

Zip – как не нужно создавать формат файлов

Zip появился 32 года назад. Можно подумать, что настолько зрелый формат должен быть отлично задокументирован. К сожалению, нет. Что же конкретно в нем не так, и каким образом его можно было бы оптимизировать? Подробно рассмотрим эти вопросы, опираясь на исходную документацию.

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

Если коротко, то zip-файл состоит из записей, каждая запись начинается с некоторого 4-байтового маркера, который обычно имеет следующую структуру:

* некоторые форматы требуют округления длины до ближайшего числа, кратного 4 или 16. Zip же этого не делает. Если вы видите id и не знаете, как этот тип содержимого записи структурирован, то понять, сколько байтов нужно пропустить, вам не удастся.

4.1.9 ZIP-архивы МОГУТ быть потоковыми, разделенными на сегменты (на стационарных или съемных носителях) либо «самораспаковывающимися» (SFX). SFX-архивы ДОЛЖНЫ нести в себе код извлечения для целевой платформы.

4.3.3 Файлы внутри ZIP-архива можно сохранять в произвольном порядке. ZIP-архив МОЖЕТ включать несколько томов или быть разделен на сегменты определенного пользователем размера. Все значения ДОЛЖНЫ храниться в порядке байтов от младшего к старшему, если для конкретного элемента данных этой документацией не установлено иное.

4.3.7 Local file header:

4.3.12 Структура центрального каталога:

4.3.16 End of central directory record:

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

Как создать DOS (или другой не-нативный) SFX-архив под Unix?
Суть этой процедуры объяснена на странице мануала UnZipSFX. Сперва понадобится подходящий бинарный дистрибутив UnZip для целевой платформы (DOS, Windows, OS/2 и т.д.). В следующем примере мы предположим, что работаем с DOS. Затем нужно извлечь из дистрибутива модуль UnZipSFX и добавить его, как если бы он был нативным модулем Unix:

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

Ну а теперь с учетом всего этого мы пройдемся по ряду проблем.

Как считывать zip-файл?

В спецификации по этому поводу ничего не сказано.

Есть два очевидных пути:

Файлы внутри ZIP-архива МОЖНО заменять, добавлять и удалять.

Как вам? Это предполагает, что центральный каталог может ссылаться не на все файлы архива, иначе это утверждение о возможности добавления, замены и удаления файлов не имело бы смысла.

Другими словами, если перед нами такая структура:

Тогда очевидно, что B удален, поскольку центральный каталог на него не ссылается. С другой стороны, если [local file B] отсутствует, тогда мы имеем просто независимый zip-архив, т.е. независимый от другого zip-архива, в котором B содержится. Нет необходимости даже упоминать об этой ситуации в спецификации.

Аналогичным образом, если перед нами:

Это может показаться бессмыслицей, но нужно помнить, что PKZIP происходит из эпохи дискет. Операции считывания содержимого всего zip-архива и записи нового zip-архива могут оказаться чрезвычайно медленными. В обоих случаях возможность удаления файла простым обновлением центрального каталога или добавления файла считыванием существующего центрального каталога с присоединением новых данных и последующей записью обновленного центрального каталога окажется весьма желаемой.

Это было особенно актуально в случаях, когда zip-архив занимал несколько дискет. В 1989 году подобная ситуация была не редкостью. Оказывалось гораздо удобнее обновлять README.TXT в zip-архиве без необходимости перезаписывать несколько дискет.

Представители PKWARE в обсуждении сказали следующее:

Файлы внутри ZIP-архива МОЖНО заменять, добавлять и удалять.

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

Может ли SFX-компонент содержать какие-либо ID?

Следуя вышеприведенной инструкции по созданию SFX-компонента, мы просто подставляем исполняемый код в начало этого файла, а затем корректируем смещения в центральном каталоге.

Предположим, что у SFX-компонента следующий код:

Вот как можно представить SFX-компонент с находящимся в нем zip-файлом:

Теперь внутри SFX-компонента находится zip-файл. Любой ридер, который считывает с начала, увидит этот внутренний zip-файл и даст сбой. Валиден ли данный zip-файл? Спецификация об этом молчит.

Я проверил. Оригинальный PKUNZIP.exe в DOS, Windows Explorer, MacOS Finder, Info-ZIP (UNZIP, включенный в MacOS и Linux), все четко считывают с конца и видят эти файлы уже после SFX-компонента. А вот Keka и 7z видят zip, вложенный в него.

Считать ли это сбоем или плохим zip-файлом?

APPNOTE.TXT ответа не дает. Я считаю, что здесь должна быть ясность, и что это является одним из незаявленных допущений. PKUNZIP сканирует с конца, поэтому такая схема работает, но как именно она работает, в документации не сказано. Проблема того, что данные в SFX-компоненте могут оказаться похожи на zip-файл, не освещается. Аналогичным образом, потоковое считывание скорее всего провалится, если еще не провалилась из-за недочетов, описанных ранее.

Вы можете решить, что это не такая уж проблема, но в сетевом архиве находятся сотни тысяч SFX zip-ов из 1990-х. Попытка считать такие файлы прямым сканером вполне может провалиться.

Может ли zip-комментарий содержать идентификаторы zip?

APPNOTE.TXT наверняка должен явно сообщать, если это невалидно. Пункт 4.3.1 косвенно указывает:

Но что именно это значит? Значит ли это, что байты 0x50 0x4B 0x05 0x06 не могут появиться в комментарии или коде SFX? Значит ли это, что когда вы в первый раз видите их при обратном сканировании, то второе совпадение уже не ищете?

Если вы сканируете с начала и не сталкиваетесь ни с одной из перечисленных ранее проблем, то прямой сканер успешно это считает. С другой стороны, сам PKUNZIP бы не справился.

Что, если смещение до центрального каталога равно 1,347,093,766?

А что значит продуманная структура?

Этот вопрос определенно требует обсуждения, но, если рассмотреть возможность повторить разработку, то кое-что можно определить без сомнений.

Это исключит двусмысленность при обратном считывании.

2.a. Считать последние 12 байтов.

Тогда, по крайней мере, исчезнет проблема сканирования комментария.

3. Внести ясность в том, какие данные могут появиться в компоненте SFX.
Если вам нужна поддержка прямого считывания, то будет логичным утвердить, что SFX-компонент не может содержать какие-либо записи.

Но обеспечить это сложно, разве что специально написать валидатор. Если вы будете просто проверять, исходя из того, может ли ваше приложение считывать zip-файл, то на сегодня для PKZIP, PKUNZIP, info-ZIP, Windows Explorer и MacOS содержимое SFX-компонента безразлично, поэтому для валидации они не годятся. Нужно явно указать в спецификации на необходимость применения именно обратного сканирования, либо же написать валидатор, который отвергает zip-файлы, не допускающие прямого сканирования, и также в спецификации указать причину.

4. Внести ясность в том, может ли central directory расходиться с записями локальных файлов.

5. Внести ясность в том, могут ли между записями появиться случайные данные.

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

Необходима ясность в том, нормально это или нет. Не нужно полагаться на скрытые схемы.

Что же делать? Как все исправить?

End of central directory record должна находиться в конце файла, и последовательность байтов 0x50 0x4B 0x05 0x06 не должна встречаться в комментарии.

Сentral directory руководит содержимым zip-файла, и считать из него можно только те данные, на которые он указывает. Во-первых, причина в том, что содержимое SFX-компонента файла не определено и может содержать zip-записи, которые фактически к zip-файлу не относятся. Во-вторых, возможность добавлять, обновлять или удалять содержимое zip-файла опирается на доступную лишь central directory информацию о том, какие локальные файлы валидны.

Это один способ. Я верю, что в таком случае удалось бы считать сотни миллионов существующих zip-файлов.

С другой стороны, если в PKWARE заявляют, что файлов, имеющих подобные проблемы, не существует, тогда также сработает следующий вариант:

End of central directory record должна находиться в конце файла, и последовательность байтов 0x50 0x4B 0x05 0x06 не должна встречаться в комментарии.

SFX-архив не должен содержать любую из последовательностей id записей, перечисленных в этом документе, так как они могут быть неверно поняты zip-сканерами прямого чтения. Любой файл, не следующий этому правилу, является недействительным zip-архивом.

Надеюсь, что файл APPNOTE.TXT все же обновят, чтобы различные zip-ридеры и zip-генераторы трактовали валидность файлов одинаково.

К сожалению, все говорит в пользу того, что PKWARE не хотят вносить в этом вопросе ясность. Их позиция состоит в том, что zip является неоднозначным форматом. Если вы хотите пользоваться прямым сканированием, то просто не делайте этого для файлов, которые его не поддерживают. Они по-прежнему остаются валидными zip-файлами, и то, что их нельзя таким образом считать, значения не имеет. Вы сами выбираете отказ от их поддержки.

Думаю, эту точку зрения можно понять. Ведь лишь несколько библиотек поддерживают все возможности zip, а может и ни одна. Тем не менее, было бы здорово знать, намеренно ли вы не обрабатываете какой-то файл, или же просто неверно его считываете, и по воле случая иногда получается.

Желание все это осветить возникло у меня в процессе написания JS-библиотеки для распаковки. Их уже существует очень много, но меня интересовали особые возможности, которых в найденных мной вариантах не было. В частности, мне нужно было, чтобы библиотека позволяла считывать из большого архива один файл максимально быстро. Это означало использование обратного сканирования, поиск смещения до нужного файла и его разархивирование. Надеюсь, что и другим моя библиотека пригодится.

Вам может быть весьма интересна эта история ZIP (англ.):

Источник

ZIP (формат файлов)

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

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

Содержание

История

Формат ZIP был первоначально создан Филом Кацем, основателем компании PKWARE, в ответ на правовое преследование компанией Software Enhancement Associates (SEA), защищавшей своё изобретение — формат архивирования ARC.

SEA — небольшая компания, основанная Томом Хендерсоном, его женой Айрин (Irene) и её братом. Формат ARC продавался как shareware и был предназначен для использования пользователями утилиты ARC были доступны для скачивания и изучения.

Кац скопировал ARC и изменил часть кода, написанного на Си, оптимизированным кодом на ассемблере, тем самым сделав программу значительно быстрее. Сначала SEA попыталась лицензировать архиватор PKARC, сделанный Кацем, но тот отказался. Тогда они возбудили иск за нарушение прав правообладателя и выиграли процесс.

Во время урегулирования Кац по-прежнему отказался выплачивать лицензию за PKARC компании SEA, согласившись вместо этого оплатить её расходы на процесс и прекратить продавать PKARC. Затем он продолжил разработку и вскоре представил собственный формат архивации файлов PKZIP, который намного эффективнее сжимал данные, чем ARC. После выпуска PKZIP многие пользователи переметнулись в его лагерь из-за лучшего алгоритма сжатия, приносившего выгоду и во времени, и в размере, а также поскольку Кац сумел успешно убедить, что он «хороший парень», которого «использовала» плохая корпорация.

Термин «ZIP» был предложен другом автора, его можно интерпретировать как «скорость». Тем самым можно было подразумевать, что этот продукт будет быстрее, чем ARC и другие форматы сжатия. По историческим причинам (из-за ограничений на имена файлов под

История версий

У каждой спецификации формата ZIP есть свой собственный номер, который может не совпадать с номерами версий PKZIP (особенно это справедливо для PKZIP 6 и более старших версий). PKWARE постоянно добавляет новые возможности в свой формат, но новая версия формата становится доступной только при выходе следующего старшего выпуска программы PKZIP.