Чому Zip здатний стискати один файл менше, ніж кілька файлів з одним вмістом?

Припустимо, у мене є 10 000 XML-файлів. Тепер припустимо, що я хочу надіслати їх другові. Перш ніж надсилати їх, я хотів би їх стиснути.

Спосіб 1. Не стискайте їх

Результати:

Resulting Size: 62 MB
Percent of initial size: 100%

Спосіб 2: Скопіюйте кожен файл і надішліть йому 10 000 XML-файлів

Команда:

for x in $(ls -1) ;  do   echo $x ; zip "$x.zip" $x ; done

Результати:

Resulting Size: 13 MB
Percent of initial size: 20%

Спосіб 3: Створіть єдиний поштовий індекс, що містить 10 000 файлів xml

Команда:

zip all.zip $(ls -1)

Результати:

Resulting Size: 12 MB
Percent of initial size: 19%

Спосіб 4: Об’єднайте файли в один файл і зафіксуйте його

Команда:

cat *.xml > oneFile.txt ; zip oneFile.zip oneFile.txt

Результати:

Resulting Size: 2 MB
Percent of initial size: 3%

Запитання:

• Чому я отримую такі різко кращі результати, коли я просто стискаю один файл?
• Я сподівався отримати кардинально кращі результати, використовуючи метод 3, ніж метод 2, але це не так. Чому?
• Чи специфічна така поведінка zip? Якщо я спробував використовувати gzip, я отримав би різні результати?

Додаткова інформація:

$ zip --version
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.
Currently maintained by E. Gordon.  Please send bug reports to
the authors using the web page at www.info-zip.org; see README for details.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip,
as of above date; see http://www.info-zip.org/ for other sites.

Compiled with gcc 4.4.4 20100525 (Red Hat 4.4.4-5) for Unix (Linux ELF) on Nov 11 2010.

Zip special compilation options:
    USE_EF_UT_TIME       (store Universal Time)
    SYMLINK_SUPPORT      (symbolic links supported)
    LARGE_FILE_SUPPORT   (can read and write large files on file system)
    ZIP64_SUPPORT        (use Zip64 to store large files in archives)
    UNICODE_SUPPORT      (store and read UTF-8 Unicode paths)
    STORE_UNIX_UIDs_GIDs (store UID/GID sizes/values using new extra field)
    UIDGID_NOT_16BIT     (old Unix 16-bit UID/GID extra field not used)
    [encryption, version 2.91 of 05 Jan 2007] (modified for Zip 3)

Редагувати: метадані

Одна відповідь говорить про те, що різниця полягає в системних метаданих, які зберігаються в zip. Я не думаю, що це може бути так. Для тестування я зробив наступне:

for x in $(seq 10000) ; do touch $x ; done
zip allZip $(ls -1)

Отриманий поштовий індекс становить 1,4 Мб. Це означає, що залишається ~ 10 Мб незрозумілого простору.

Zip обробляє вміст кожного файлу окремо під час стискання. Кожен файл матиме власний стислий потік. Існує підтримка в алгоритмі стиснення (як правило, DEFLATE ) для ідентифікації повторних розділів. Однак у Zip немає підтримки для пошуку надмірності між файлами.

Ось чому так багато додаткового простору, коли вміст знаходиться в декількох файлах: він розміщує один і той же стислий потік у файлі кілька разів.

Стиснення ZIP засноване на повторюваних шаблонах даних, що стискаються, і стискання стає кращим, чим довший файл, оскільки все більше і довші шаблони можна знайти та використовувати.

Спрощено, якщо ви стискаєте один файл, словник, який відображає (короткі) коди на (довші) шаблони, обов'язково міститься у кожному отриманому поштовому файлі; якщо ви накопичуєте один довгий файл, словник "повторно використовується" і стає ще більш ефективним для всього вмісту.

Якщо ваші файли навіть трохи схожі (як завжди текст), повторне використання «словника» стає дуже ефективним, а результат - значно меншим загальним ZIP.

У Zip кожен файл стискається окремо. Навпаки - «суцільне стиснення», тобто файли стискаються разом. 7-zip та Rar за замовчуванням використовують тверду компресію. Gzip і Bzip2 не можуть стискати декілька файлів, тому спочатку використовується Tar, маючи такий же ефект, як і тверде стиснення.

Оскільки файл XML має подібну структуру та, ймовірно, подібний вміст, якщо файли стиснуті разом, стиснення буде вище.

Наприклад, якщо файл містить рядок "<content><element name="і компресор вже виявив, що рядок в іншому файлі, він замінить його невеликим вказівником на попередній збіг, якщо компресор не використовує "тверде стиснення", перше виникнення рядка в файл буде записаний як літерал, який більший.

Zip не просто зберігає вміст файлу, він також зберігає метадані файлів, такі як власний ідентифікатор користувача, дозволи, час створення та модифікації тощо. Якщо у вас є один файл, у вас є один набір метаданих; якщо у вас 10 000 файлів, у вас є 10 000 наборів метаданих.

Опція, пропущена ОП, полягає в тому, щоб зібрати всі файли разом із вимкненим стисненням, а потім зафіксувати отриманий zip з компресією, встановленою на максимум. Це приблизно імітує поведінку стислих архівів * nix .tar.Z, .tar.gz, .tar.bz тощо, дозволяючи стисненню використовувати надмірності через межі файлів (що алгоритм ZIP не може зробити при запуску в одному пропуск). Це дозволяє отримати окремі файли XML пізніше, але максимально стискає. Мінус полягає в тому, що процес вилучення вимагає додаткового кроку, тимчасово використовуючи набагато більше місця на диску, ніж потрібно для звичайного .zip.

Завдяки повсюдності безкоштовних інструментів, таких як 7-Zip, щоб розширити сімейство смол на Windows, насправді немає причин не використовувати .tar.gz або .tar.bz тощо, як це мають Linux, OS X та BSD. рідні інструменти для маніпулювання ними.

Формат стиснення zip зберігає та стискає кожен файл окремо. Це не використовує повторення між файлами, лише в межах файлу.

Об’єднання файлу дозволяє zip використовувати переваги повторень у всіх файлах, що призводить до різкого стиснення.

Наприклад, скажімо, що кожен XML-файл має певний заголовок. Цей заголовок виникає лише один раз у кожному файлі, але повторюється майже однаково у багатьох інших файлах. У способах 2 і 3 блискавка не могла стиснути це, але в методі 4 вона могла.

Поруч із метаданими, про які згадував Майк Скотт, також існує алгоритм стиснення.

Стискаючи купу окремих невеликих файлів, вам доведеться пощастити, що зможете їх стиснути, що просто виходить заповнити один блок стиснення. При стисненні одного монолітного блоку система може просто продовжувати передачу даних до свого алгоритму, ігноруючи «межі» (за відсутністю кращого слова) окремих файлів.

Також відомо, що ASCII має високий коефіцієнт стиснення. плюс xml часто дуже повторюється, що робить метадані великою частиною даних, які не можна так легко стиснути, як вміст xml.

Нарешті, якщо пам'ять слугує правильно, zip використовує щось на зразок кодування словника, що особливо ефективно для файлів ascii і тим більше для XML через їх повторюваності

Пояснення стиснення даних: http://mattmahoney.net/dc/dce.html

Розглянемо цей XML:

<root>
  <element id="1" />
  <element id="2" /> 
  <other id="3" />
  ...
</root>

XML має дуже повторювану структуру, Zip використовує ті повтори, щоб створити словник, у якого шаблон має більше випадків, а потім при стисненні використовує менше біт для зберігання більше повторених шаблонів і більше бітів для зберігання менш повторених шаблонів .

Коли ви об'єднуєте ці файли, вихідний файл (джерело для zip) є великим, але містить значно більше повторених шаблонів, оскільки розподіл нудних структур XML амортизується у великому цілому файлі, що дає можливість ZIP зберегти ці шаблони використовуючи менше бітів.

Тепер, якщо ви об’єднаєте різні файли XML в один файл, навіть коли ці файли мають абсолютно різні імена тегів, алгоритм стиснення знайде найкращий розподіл шаблону по всіх файлах, а не файл за файлом.

Зрештою алгоритм стиснення знайшов найкращий повторний розподіл шаблону.

На додаток до відповіді 7-Zip, є ще один підхід, який не так добре, але варто перевірити, якщо з якихось причин ви не хочете використовувати 7-Zip:

Стисніть zip-файл. Тепер, як правило, zip-файл нестискається, але коли він містить багато однакових файлів, компресор може знайти це надмірність і стиснути його. Зауважте, що я також бачив невеликий приріст, коли працював з великою кількістю файлів без надмірності. Якщо ви дійсно піклуєтеся про розмір, варто спробувати, якщо у вас в папері дуже багато файлів.