You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Stefan Bodewig (JIRA)" <ji...@apache.org> on 2014/07/12 07:39:04 UTC

[jira] [Commented] (COMPRESS-263) Add DEFLATE support

    [ https://issues.apache.org/jira/browse/COMPRESS-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14059660#comment-14059660 ] 

Stefan Bodewig commented on COMPRESS-263:
-----------------------------------------

Counting isn't used consistently in Compress, gzip counts the decompressed bytes and only counts inside the input stream as well, so I won't bother you with it here.  All that's missing is the documentation, I'll look into it.


> Add DEFLATE support
> -------------------
>
>                 Key: COMPRESS-263
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-263
>             Project: Commons Compress
>          Issue Type: New Feature
>          Components: Compressors
>            Reporter: Matthias Stevens
>              Labels: features
>             Fix For: 1.9
>
>         Attachments: COMPRESS-263_DeflateSupport.patch, COMPRESS-263_DeflateSupport_v1.1.patch, bla.tar.deflate, bla.tar.deflatez
>
>
> GZIP is not a compression algorithm "as such". The de facto (and currently the only supported) compression algorithm it uses is DEFLATE.
> GZIP adds a header of minimum 10 bytes and a footer of 8 bytes to a "deflated" data stream. Find out more here: http://en.wikipedia.org/wiki/Gzip#File_format
> I have no problem with the current GZIP support, but it would be nice if CommonsCompress would also have compression and decompression support for "raw" DEFLATE streams and DEFLATE streams with the zlib header.
> Similarly to the GZIP support in CommonsCompress these functionality can be implemented very easily using the standard java.util.zip package, as done in the provided patch.



--
This message was sent by Atlassian JIRA
(v6.2#6252)