DeflateStream сжимает / распаковывает несоответствие

Question

У меня есть следующие данные из файла Photoshop, который использует сжатие zip (RFC1951):

250, 255, 159, 1, 47, 248, 63, 42, 63, 172, 229, 1, 2, 12, 0, 209, 255, 31, 225

Который распаковывает к следующему, x16:

255, 255, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

Повторное сжатие это дает мне:

251, 255, 159, 1, 47, 248, 63, 42, 63, 172, 229, 1

Почему это не то же самое, что исходный ввод?

(первоначально размещено в codeplex, но не получило ответов: http://dotnetzip.codeplex.com/discussions/406943)

Answer 1

Во-первых, чтобы получить правильную терминологию, RFC 1951 - это формат deflate (которым являются ваши данные), а не "сжатие zip". zip может использовать deflate, но затем данные deflate оборачиваются заголовками zip, трейлерами и каталогом.

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

Для вашего конкретного примера, первый компрессор добавил несколько посторонних пустых блоков (два из них). Вот и спускай поток разобрали

static
literal 255 255 0
match 29 1
literal 255
match 258 32
match 221 32
end
!
static
end
!
last
static
end

Второй компрессор не включал в себя посторонние пустые блоки:

last
static
literal 255 255 0
match 29 1
literal 255
match 258 32
match 221 32
end