Чому 7zipped файл більший за необроблений файл? [дублікат]


37

Можливий повтор:
Чому ZIP Compression нічого не стискає?

Я спробував 7zipping an .exe файл, але він фактично став більшим.

введіть тут опис зображення

Це очікуваний результат?


3
Так, це очікуваний результат. Чому? Тому що коли щось вже стиснене (= використовуючи менший можливий простір), його не можна стиснути далі.
woliveirajr

4
Просто додати до всіх інших - оскільки цей EXE-файл спеціально є інсталятором, більшість його вмісту, ймовірно, є архівом zip або cab. Ви не отримаєте однакових результатів із звичайного файлу EXE (але більшість звичайних EXE-файлів не буде 145 мегабайт)
Random832

1
Пояснення лише з використанням базової логіки: Стиснення знаходить для необробленого файлу UNIQUE заархівований файл, а для zipped - файл UNIQUE raw (нестиснений) оригінальний файл. Уявіть, що у вас є 8-бітні файли, і хочете їх стиснути в 5-бітні файли. Є 256 унікальних 8-бітних файлів, але лише 32 унікальних 5-бітових файлів (!). Тому деякі 8-бітні файли повинні бути стиснуті в той самий 5-бітний файл (!). І якщо два різні сирі файли стиснуті в один ZIP-файл, який ви хочете отримати після декомпресії? Для будь-якого методу блискавки, якщо існують файли, які зменшуються після блискавки, повинні існувати файли, які стають більшими (!)
Іван Кукір,

Відповіді:


78

Це зводиться до поняття, яке називається ентропія . Дивіться Вікіпедію .

Основна ідея полягає в тому, що якби існувала операція стиснення, яка завжди могла б зменшити файл, то логіка диктує, що зазначена операція стиснення зможе зменшити будь-який файл до 0 байт і все-таки зберегти всі дані. Але це абсурдно , адже ми знаємо, що 0 байтів взагалі не можуть передати будь-яку інформацію. Тож ми тільки що довели, що не може існувати алгоритм стиснення, який завжди робить його введення меншим, оскільки якби це було так, будь-яка інформація могла б зберігатися в 0 байтах, але 0 байт означає відсутність інформації, тож ви можете ' t одночасно не мають інформації і всієї інформації. Значить, це абсурд.

Завдяки цій теоретичній концепції кожна програма стиснення, яку ви коли-небудь використовуєте, збільшить розмір (або в кращому випадку - підтримує однаковий розмір) деякого вводу. Тобто, для будь-якого алгоритму стиснення, який ви розробляєте або використовуєте, будуть певні входи, які вийдуть меншими, а деякі - ні.

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

Наприклад, якщо у вас був текстовий файл розміром 100 Мб і стискали його за допомогою звичайного алгоритму Zip, він може стискатися до 50 Мб. Якщо потім стиснути Zip-файл за допомогою LZMA2, ви можете зменшити його до 40 або 45 Мб, оскільки LZMA має високий коефіцієнт стиснення для більшості стисливих даних, ніж Zip. Тому, очевидно, він може також стискати дані Zip, оскільки Zip повністю не висмоктує всю ентропію з них. Але якщо ви повністю усунете контейнер Zip, можливо, ви зможете отримати його ще менше, стиснувши сирий текст за допомогою LZMA2, потенційно отримавши щось на порядку 30 - 35 Мб (це лише "повітряні номери" для ілюстрації концепції) .

У випадку цього бінарного файлу, який ви намагаєтесь стиснути, він більший, оскільки формат файлу 7-Zip повинен створити власну внутрішню структуру та упакувати дані вже стислих виконуваних даних у формат 7-Zip. Тут містяться такі речі, як словник, заголовок файлу тощо. Ці додаткові дані, як правило, більше ніж компенсуються економією від стиснення самих даних, але виявляється, що виконуваний файл, який ви намагаєтесь стиснути, вже стиснутий певною формою LZMA; інакше, швидше за все, зменшиться розмір виконуваного файлу або дуже незначно збільшить його, а не збільшить його на 2 Мб (що багато).


btw Найважливіша частина відповіді на це питання знаходиться в самому кінці: "Це містить такі речі, як словник, заголовок файлу тощо. Ці додаткові дані, як правило, більше ніж компенсуються економією від стиснення самих даних, але це виявляється, що виконуваний файл, який ви намагаєтесь стиснути, вже стиснутий якоюсь формою LZMA "
jhocking

6
@jhocking: Ні, найважливіша частина - це середина: "Кожна програма стиснення, яку ви коли-небудь використовуєте, збільшить розмір ... деякого вводу". У файловому форматі 7zip є словник / file-header / тощо, але навіть якщо 7zip використовував алгоритм, який не мав жодної з цих речей, ми все одно гарантуємо, що деякі (насправді більшість) входи матимуть вихідні дані, які є як-великі-чи-більші, ніж самі входи. Це основний факт теорії інформації і не має нічого спільного з файловими заголовками.
BlueRaja - Danny Pflughoeft

2
@Mehrdad Впевнений: Просто напишіть алгоритм "стиснення", який завжди повертає початковий вхід. Там; зроблено. : P ... Окрім цього, ні - будь-який алгоритм стиснення, який є алгоритмом взагалі, матиме деякі метадані, навіть якщо це лише один біт на початку файлу, який вказує, чи стискається файл чи ні (0 == нестиснений, 1 == стислий). Якщо ви збираєтесь змінювати вміст файлу НА ВСІХ , вам потрібні деякі метадані. І якщо ви змінюєте вміст, ви збільшите кілька входів.
allquixotic

1
Однак якщо у вашому запитанні було "Чи існує якийсь алгоритм стиснення, який не збільшує довжину введення за межі фіксованої кількості метаданих", відповідь така: я не знаю, але теоретично це можна зробити. Насправді легко. Все , що вам потрібно зробити , це розробити формат контейнера , який може або містити вихідний файл, або потік стислих даних. Потім, коли ви створюєте архів, спробуйте стиснути: якщо стислий розмір більший за вхідний, просто зберігайте оригінальний вхід і запакуйте метадані спереду. Розмір файлу збільшиться, але якщо метадані невеликі (продовження)
allquixotic

2
@Mehrdad: "Чи існує алгоритм стиснення (однак поганий), який не збільшує довжину будь-якого вводу? " - Відповідь - ні. Є 2^(n+1)-1можливі повідомлення розміру N-біти або менше. Наш алгоритм повинен відображати кожен з них до унікального результату. Якщо навіть один із них відображається на значення з меншою кількістю бітів, інше значення обов'язково має бути відображене на одне з більшою кількістю.
BlueRaja - Danny Pflughoeft

7

Базові алгоритми стиснення, що використовуються в 7z, не мають втрат . Це означає, що ви можете ітеративно стискати-розпаковувати файл багато разів. Крім того, після кожної ітерації файл залишатиметься точно однаковим.

На жаль, не можна очікувати, що алгоритм стиснення без втрат застосовується багато разів, завжди з позитивним результатом. Існує сувора межа, яку вона не може перейти. Приблизно цей кордон залежить від того, наскільки тісно послідовність введення об'єднує випадкові дані. Перш за все, алгоритми без втрат використовуються для стиснення файлів, передачі HTML в Інтернеті, резервного копіювання та інших операцій, які передбачають, що вихідний файл буде декомпресований в точно такий же вихідний вхідний файл.

На відміну від стиснення без втрат , ви завжди можете очікувати зменшення розміру файлу після стиснення за допомогою втрачених (або втрачених) алгоритмів стиснення . Нижня сторона полягає в тому, що ви не можете точно відновити оригінальний файл після однієї компресії-декомпресії ітерації. Ці алгоритми найвідоміші для передачі та зберігання аудіо / відео / зображення.

bzip2 , LZMA , LZMA2 та інші алгоритми, які використовуються у форматі 7z , без втрат . Тому буде межа, після якої вона вже не може стискатися. Крім цього, виконувані зображення (.exe) - це зазвичай дуже стислі файли. 7zip як і багато інших інструментів стиснення, вбудовує деякі метадані, які насправді можуть збільшити вихідний файл.

Мозок тизера: що робити, якщо у нас був алгоритм без втрат, який завжди може зменшити розмір файлу?

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


5
Доведення через зараження. Гіпотеза: Припустимо, що завжди можна стиснути файл за допомогою алгоритму без втрат. Крок 1. Одинарне стиснення робить вихідний файл меншим хоча б на один біт. Якщо так, то після ряду ітерацій ми закінчимось файлом, який містить лише два біти. Крок 2 Наступна ітерація робить файл розміром 1 біт. Крок 3 Але алгоритми стиснення без втрат, а це означає, що дозволена лише одна дійсна декомпресія. Очевидно, що ви не можете відновити 2 оригінальних біта з 1 стисненого біта - вам доведеться здогадатися. Останній пункт порушує гіпотезу.
олексій

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

@jeteon Я не впевнений, що ти намагаєшся сказати.
олексій

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

@jeteon о, я бачу. Так, має сенс.
олексій

6

Якщо оригінальний виконуваний файл вже був стиснутий (або містив сильно стиснуті дані або дані, що не стискаються), то стиснення його збільшить розмір.


2

Більшість алгоритмів стиснення використовують те, що називається символьною таблицею, в основному це песики файлу, який він використовує як елементи, які МОЖЕ стиснути. Це, звичайно, створює певні накладні витрати у файлі, але зазвичай призводить до набагато менших файлів.

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


0

стиснення ідеї:

програмне забезпечення для стиснення створює список файлів і виключає повторюваний вміст.

стискаючи вже стиснуті файли, ви можете отримати стиснуті файли більше оригіналу.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.