сколько раз файл может быть сжат?

<p>я думал о сжатии, и кажется, что должно быть какое-то ограничение на сжатие, которое может быть применено к нему, иначе это будет один байт.</p><p>поэтому мой вопрос: сколько раз я могу сжать файл раньше:</p><ul> <li>это не становится меньше?</li> <li>файл становится поврежденным?</li> </ul><p>эти две точки одинаковы или различны?</p><p>где появляется точка убывающей отдачи?</p><p>как можно найти эти точки?</p><p>я не говорю о каком-то конкретном алгоритме или конкретном файле, просто в общем.</p>

<p>для сжатия без потерь единственный способ узнать, сколько раз вы можете получить повторное сжатие файла, - это попытаться. это будет зависеть от алгоритма сжатия и файла, который вы сжимаете.</p><p>два файла никогда не могут сжиматься в один и тот же вывод, поэтому вы не можете перейти к одному байту. как один байт может представлять все файлы, которые вы можете распаковать?</p><p>причина того, что второе сжатие иногда работает, состоит в том, что алгоритм сжатия не может сделать всевозможное идеальное сжатие. есть компромисс между работой, которую она должна сделать, и временем, которое требуется, чтобы сделать это. ваш файл изменяется со всех данных на комбинацию данных о ваших данных и самих данных.</p><p><strong> пример </strong></p><p>возьмем в качестве примера кодирование по длине прогона (возможно, простейшее полезное сжатие).</p><p>04 04 04 04 43 43 43 43 51 52 <strong> <em> 11 байт </em> </strong></p><p>эта серия байтов может быть сжата как:</p><p>[4] 04 [4] 43 [-2] 51 52 <strong> <em> 7 байт (я ставлю метаданные в скобках) </em> </strong></p><p>где положительное число в скобках - это число повторений, а отрицательное число в скобках - это команда, которая выдает следующие символы -n, когда они найдены.</p><p>в этом случае мы можем попробовать еще одно сжатие:</p><p>[3] 04 [-4] 43 fe 51 52 <strong> <em> 7 байт (например, ваш -2 рассматривается как данные дополнения двух) </em> </strong></p><p>мы ничего не получили, и мы начнем расти на следующей итерации:</p><p>[-7] 03 04 fc 43 fe 51 52 <strong> <em> 8 байт </em> </strong></p><p>некоторое время мы будем увеличиваться на один байт за итерацию, но на самом деле все будет хуже. один байт может содержать только отрицательные числа до -128. мы начнем увеличиваться на два байта, когда длина файла превысит 128 байтов. рост будет еще хуже, поскольку файл становится больше.</p><p>против программы сжатия дует встречный ветер - метаданные. а также, для <em> реальных </em> компрессоров, заголовок прикрепляется к началу файла. это означает, что в конечном итоге файл начнет расти с каждым дополнительным сжатием.</p><hr><p>rle является отправной точкой. если вы хотите узнать больше, посмотрите на <a href="http://en.wikipedia.org/wiki/lz77\_and\_lz78">lz77</a> (который смотрит в файл, чтобы найти шаблоны) и <a href="http://en.wikipedia.org/wiki/lz77\_and\_lz78">lz78</a> (который создает словарь). компрессоры, такие как zip, часто пробуют несколько алгоритмов и используют лучший.</p><p>вот несколько случаев, когда я могу вспомнить, где работало многократное сжатие.</p><ol> <li>я работал в журнале amiga, который поставлялся с диском. естественно, мы упаковали диск в жабры. один из инструментов, которые мы использовали, позволяет упаковать исполняемый файл так, чтобы при запуске он распаковывался и запускался сам. поскольку алгоритм распаковки должен быть в каждом исполняемом файле, он должен быть небольшим и простым. мы часто получали дополнительную прибыль, сжимая дважды. декомпрессия была сделана в ram. поскольку чтение дискеты было медленным, мы также часто получали увеличение скорости!</li> <li>microsoft поддерживает сжатие rle для файлов bmp. также многие текстовые процессоры делали кодирование rle. файлы rle почти всегда значительно сжимаются лучшим компрессором.</li> <li>во многих играх, над которыми я работал, использовался небольшой, быстрый декомпрессор lz77. если вы сжимаете большой прямоугольник пикселей (особенно если у него много фонового цвета или если это анимация), вы можете очень часто сжимать дважды с хорошими результатами. (причина? у вас есть только столько битов, чтобы указать расстояние и длину просмотра, поэтому один большой повторный шаблон кодируется несколькими частями, и эти фрагменты легко сжимаются.)</li> </ol>

<p>обычно предел - одно сжатие. некоторые алгоритмы приводят к более высокой степени сжатия, и использование плохого алгоритма, сопровождаемого хорошим алгоритмом, часто приводит к улучшениям. но использование хорошего алгоритма - это, в первую очередь, правильное решение.</p><p>существует теоретический предел того, насколько данный набор данных может быть сжат. чтобы узнать больше об этом вам придется изучить <a href="http://en.wikipedia.org/wiki/information\_theory">теория информации</a> .</p>

<p>в целом, для большинства алгоритмов сжатие более одного раза бесполезно. хотя есть особый случай.</p><p>если у вас есть большое количество дубликатов файлов, формат zip будет сжать каждый файл независимо, а затем вы можете сжать первый файл zip, чтобы удалить дублирующуюся информацию zip. в частности, для 7 идентичных файлов excel размером 108 кб их сжатие с 7-zip приводит к архиву размером 120 кб. повторное сжатие приводит к архиву 18 кб. пройдя мимо, вы получаете убывающую отдачу.</p>

<p>предположим, у нас есть файл длиной n бит и мы хотим сжать его без потерь, чтобы мы могли восстановить исходный файл. есть 2 ^ n возможных файлов длиной n битов, поэтому наш алгоритм сжатия должен заменить один из этих файлов на один из 2 ^ n возможных других. однако мы не можем выразить 2 ^ n разных файлов менее чем за n бит.</p><p>поэтому, если мы можем взять некоторые файлы и сжать их, у нас должны быть файлы такой длины при сжатии, чтобы сбалансировать те, которые укорачиваются.</p><p>это означает, что алгоритм сжатия может сжимать только определенные файлы, а на самом деле он должен удлинять некоторые. это означает, что в среднем сжатие случайного файла не может сократить его, но может удлинить.</p><p>практические алгоритмы сжатия работают, потому что мы обычно не используем случайные файлы. большинство файлов, которые мы используем, имеют некоторую структуру или другие свойства, будь то текстовые или программные исполняемые файлы или значимые изображения. используя хороший алгоритм сжатия, мы можем значительно сократить файлы тех типов, которые мы обычно используем.</p><p>однако сжатый файл не относится к таким типам. если алгоритм сжатия хорош, большая часть структуры и избыточности были вытеснены, а то, что осталось, выглядит как случайность.</p><p>ни один алгоритм сжатия, как мы видели, не может эффективно сжимать случайный файл, и это относится и к случайному файлу. следовательно, попытка повторно сжать сжатый файл не приведет к его значительному сокращению и может даже несколько его удлинить.</p><p>таким образом, обычное количество раз, когда алгоритм сжатия может быть с пользой запущен, равно единице.</p><p>коррупция происходит только тогда, когда мы говорим о сжатии с потерями. например, вы не можете восстановить изображение точно из файла jpeg. это означает, что компрессор jpeg может надежно сократить файл изображения, но только за счет невозможности его точного восстановления. мы часто готовы сделать это для изображений, но не для текста и, в частности, не для исполняемых файлов.</p><p>в этом случае нет стадии, на которой начинается коррупция. он начинается, когда вы начинаете сжимать его, и ухудшается, когда вы сжимаете его больше. вот почему хорошие программы обработки изображений позволяют вам указать, какое сжатие вы хотите при создании jpeg: чтобы вы могли сбалансировать качество изображения с размером файла. вы находите точку остановки, рассматривая стоимость размера файла (которая в целом важнее для сетевых подключений, чем хранилища) в сравнении с затратами на снижение качества. там нет очевидного правильного ответа.</p>

<p>обычно сжатие один раз достаточно хорошо, если алгоритм хорош.<br> <sub>фактически, многократное сжатие может привести к увеличению размера</sub></p><p>ваши две точки разные.</p><ul> <li>сжатие выполняется многократно и достигается <strong> без улучшения уменьшения размера </strong><br> является ожидаемым теоретическим условием</li> <li>повторное сжатие <strong> вызывает повреждение </strong><br> может быть ошибкой в реализации (или, возможно, самого алгоритма)</li> </ul><p>теперь давайте посмотрим на некоторые исключения или варианты,</p><ul> <li><strong> шифрование </strong> может быть <strong> применено повторно </strong> без уменьшения размера<br> (фактически в разы увеличивается в размерах) <strong> с целью повышения безопасности </strong></li> <li><strong> изображения, видео или аудио файлы </strong> все больше сжимаются<br> <strong> потеряет данные </strong> (в некотором смысле фактически "поврежден")</li> </ul>

<p>вы можете сжать бесконечное количество раз. тем не менее, второе и последующее сжатие, как правило, будут производить только файл, размер которого больше предыдущего. так что нет смысла сжимать более одного раза.</p>

<p>вы можете сжать файл столько раз, сколько захотите. но для большинства алгоритмов сжатия результирующее сжатие со второго раза будет незначительным.</p>

<blockquote> <p>сколько раз я могу сжать файл, прежде чем он станет меньше?</p> </blockquote><p>в общем, <strong>даже не один</strong>. какой бы алгоритм сжатия вы ни использовали, всегда должен быть <em> </em> файл, который вообще не сжимается, иначе вы могли бы <em> всегда </em> сжимайте несколько раз, пока не достигнете 1 байта, по тому же аргументу.</p><blockquote> <p>сколько раз я могу сжать файл, прежде чем он станет поврежденным?</p> </blockquote><p>если программа, которую вы используете для сжатия файла, выполняет свою работу, файл никогда не будет поврежден (конечно, я думаю о <em> сжатии без потерь </em>).</p>

<p>сжатие (я думаю, без потерь) в основном означает выражение чего-то более кратким. например</p><pre><code>111111111111111 </code></pre><p>может быть более кратко выражено как</p><pre><code>15 x '1' </code></pre><p>это называется длиной кодирования. другой метод, который может использовать компьютер, - найти шаблон, который регулярно повторяется в файле.</p><p>ясно, что есть предел того, насколько эти методы могут быть использованы, например, кодирование длин серий не будет влиять на</p><pre><code>15 x '1' </code></pre><p>так как нет повторяющихся паттернов. точно так же, если методы замены шаблона преобразуют длинные шаблоны в 3-х символьные, повторное применение будет иметь небольшой эффект, поскольку единственные оставшиеся повторяющиеся шаблоны будут иметь длину 3 или короче. обычно применение сжатия к уже сжатому файлу делает его немного больше из-за различных накладных расходов. применение хорошего сжатия к плохо сжатому файлу обычно менее эффективно, чем применение только хорошего сжатия.</p>

<p>вот окончательный алгоритм сжатия (в python), который при многократном использовании сжимает любую строку цифр до размера 0 (читателю оставлено в качестве упражнения, как применить его к строке байтов).</p><pre><code> def compress(digitstring): if digitstring=="": raise "already as small as possible" currentlen=len(digitstring) if digitstring=="0"*currentlen: return "9"*(currentlen-1) n=str(long(digitstring)-1); #convert to number and decrement newlen=len(n); return ("0"*(currentlen-newlen))+n; # add zeros to keep same length #test it x="12"; while not x=="": print x; x=compress(x) </code></pre><p>программа выводит 12 11 10 09 08 07 06 05 04 03 02 01 00 9 8 7 6 5 4 3 2 1 0, затем пустую строку. он не сжимает строку при каждом проходе, но с достаточным количеством проходов сжимает любую строку цифр до строки нулевой длины. обязательно запишите, сколько раз вы отправляли его через компрессор, иначе вы не сможете его вернуть.</p>

<p>это очень хороший вопрос. вы можете посмотреть в файл с другой точки зрения. может быть, вы априори знаете, что этот файл содержит арифметические серии. давайте рассмотрим его как поток данных "байтов", "символов" или "сэмплов".</p><p>некоторые ответы могут дать вам "теорию информации" и "математическую статистику". пожалуйста, проверьте монографию этих исследователей для полного понимания:</p><p> <a href="https://en.wikipedia.org/wiki/andrey\_kolmogorov">а. колмогоров</a> </p><p> <a href="https://en.wikipedia.org/wiki/solomon\_kullback">с. куллбек</a> </p><p> <a href="https://en.wikipedia.org/wiki/claude\_shannon">с. шеннон</a> </p><p> <a href="https://en.wikipedia.org/wiki/norbert\_wiener">н. винер</a> </p><p>одним из основных понятий в теории информации является <a href="http://mathworld.wolfram.com/entropy.html">энтропия</a> . если у вас есть поток "байтов" .... энтропия этих байтов не зависит от значений ваших "байтов" или "отсчетов" ... если был определен только частотами, с которых байты получают разные значения. максимальная энтропия имеет место быть для полного случайного потока данных. минимальная энтропия, равная нулю, имеет место для случая, когда ваши "байты" имеют одинаковое значение.</p><blockquote> <p>это не становится меньше?</p> </blockquote><p>таким образом, энтропия - это минимальное количество бит на ваш "байт", которое необходимо использовать при записи информации на диск. конечно, это так, если вы используете алгоритм бога. реальные алгоритмы сжатия без потерь в эвристике не таковы.</p><blockquote> <p>файл становится поврежденным?</p> </blockquote><p>я не понимаю смысла вопроса. вы не можете записывать биты на диск, и вы будете записывать поврежденный файл на диск размером 0 бит. конечно, он поврежден, но его размер равен нулю.</p>

<p>пример более продвинутой техники сжатия, использующей "двойную таблицу или кросс-матрицу", также исключает в алгоритме лишние символы unnessacry</p><p>[предыдущий пример] возьмем в качестве примера кодировку длины прогона (возможно, самое простое полезное сжатие).</p><p>04 04 04 04 43 43 43 43 51 52 11 байт</p><p>эта серия байтов может быть сжата как:</p><p>[4] 04 [4] 43 [-2] 51 52 7 байт (я помещаю метаданные в скобки)</p><p>[вращается] 04.43.51.52 значения 4.4. ** - 2 сжатие</p><p>дальнейшее сжатие с использованием дополнительных символов в качестве замещающих значений</p><p>04.a.b.c значения 4.4. ** - 2 сжатие</p>

<p>в теории, мы никогда не узнаем, это бесконечная вещь:</p><blockquote> <p>в информатике и математике термин теорема о полной занятости использовался для обозначения теоремы, показывающей, что ни один алгоритм не может оптимально выполнить определенную задачу, выполняемую некоторым классом специалистов. название возникает из-за того, что такая теорема гарантирует, что есть бесконечные возможности для открытия новых методов, чтобы улучшить способ, по крайней мере, какую-то конкретную задачу. например, теорема о полной занятости для авторов компиляторов гласит, что не существует такого понятия, как доказуемо совершенный компилятор, оптимизирующий размер, поскольку такое доказательство для компилятора должно было бы обнаруживать не завершающиеся вычисления и сводить их к бесконечной одной инструкции петля. <strong> таким образом, существование доказуемо совершенного оптимизирующего размер компилятора означало бы решение проблемы остановки, которая не может существовать </strong>, делая само доказательство неразрешимой проблемой ,.</p> </blockquote><p> <a href="http://en.wikipedia.org/wiki/full\_employment\_theorem">(источник)</a> </p>