Make zip files smaller with zip shrinker(evanhahn.com) |
Make zip files smaller with zip shrinker(evanhahn.com) |
1985457 oxipng-o6.png
2030036 oxipng-o2.png
2125459 ect-o9.png
2144598 ect-o3.png
2169351 optipng-o7.png
2215086 optipng-o2.png
2218326 original.png
oxipng 9.1.5
OptiPNG version 7.9.1
Efficient Compression Tool Version 0.9.5
I tried to apply ECT to a few .gz files, but it complained it was not compatible, and I did not dig further.
[edited for a typo s/I/it/]
But, why would you remove comments? Presumably, if those are there, they were added for a specific reason. And the author acknowledges the space savings are minimal.
I hope that's disabled by default. Something like: "turning this option on may reduce file size by a small percent, but could impact compatibility."
I suspect the option will be much more useful with file formats that are zip under the hood, where it's easier to test the small subset of applications that read those files and/or update the file specification.
Is there any point for (new) .bz2 archives in the era of Zstd?
It takes years for bzip2 be in every Linux Distro, and we _still_ doing gzip.
LZMA / xz tool are start to get more support, but they are nowhere near universal.
No idea when how long zstd will need.
For Windows systems, 7-zip (.7z, similar compression to .xz) is a free download for Windows 10, and Windows 11 can open up a .7z file with a simple double click.
.zip and .gz no longer need to be used here in 2026.
The APK number looks impressive if you don't know some files are uncompressed on purpose: https://developer.android.com/tools/zipalign
There's also no mention that this likely breaks signatures? https://developer.android.com/tools/apksigner
The weird thing is that they say they worked on Signal ... so, what's going on?
[1] http://web.archive.org/web/20031018072659/http://msdn.micros...
[1] https://github.com/UKGovernmentBEIS/inspect_ai/pull/3145
As far as I know, the ISO standard for zip only specifies two compression methods: "store" (no compression) and "deflate". If I follow that, when I create a zip file, I know it's not performant, but at least it's almost universal (except for file ownership, permissions, character encoding and anything modern).
The corporate PKWARE has added other compressions to their original zip software, but those are not in the standard. They will not work for an EPUB, a LibreOffice file, etc. If I want a good compression, I reach for zstd (often through `tar`) or 7z if I want more portability.
Just like if you modified PNG files to use zstandard instead of deflate, but otherwise be identical, it's still not a PNG file anymore.
yeah, this will inevitably break things. excluding those from the directory stripping shouldn't be too hard (TM)
"It deletes empty folders" and "Let me know if this is a problem for you"
NEVER DO THAT. I know you meant well, but the first rule of any program is to NEVER automatically delete something without informing the user. NEVER. Users keep empty folders for structure, reminders, or placeholders because software will dump files into it later when it's run. If it was there when they zipped it up, it should be there when they unzip it. Otherwise they'll check the before and after and it will show some folders missing, create confusion, and the user will run off trying to find out if anything else is missing.
Example: A user zips up a program. Some programs are coded to look for a folder and dump files into it, if the folder is missing the program will fail. I've had that occasionally over the years. Not all programs will recreate a missing folder.
makes me feel uneasy that sth. which does lossy compression(metadata is lost) is called "ZIP Shrinker". Hope nobody gets surprised by this.
The real solution is to use lzma(2).
Just kidding, I don't see how the overhead of the directory entry is even remotely enough to warrant removal. Most of the magic can be left to efficient DEFLATE compatible blocks and removing entries not in the central directory in the first place (ZIP files can support concatenation of new data so long as you re-write the central directory at the end of the file).
.gz/deflate is used when something very cheap and very fast is needed. xz/lzma is quite often too slow or requires too much memory even on decompression.
so no, .zip and .gz are very much needed in 2026.
you need python 3.14 for zstd.