Python: 压缩和解压实现
我正在和一个服务器对接,这个服务器要求发送给它的数据必须使用Deflate算法进行压缩(这是一种结合了霍夫曼编码和LZ77的压缩方式),而且它还会发送我需要Inflate的数据。
我知道Python里面有Zlib这个库,而Zlib的C语言库支持Inflate和Deflate的调用,但这些功能在Python的Zlib模块里似乎并没有提供。它提供了Compress和Decompress,但是当我调用下面的代码时:
result_data = zlib.decompress( base64_decoded_compressed_string )
我收到了以下错误信息:
Error -3 while decompressing data: incorrect header check
使用Gzip也没有好到哪里去;当我调用如下代码时:
result_data = gzip.GzipFile( fileobj = StringIO.StringIO( base64_decoded_compressed_string ) ).read()
我收到了这个错误:
IOError: Not a gzipped file
这也说得通,因为数据是一个Deflated文件,而不是一个真正的Gzipped文件。
我知道有一个Deflate的实现(叫做Pyflate),但我不知道有没有Inflate的实现。
看起来我有几个选择:
- 找到一个现成的Python实现(理想情况)来处理Inflate和Deflate
- 自己写一个Python扩展,调用zlib的C库,包含Inflate和Deflate
- 调用其他可以从命令行执行的东西(比如Ruby脚本,因为在Ruby中Inflate/Deflate的调用已经完全封装好了)
- ?
我在寻找解决方案,但如果没有解决方案,我也会感谢任何见解、建设性的意见和想法。
附加信息:
对我来说,解压(和编码)一个字符串的结果应该和下面这段C#代码的结果相同,其中输入参数是一个对应于要压缩数据的UTF字节数组:
public static string DeflateAndEncodeBase64(byte[] data)
{
if (null == data || data.Length < 1) return null;
string compressedBase64 = "";
//write into a new memory stream wrapped by a deflate stream
using (MemoryStream ms = new MemoryStream())
{
using (DeflateStream deflateStream = new DeflateStream(ms, CompressionMode.Compress, true))
{
//write byte buffer into memorystream
deflateStream.Write(data, 0, data.Length);
deflateStream.Close();
//rewind memory stream and write to base 64 string
byte[] compressedBytes = new byte[ms.Length];
ms.Seek(0, SeekOrigin.Begin);
ms.Read(compressedBytes, 0, (int)ms.Length);
compressedBase64 = Convert.ToBase64String(compressedBytes);
}
}
return compressedBase64;
}
运行这段.NET代码,输入字符串“deflate and encode me”,得到的结果是:
7b0HYBxJliUmL23Ke39K9UrX4HShCIBgEyTYkEAQ7MGIzeaS7B1pRyMpqyqBymVWZV1mFkDM7Z28995777333nvvvfe6O51OJ/ff/z9cZmQBbPbOStrJniGAqsgfP358Hz8iZvl5mbV5mi1nab6cVrM8XeT/Dw==
当“deflate and encode me”通过Python的Zlib.compress()处理后,再进行base64编码,结果是“eJxLSU3LSSxJVUjMS1FIzUvOT0lVyE0FAFXHB6k=”。
很明显,zlib.compress()并不是标准Deflate算法的实现。
更多信息:
.NET的deflate数据的前两个字节(“7b0HY...”)在进行base64解码后是0xEDBD,这与Gzip数据(0x1f8b)、BZip2(0x425A)数据或Zlib(0x789C)数据都不对应。
而Python压缩数据的前两个字节(“eJxLS...”)在进行base64解码后是0x789C。这是一个Zlib头部。
已解决
为了处理原始的deflate和inflate,不带头部和校验和,需要做以下事情:
在deflate/compress时:去掉前两个字节(头部)和最后四个字节(校验和)。
在inflate/decompress时:有一个第二个参数是窗口大小。如果这个值是负数,就会抑制头部。以下是我目前的方法,包括base64编码/解码,且运行正常:
import zlib
import base64
def decode_base64_and_inflate( b64string ):
decoded_data = base64.b64decode( b64string )
return zlib.decompress( decoded_data , -15)
def deflate_and_base64_encode( string_val ):
zlibbed_str = zlib.compress( string_val )
compressed_string = zlibbed_str[2:-4]
return base64.b64encode( compressed_string )
2 个回答
你仍然可以使用 zlib
模块来压缩和解压数据。gzip
模块在内部使用了它,但还添加了一个文件头,使其变成一个 gzip 文件。查看一下 gzip.py
文件,像这样可能会有效:
import zlib
def deflate(data, compresslevel=9):
compress = zlib.compressobj(
compresslevel, # level: 0-9
zlib.DEFLATED, # method: must be DEFLATED
-zlib.MAX_WBITS, # window size in bits:
# -15..-8: negate, suppress header
# 8..15: normal
# 16..30: subtract 16, gzip header
zlib.DEF_MEM_LEVEL, # mem level: 1..8/9
0 # strategy:
# 0 = Z_DEFAULT_STRATEGY
# 1 = Z_FILTERED
# 2 = Z_HUFFMAN_ONLY
# 3 = Z_RLE
# 4 = Z_FIXED
)
deflated = compress.compress(data)
deflated += compress.flush()
return deflated
def inflate(data):
decompress = zlib.decompressobj(
-zlib.MAX_WBITS # see above
)
inflated = decompress.decompress(data)
inflated += decompress.flush()
return inflated
我不知道这是否完全符合你服务器的要求,但这两个函数能够处理我尝试过的任何数据。
这些参数直接对应于传递给 zlib 库函数的内容。
Python ⇒ C
zlib.compressobj(...)
⇒ deflateInit(...)
compressobj.compress(...)
⇒ deflate(...)
zlib.decompressobj(...)
⇒ inflateInit(...)
decompressobj.decompress(...)
⇒ inflate(...)
这些构造函数创建了一个结构,并用默认值填充它,然后将其传递给初始化函数。compress
/decompress
方法会更新这个结构,并将其传递给 inflate
/deflate
。
这是对MizardX回答的一个补充,提供了一些解释和背景信息。
可以查看这个链接:http://www.chiramattel.com/george/blog/2007/09/09/deflatestream-block-length-does-not-match.html
根据RFC 1950,以默认方式构建的zlib流包含:
- 一个2字节的头部(例如:0x78 0x9C)
- 一个压缩流——详细信息请参见RFC 1951
- 未压缩数据的Adler-32校验和(4字节)
C#中的DeflateStream
正是处理(你猜对了)压缩流的。MizardX的代码告诉zlib模块,数据是一个原始的压缩流。
观察: (1) 希望C#的“解压”方法在处理短输入时产生更长的字符串 (2) 使用没有Adler-32校验和的原始压缩流?有点冒险,除非用更好的东西替代。
更新
错误信息 Block length does not match with its complement
如果你在用C#的DeflateStream
解压一些压缩数据时看到这个信息,那么很可能你给它的是一个zlib流,而不是压缩流。
可以查看这个链接:如何在文件的一部分上使用DeflateStream?
同时,把错误信息复制粘贴到谷歌搜索中,你会找到很多相关的信息(包括这个回答前面的内容),大致都是在说同样的事情。
Java中的Deflater
... 被“网站”使用 ... C#的DeflateStream“相当简单,并且已经与Java实现进行了测试”。那么,以下哪个Java Deflater构造函数是网站在使用的呢?
public Deflater(int level, boolean nowrap)
使用指定的压缩级别创建一个新的压缩器。如果'nowrap'为真,则不会使用ZLIB头部和校验和字段,以支持GZIP和PKZIP使用的压缩格式。
public Deflater(int level)
使用指定的压缩级别创建一个新的压缩器。生成的压缩数据将采用ZLIB格式。
public Deflater()
使用默认的压缩级别创建一个新的压缩器。生成的压缩数据将采用ZLIB格式。
一个简单的压缩器,在丢弃2字节的zlib头部和4字节的校验和后:
uncompressed_string.encode('zlib')[2:-4] # does not work in Python 3.x
或者
zlib.compress(uncompressed_string)[2:-4]