распаковка zlib в Python

Хорошо, извините за мой последний пост, у меня не было всего. И я не могу редактировать свой пост, потому что не использовал OpenID. В любом случае, вот некоторые данные:

1) Отслеживание декомпрессии:

Traceback (most recent call last):
  File "<my file>", line 5, in <module>
    zlib.decompress(data)
zlib.error: Error -5 while decompressing data

2) Код сжатия:

#here you can assume the data is the data to be compressed/stored
data = encrypt(zlib.compress(data,9)) #a short wrapper around PyCrypto AES encryption
f = open("somefile", 'wb')
f.write(data)
f.close()

3) Код декомпрессии:

f = open("somefile", 'rb')
data = f.read()
f.close()

zlib.decompress(decrypt(data)) #this yeilds the error in (1)

Ладно, извините, я недостаточно ясно понял. Это win32, python 2.6.2. Боюсь, я не могу найти файл zlib, но это все, что включено в двоичную версию win32. И у меня нет доступа к исходным данным - я сжимал свои файлы журналов и хотел бы вернуть их. Что касается другого программного обеспечения, я наивно пробовал 7zip, но, конечно, это не удалось, потому что это zlib, а не gzip (я не мог напрямую распаковывать потоки zlib). Я не могу предоставить точную копию трассировки сейчас, но она была (прослежена до zlib.decompress (data)) zlib.error: Error: -3. Кроме того, для ясности, это статические файлы, а не потоки, как я говорил ранее (так что ошибок передачи нет). И я снова боюсь, что у меня нет кода, но я знаю, что использовал zlib.compress (data, 9) (т.е.

Согласно RFC 1950 , разница между «OK» 0x789C и «плохим» 0x78DA заключается в битовом поле FLEVEL:

  FLEVEL (Compression level)
     These flags are available for use by specific compression
     methods.  The "deflate" method (CM = 8) sets these flags as
     follows:

        0 - compressor used fastest algorithm
        1 - compressor used fast algorithm
        2 - compressor used default algorithm
        3 - compressor used maximum compression, slowest algorithm

     The information in FLEVEL is not needed for decompression; it
     is there to indicate if recompression might be worthwhile.

«OK» использует 2, «плохо» использует 3. Так что эта разница сама по себе не проблема.

Чтобы получить дальнейшее, вы можете рассмотреть возможность предоставления следующей информации для каждого из сжатия и (попытки) распаковки: какая платформа, какая версия Python , какая версия библиотеки zlib, какой код использовался для вызова модуля zlib. Также предоставьте полную трассировку и сообщение об ошибке неудачных попыток декомпрессии. Вы пытались распаковать неисправные файлы с помощью какой-либо другой программы для чтения zlib? С какими результатами? Пожалуйста, поясните, с чем вам предстоит работать: "Меня обливают?" значит, что ты не нет доступа к исходным данным? Как оно попало из потока в файл? Какая у вас гарантия, что данные не были искажены при передаче?

ОБНОВЛЕНИЕ Некоторые наблюдения, основанные на частичных пояснениях, опубликованных в вашем собственном ответе:

Вы используете Windows. Windows различает двоичный режим и текстовый режим при чтении и записи файлов. При чтении в текстовом режиме Python 2.x меняет '\ r \ n' на '\ n' и меняет '\ n' на '\ r \ n' при записи. Это не лучшая идея при работе с нетекстовыми данными. Хуже того, при чтении в текстовом режиме '\ x1a', также известная как Ctrl-Z, рассматривается как конец файла.

Чтобы сжать файл:

# imports and other superstructure left as a exercise
str_object1 = open('my_log_file', 'rb').read()
str_object2 = zlib.compress(str_object1, 9)
f = open('compressed_file', 'wb')
f.write(str_object2)
f.close()

Чтобы распаковать файл:

str_object1 = open('compressed_file', 'rb').read()
str_object2 = zlib.decompress(str_object1)
f = open('my_recovered_log_file', 'wb')
f.write(str_object2)
f.close()

Кроме того: лучше использовать gzip, который избавляет вас от необходимости думать о таких неприятностях, как текстовый режим, за счет нескольких байтов для дополнительной информации заголовка. что, конечно, должно вызвать исключение. В этом случае вы можете осторожно обратить процесс, прочитав сжатый файл в двоичном режиме, а затем заменив '\ r \ n' на '\ n' [т.е. имитировать текстовый режим без уловки Ctrl-Z -> EOF]. Распаковать результат. Редактировать Вывести результат в текстовом режиме. Конец редактирования

ОБНОВЛЕНИЕ 2 Я могу воспроизвести ваши симптомы - с ЛЮБЫМ уровнем от 1 до 9 - с помощью следующего скрипта:

import zlib, sys
fn = sys.argv[1]
level = int(sys.argv[2])
s1 = open(fn).read() # TEXT mode
s2 = zlib.compress(s1, level)
f = open(fn + '-ct', 'w') # TEXT mode
f.write(s2)
f.close()
# try to decompress in text mode
s1 = open(fn + '-ct').read() # TEXT mode
s2 = zlib.decompress(s1) # error -5
f = open(fn + '-dtt', 'w')
f.write(s2)
f.close()

Примечание: вам понадобится достаточно большой текстовый файл (I использовал исходный файл размером 80 КБ), чтобы гарантировать, что результат распаковки будет содержать '\ x1a'.

Я могу выполнить восстановление с помощью этого сценария:

import zlib, sys
fn = sys.argv[1]
# (1) reverse the text-mode write
# can't use text-mode read as it will stop at Ctrl-Z
s1 = open(fn, 'rb').read() # BINARY mode
s1 = s1.replace('\r\n', '\n')
# (2) reverse the compression
s2 = zlib.decompress(s1)
# (3) reverse the text mode read
f = open(fn + '-fixed', 'w') # TEXT mode
f.write(s2)
f.close()

ПРИМЕЧАНИЕ: Если есть '\ x1a' или байт Ctrl-Z в исходный файл, и файл читается в текстовом режиме, этот байт и все последующие байты НЕ будут включены в сжатый файл и, следовательно, НЕ могут быть восстановлены. Для текстового файла (например, исходного кода) это вообще не потеря. В случае бинарного файла вы, скорее всего, попали в шквал.

Обновление 3 [после позднего обнаружения того, что проблема связана с уровнем шифрования / дешифрования]:

Сообщение «Ошибка -5» указывает на то, что данные файл, который вы пытаетесь распаковать, был искажен с момента его сжатия. Если это не вызвано использованием текстового режима для файлов, подозрение, очевидно (?) Падает на ваши оболочки дешифрования и шифрования. Если вам нужна помощь, вам нужно сообщить источник этих оболочек. Фактически, вам следует попытаться (как и я) собрать небольшой сценарий, который воспроизводит проблему более чем в одном входном файле. Во-вторых (как и я) посмотрите, можете ли вы повернуть процесс вспять при каких условиях. Если вам нужна помощь на втором этапе, вам необходимо предоставить сценарий воспроизведения проблемы.