.net - What if data compressed with GZipStream or DeflateStream is longer than the raw data? -
i'm no expert on formats, i'm guessing it's possible input data compressed data longer, due formatting overheads.
i'm ok i'm not ok documented behaviour of count parameter gzipstream/deflatestream.write(): "the maximum number of compressed bytes write." usual practice (unless compressing in chunks) pass in length of input data:
public static byte[] compress(byte[] data) { using (var compressed = new io.memorystream(data.length)) { using (var compressor = new io.compression.deflatestream(compressed, io.compression.compressionmode.compress)) compressor.write(data, 0, data.length); return compressed.toarray(); } }
in edge case i'm talking about, write statement won't write out whole compressed data stream, first data.length bytes of it. double buffer size large data sets that's bit wasteful, , anyway don't guesswork.
is there better way this?
i pretty sure mistake in documentation. documentation in earlier versions reads "the number of bytes compressed.", consistent how other streams work.
the same change made documentation of read
method, makes sense, think change made mistake documentation of write
method. corrected documentation of read
method, , thought same correction apply write
method also.
the normal behavior read
method of stream can return less data requested, , method returns number of bytes placed in buffer. write
method on other hand writes data specified. wouldn't make sense method write less data in implementation. method doesn't have return value, not return number of bytes written.
the count specified not size of output, it's size of data send method. if output larger input, still written stream.
edit:
i added comment community content of documentation of method in msdn library. let's see if microsoft follows on that...
Comments
Post a Comment