Почему мои функции java.util.zip показывают непоследовательное поведение?

Question

У меня есть приложение Java, которое использует библиотеку java.util.zip для сжатия и распаковки файлов.У меня есть zip-файл на сервере (созданный моим приложением), и клиент архивирует некоторые из своих файлов и загружает файл на сервер, но если нет разницы в базовых файлах, я не хочу тратить впустуювремя загрузки.Я подумал, что мог бы вычислить хеш-значения MD5 на стороне клиента и на стороне сервера и посмотреть, одинаковы ли они, но в результате я использую свое приложение для распаковки zip-файла, а затем без изменения каких-либо базовых файлов.файлы, я использую свое приложение для повторного сжатия, но старые и новые zip-файлы имеют разные хэши MD5.Кто-нибудь знает, почему это происходит, и есть ли лучший способ сравнить два архива?Спасибо.

Answer 1

Еще хуже, я думаю:

Выполнение одной и той же zip-операции дважды может привести к двум разным zip-архивам:

> zip some.zip some.txt 
  adding: some.txt (stored 0%)
> zip other.zip some.txt
  adding: some.txt (stored 0%)
> ll
total 24
-rw-r--r--  1 cthies  staff  170 12 Dez 18:01 other.zip
-rw-r--r--  1 cthies  staff    4 12 Dez 18:01 some.txt
-rw-r--r--  1 cthies  staff  170 12 Dez 18:01 some.zip
> md5 *.zip
MD5 (other.zip) = f56d7753c5af78427274d930b9fb8c90
MD5 (some.zip) = e2f0382c4ad31871f62fb559157df8e8

Глядя в двоичные файлы, можно увидеть разницу только в одном месте:

> xxd some.zip > some.xxd
> xxd other.zip > other.xxd
> colordiff *.xxd
3c3
< 0000020: 6d65 2e74 7874 5554 0900 0363 33e6 4e78  me.txtUT...c3.Nx
---
> 0000020: 6d65 2e74 7874 5554 0900 0363 33e6 4e64  me.txtUT...c3.Nd

Я думаю (в зависимости от самого zip-приложения) текущее системное время может / будет вовлечено. Таким образом, любая zip-операция на тех же самых источниках может (!) Быть уникальной, и поэтому контрольные суммы нельзя считать равными.

Не зависящие от времени инструменты, которые я нашел: tar , 7z . (обе командной строки) То есть tar и 7z воспроизводит архивы с одинаковыми контрольными суммами (md5).

(протестировано на OSX 10.6.8 с утилитой zip из командной строки)

Answer 2

1) Проверьте метки времени на файлах. Файлы, созданные при распаковке, могут иметь другую дату последнего изменения и / или дату создания. Эти метаданные файла могут быть использованы для создания хэша.

2) Используете ли вы одну и ту же ОС в обеих системах? Если операционные системы отличаются, они могут использовать другую кодировку символов.

3) Можете ли вы различать файлы zip? Разные MD5-хэши должны означать разные данные. Это будет грязно, но вы можете получить некоторые подсказки, сравнивая необработанные файлы.

Answer 3

Просто дикий выстрел в темноте - две ли файловые системы, по которым вы вычисляете значения хеш-функции, по-разному обрабатываются?

То есть, является ли одна из них Windows, которая обрабатывает имена файлов ABC.CLASS и abc.class как идентичные, и одна из версий Unix, которая обрабатывает ABC.CLASS и abc.class как разные?

Просто дикая догадка ...

РЕДАКТИРОВАТЬ: Вы также можете посмотреть на встроенные символы разделителя каталогов / \. или: внутри почтового файла.

Answer 4

Невозможно сравнить полученные zip-файлы из разных zip-программ и ожидать, что они будут одинаковыми, даже если перед сжатием использовались одинаковые файлы.

Не гарантируется, что архивирование файла будет детерминированным между двумя различными реализациями zip-кодировок. Zip работает, заменяя повторяющиеся разделы данных тем, что составляет ключ поиска. Два разных алгоритма могут по-разному определять словарь (набор повторяющихся данных), чтобы оптимизировать уровни сжатия. Тем не менее, обе реализации могут создавать допустимые zip-файлы, которые при разархивировании приводят к одному и тому же файлу.

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

РЕДАКТИРОВАТЬ: Вот почему вы видите различные настройки уровня сжатия в реализации Java алгоритма Deflate http://download.oracle.com/javase/1.5.0/docs/api/java/util/zip/Deflater.html

Answer 5

Вы пишете новый файл, а не тот же файл, поэтому MD5 изменится, как я понимаю, от таких потоков, как этот: MD5 Hash Not Reversible