Почему ZIP почти не уменьшает фотографии и видео
JPEG и сжатое видео обычно мало уменьшаются при упаковке в ZIP.
Сравнение двух файлов покажет, откуда берётся разница. А простой расчёт поможет решить, стоит ли ждать создания архива ради более быстрой отправки или он нужен только для удобной упаковки.
В статье вы узнаете:
Один файл уменьшился в сто раз, другой стал больше
Возьмём два файла. Первый представляет собой обычный текст: английская строка Meeting at five. Bring a notebook. с переводом строки повторена тысячу раз. Второй содержит уже готовую иллюстрацию в WebP, одном из форматов изображений.
Текст занимает 35 000 байт. После упаковки в ZIP получилось 300 байт, то есть меньше исходника более чем в сто раз. Но это нарочно удобная задача для архиватора: тысяча одинаковых строк. Обычная переписка или школьное сочинение не обязаны сжиматься так же сильно.
С иллюстрацией вышло наоборот. Исходный файл занимал 41 408 байт, архив стал занимать 41 562 байта. Прибавилось 154 байта. Архиватор создал новый файл, а экономии нет.
Оба архива распаковали и проверили, что файлы полностью совпадают с исходными. Значит, размер упаковки изменился, но ни буква в тексте, ни данные изображения не потерялись. Именно это означает «сжатие без потерь»: после распаковки получается тот же файл, а не похожий на него.
Эти числа относятся к двум конкретным файлам и одному способу создания ZIP. На другом изображении или с другой программой результат будет иным. Полезен здесь сам контраст: архивирование сработало в обоих случаях, но уменьшило размер только в одном.
Повтор можно записать короче
Если сообщение содержит слово «привет» сто раз подряд, необязательно каждый раз выписывать его заново. Можно записать слово один раз и дать короткую инструкцию повторить его. Получатель восстановит все сто слов, хотя переслать пришлось гораздо меньше знаков.
Распространённый способ сжатия внутри ZIP работает с похожей идеей. Он ищет повторяющиеся последовательности байтов, то есть кусочки записи файла, и может заменять их короткими ссылками на уже встреченное. При распаковке программа разворачивает ссылки обратно. Это часть метода Deflate, описанного в RFC 1951.
Пример со словом объясняет принцип, а не буквальное устройство архива. Архиватору не нужно понимать русский язык, узнавать лица на фотографии или следить за сюжетом видео. Он работает с записью данных.
У фотографии в JPEG эта запись уже сжата при сохранении. У обычного видео значительную часть работы тоже выполнила программа, создавшая видеофайл. Понятные универсальному архиватору повторы часто уже сокращены, поэтому повторная упаковка мало помогает.
Уже сжатый файл не обязательно несжимаем. У исходного формата могут быть неудачные настройки, а специализированная программа иногда находит дополнительный способ сохранить те же данные короче. Поэтому правильный вывод звучит так: обычный ZIP часто мало выигрывает на JPEG и сжатом видео, а результат проверяют по полученному размеру.
У архива есть собственная упаковка
Рядом с содержимым файлов ZIP хранит их имена, сведения для распаковки и список того, что находится внутри. Благодаря этому можно передать несколько папок одним файлом, а затем восстановить их расположение.
Эти служебные записи тоже занимают место. Если содержимое удалось уменьшить сильно, на общем результате упаковку почти не видно. Если сэкономить почти нечего, дополнительные байты оказываются больше выигрыша. Поэтому архив с маленьким текстовым файлом или уже сжатой картинкой может быть крупнее исходника. Это само по себе не признак ошибки.
Формат ZIP допускает разные способы сжатия. Deflate лишь один из них, хотя и распространённый. Можно даже сохранить отдельный файл без сжатия: он всё равно останется частью нормального ZIP-архива.
По той же причине обычно мало смысла снова архивировать готовый ZIP только ради размера. Повторная упаковка добавляет ещё один слой служебных данных, а полезной работы для сжатия часто почти не остаётся. Для пробы выберите несколько файлов, создайте из них ZIP и упакуйте полученный архив ещё раз. Сравнение двух размеров покажет, помогла ли вторая попытка.
ZIP не делает фотографию менее чёткой
Если JPEG-фотографию упаковать в обычный ZIP без потерь, а потом распаковать, получится исходный JPEG-файл. Архиватор не должен менять разрешение, размывать волосы или упрощать рисунок травы. Если потери уже возникли при прежнем сохранении фотографии, ZIP их не исправит, но и новых не добавит.
Другая операция начинается, когда редактору говорят «сохранить JPEG с меньшим качеством» или просят уменьшить видео. Программа может заново обработать изображение, отбросить часть деталей, изменить разрешение или настройки видеозаписи. Файл часто становится заметно меньше, но точное восстановление прежних данных уже не обещано.
Поэтому две кнопки с похожим словом «сжать» могут решать разные задачи. Архиватор старается записать исходник короче и вернуть его целиком. Экспорт с потерями создаёт другую версию изображения или ролика. Иногда такая версия вполне подходит для просмотра на телефоне, но выдавать её за неизменённый оригинал нельзя.
При передаче через мессенджер есть ещё одна развилка: отправить снимок как фотографию или как файл. Разницу и проверку полученного оригинала отдельно объясняет статья о том, почему мессенджер ухудшает качество видео. Сам факт наличия ZIP не сообщает, что программа до архивирования сделала с исходником.
Пять сэкономленных мегабайт могут не окупить ожидание
Представим папку изображений размером 500 МБ. Готовый архив весит 495 МБ. Выигрыш есть, но стоит ли ради него ждать перед отправкой?
Пусть фактическая скорость отправки держится на уровне 10 Мбит/с. В одном байте восемь бит, поэтому это 1,25 МБ в секунду. Делим 500 МБ на 1,25 и получаем 400 секунд, или 6 минут 40 секунд. Для 495 МБ потребуется 396 секунд, или 6 минут 36 секунд. Архив сэкономит всего четыре секунды передачи.
Если его создание заняло 30 секунд, а загрузка началась только после этого, весь путь занял 7 минут 6 секунд. Отправка исходной папки при тех же условиях закончилась бы на 26 секунд раньше. Здесь ещё не учтено время распаковки у получателя.
Для своего случая откройте калькулятор времени передачи файла. Сначала укажите исходный размер, затем фактический размер готового архива. Возьмите скорость отправки из приложения, которым передаёте файлы. Выберите «Без запаса, использовать 100%»: тогда калькулятор использует всю введённую скорость, а не снизит её для осторожного прогноза.
Калькулятор не предсказывает, насколько удачно сожмутся фотографии, и не включает создание архива. Он сравнивает передачу двух уже известных размеров. В свойствах файлов смотрите именно «Размер», а не «Размер на диске»: второй показатель зависит ещё и от того, как накопитель размещает данные.
Пример предполагает одинаковую скорость и последовательные действия: сначала упаковка, потом загрузка. При передаче тысяч мелких файлов архив может ускорить работу ещё и потому, что сервису проще обработать один файл вместо множества. Но это уже преимущество упаковки, а не доказательство хорошего сжатия.
Если ZIP почти не уменьшил папку, он всё ещё может быть полезен: получатель скачает один файл со всеми вложенными папками. Делайте архив ради этого удобства. А если цель только в скорости отправки, сначала сравните реальные размеры и время подготовки. Иногда быстрее просто начать загрузку.
Есть что добавить?
Напишите своё мнение, комментарий или предложение.