I can’t seem to get a stream that Flex 3 want’s to decompress.
I’ve tried:
- System.IO.Compression.GZipStream
- System.IO.Compression.DeflateStream
- ICSharpCode.SharpZipLib.Zip.Compression.Streams.DeflaterOutputStream
- zlib.ZOutputStream
None of these seem to make ByteArray.uncompress happy, i.e. I get
Error #2058: There was an error decompressing the data.
Also the whole Deflate vs zlib has me going around in circles.
It seems that according to the wikipedia article, zlib is an implementation of DEFLATE. But according to Actionscript they are two different things?
Microsoft also seems to indicate the Gzip at least uses the Deflate algorithm, as in their docs they refer that GZipOutputStream uses the same compression algorithm as DeflateStream. So I’m assuming that it’s just a header difference, which would indicate that’s “no good” as far as ‘ByteArray.uncompress’ as the “DEFLATE” algorithm is only supported in AIR applications.
Sample “server” code, using SharpZipLib in this case (not working):
public virtual bool ProcessRequest(string path, HttpListenerContext context)
{
var buffer = File.ReadAllBytes(path);
// Specifying to strip header/footer from data as that seems to be what the
// docs for ByteArray.uncompress indicate is necessary
var deflater = new Deflater(Deflater.DEFAULT_COMPRESSION, true);
using (var zipStream = new DeflaterOutputStream(context.Response.OutputStream, deflater))
{
zipStream.Write(buffer, 0, buffer.Length);
}
}
ZLIB and DEFLATE are not the same. There is a set of 3 related compression specs defined in IETF RFCs:
They all use (mostly) a particular compression algorithm, which is DEFLATE.
How ZLIB Relates to DEFLATE
The first, ZLIB, includes framing bytes in the beginning. According to RFC 1950…
CMF and FLG are bytes. As the spec says, the primary compression method used in ZLIB is DEFLATE, though the spec could be used with other methods. In general it isn’t. Also, the DICTID is generally not used. Therefore every ZLIB bytestream has 2 bytes, followed by a stream of compressed data, followed by an Adler32 checksum. The compressed data is a bare stream of bytes from DEFLATE.
How GZIP Relates to DEFLATE
That takes care of how ZLIB differs from DEFLATE, as a format. GZIP is a third format. If you want the details, check the RFC. The key things are that like ZLIB, GZIP primarily uses DEFLATE and it puts a header prior to the compressed datastream, and a checksum afterwards. But the GZIP header is different than the ZLIB header, so any GZipStream class is not going to be able to write a stream of bytes that will be readable as ZLIB. And vice versa.
Solving the problem
When reading a ZLIB Stream, some people address the problem you experienced by using .NET’s built-in DeflateStream on the datastream, after advancing the stream past the first two ZLIB framing bytes. This works, as long as you want to READ, the ZLIB stream uses DEFLATE (safe assumption) and it does not define a fixed dictionary (also pretty safe), and if you don’t care about the integrity check provided by the Adler32 (maybe).
If you don’t like making those assumptions or giving up the check, or if you have to generate a a ZLIB data stream, there’s a ZlibStream in DotNetZip that will read and write ZLIB data streams for you, and verify or produce the checksum as necessary.
DotNetZip is free to use, works with any .NET language. You don’t need the full DotNetZip library, instead you just need the Ionic.Zlib.dll .