

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer

Possible Duplicate:
Why doesn't ZIP Compression compress anything?


enter image description here

Is this the expected result?

share|improve this question



Explanation using basic logic only: Compression finds for a raw file a UNIQUE zipped file, and for zipped file UNIQUE raw (uncompressed) original file. Imagine you have 8-bit files and want to compress them into 5-bit files. There are 256 unique 8-bit files, but only 32 unique 5-bit files(!) So some 8-bit files must be compressed into the same 5-bit file(!). And if 2 different raw files compressed into same ZIP file, which one do you want to get after decompression? For any zipping method, if there exist files that become smaller after zipping, there must exist files, that become larger(!) – Ivan Kuckir Jan 19 '15 at 22:44
up vote 70 down vote accepted

It comes down to a concept called entropy. See Wikipedia.






share|improve this answer
@Mehrdad Sure: Just write a "compression" algorithm that always returns the original input. There; done. :P ... Aside from that, no -- any compression algorithm that's an algorithm at all is going to have some metadata, even if it's just one bit at the start of the file that indicates whether or not the file is compressed (0 == uncompressed, 1 == compressed). If you're going to modify the contents of the file AT ALL, you need some metadata. And if you're modifying the contents, you're going to make some inputs larger. – allquixotic Jul 23 '14 at 13:36
However, if your question was "Is there any compression algorithm that does not increase the length of the input beyond a fixed amount of metadata", the answer is: I don't know, but it should be theoretically possible to do it. Easy, in fact. All you have to do is develop a container format that can either contain the original file, or a compressed data stream. Then, when you create the archive, try to compress: if the compressed size is larger than the input, just store the original input and pack your metadata in front. The file size will increase, but if the metadata is small (cont'd) – allquixotic Jul 23 '14 at 13:39
@Mehrdad: "Is there any compression algorithm (however poor) that does not increase the length of any input?" - The answer is no. There are 2^(n+1)-1 possible messages of size n-bits or less. Our algorithm must map each one of these to a unique output. If even one of these gets mapped to a value with fewer bits, another value must necessarily get mapped to one with more. – BlueRaja - Danny Pflughoeft Jan 27 '15 at 23:30







share|improve this answer
You can't guarantee an algorithm that makes the file smaller but you can guarantee one that won't increase the size by applying no "compression" in those cases. In order to really have no file size increase though, you would have to indicate this out of band (e.g. in the file name). – jeteon Aug 20 '15 at 7:39
@jeteon I am not sure what you trying to say. – oleksii Aug 20 '15 at 10:49
I was just adding that since you always have the option of not compressing the input, you can have a compression program that will not compress the file at all at worst. Basically, if you determine that the compressed version is larger than the uncompressed version, then you just leave it. You would also then have to indicate somehow that this is the case without adding to the size of the output so the decompresser knows the file wasn't compressed. The only way to do this without increasing the file size, is doing something like changing the file name. – jeteon Aug 20 '15 at 12:31
@jeteon oh, I see. Yep, make sense. – oleksii Aug 20 '15 at 14:19


share|improve this answer



share|improve this answer

the compressing ideea:



share|improve this answer
