Why WinZip has better ratio than othes when compress compressed file

[l1t]

for examples
winrar a.txt ->a.rar 100K
winzip a.rar ->a.rar.zip 98K
7zip a.rar ->a.rar.7z 101K

[Black_Fox1]

As opposed to:
save file from my testset -> compressed with PAQ8K -> in
original 2 084 134
in.rar -> 2 084 205
in.zip -> 2 084 576


Can be smaller header and of course different handling of "random" data...

[Piotr Tarsa]

maybe because zip format enforces more frequent updating of literal huffman codes (maybe because of smaller dictionary size than other formats that are using huffman codes). this allows efficient coding of small reduntant block while not expanding other blocks with random data. 7z (lzma) uses adaptive arithmetic coding (as opposed to static huffman/ prefix coding in other lz77 schemes) and such method is known for expanding random data.

[encode]

The catch not only in huffman coding. Deflate stream has three types of blocks:
Two with different huffman codes (dynamic/static)
and one uncompressed (stored) block type
So, if Deflate cannot compress, it just store the data - inflation is about a few bytes per each 64 KB of data.