ZIP vs 7Z vs ZSTD: la comparativa definitiva amb dades reals

triar entre ZIP, 7Z i ZSTD sembla qüestió menor fins que necessites desplegar aplicacions, enviar backups diàriament o reduir costos de emmagatzematge i ample de banda (veure com comprimir i descomprimir arxius). A la pràctica, la decisió canvia els temps de lliurament, el consum de CPU/RAM i fins i tot la compatibilitat amb eines i sistemes de tercers.

Després de revisar múltiples benchmarks amb dades reals i contextos molt diferents. dataset de 5,4 GB .NET per a desplegaments, passant per un corpus de text de Wikipedia d'1 GB, a imatges de contenidor i un binari de 28,7 GB— la foto completa revela quan convé prioritzar ràtio, on mana la velocitat de descompressió i quines implicacions té la compatibilitat (ZIP clàssic, ZIP amb ZSTD, 7Z amb LZMA2 o amb còdecs alternatius, etc.).

Què comparem i per què importa

Hem analitzat les famílies més utilitzades: ZIP (Deflate), 7Z (LZMA/LZMA2) y ZSTD. A més, entren a la conversa Brotli, XZ, bzip2, zpaq i LZ4, perquè a la vida real gairebé mai és un «cara a cara» pur. A desplegaments .NET, per exemple, l'equilibri entre compatibilitat, ràtio i velocitat pesa de manera diferent que en backups massius o en empaquetat de paquets de distribució.

El context mana: si busques mínim temps de desplegament i suport omnipresent, no tries igual que quan intentes minimitzar l'emmagatzematge de 15 còpies de seguretat (i dividir fitxers comprimits) i optimitzar el cost d'egress. El millor és que ara hi ha xifres comparables i patrons clars per decidir amb cap.

Com treballa cada format (i què significa a la pràctica)

• ZIP (Deflate) combina LZ77 i Huffman; és el veterà, ubic i compatible fins a la medul·la. No sol guanyar en ràtio ni en velocitat de compressió davant d'opcions modernes, però obre a qualsevol lloc (veure com gestionar extensions de l'explorador) i la seva implementació és estable i coneguda. El ZIP tradicional (mètode 8) tenia límits històrics, encara que els compressors moderns sortegen gran part d'aquestes traves.
• 7Z es recolza sobretot en LZMA/LZMA2, amb molt bona ràtio i eines madures. A més, 7-Zip paral·lelitza bé i els seus «defaults assenyats» ho fan sentir àgil. És un estàndard de facto en entorns d'escriptori i devs, amb suport ampli a Windows, Linux i macOS (de vegades estirant utilitats externes).
• Zstandard (ZSTD), Creat per Facebook (2015), destaca per descompressió extremadament ràpida i una paleta de nivells molt àmplia (1–22). El seu objectiu és rendir igual o millor que Deflate i acostar-se a LZMA en ràtio, amb una execució generalment més veloç. Ho veiem integrat en kernels BSD/Linux, compressió de paquets (p. ex. Arch Linux utilitza zstd nivell 20, descomprimint 14× més ràpid que XZ amb només +0,8% de mida) i cada vegada més present en fluxos CI/CD.

Altres actors que convé conèixer

• Brotli, pensat per a la Web, comprimeix millor que gzip en contingut textual i es beneficia del content-encoding dels navegadors. La seva referència de compressió és monofil, cosa que esbiaixa comparatives de temps real wall-clock si ho enfrontes a còdecs multifil, però hi ha implementacions paral·leles. En entorns de servidor, el consum de CPU total (user+sys) és més rellevant que el rellotge de paret.
• XZ millora LZMA i ofereix gran ràtio a costa de temps de compressió alts. En binaris grans pot ser competitiu, però la seva velocitat de descompressió sol quedar darrere de ZSTD i 7Z. Concurrència multifil i el paràmetre -e (extrem) milloren una mica la foto, encara que no fa miracles.
• bzip2/pbzip2 equilibren ràtio i CPU més o menys al mig del tauler. Amb pbzip2 es guanya paral·lelisme. No obstant això, per a molts casos moderns ZSTD i 7Z ofereixen millors trade-offs globals.
• zpaq és el «tot terreny de la ràtio màxima» amb compressió incremental tipus journaling; el seu focus està en esprémer bytes, sacrificant amb gust la velocitat de descompressió. Per a còpies de seguretat freds pot ser bona idea; per a consum general, no.

Benchmarks amb dades: text, binaris grans i desplegaments

1) Dataset textual (Wikipedia 1 GB)

En una comparativa de ZIP (via 7zip), 7zip, XZ, Brotli, Zstandard, zpaq sobre 1 GB de text de Wikipedia, es van grafificar temps vs mida a cada nivell. L'autor avisa: proves no científiques i Brotli referència monofil penalitza els temps «reals». En còmput user+sys la foto millora per a Brotli; ZSTD apareix molt competitiu, descomprimint rapidíssim i amb ràtios a l'òrbita de XZ/7zip a esforços elevats.

Troballes clau: ZIP queda per darrere en ràtio i temps de compressió; 7zip avança amb eines més cuidades i multifil; XZ millora ràtio però decomprimeix més lent que ZSTD; ZSTD equilibra fantàsticament en pujar esforç; i zpaq aconsegueix ràtios top pagant molt de temps, sobretot en descompressió.

2) Prova «màxima compressió» de PeaZip (Windows, i7-8565U)

Amb PeaZip/WinRAR, fitxer d'entrada 303,0 MB i cinc repeticions per test, aquests van ser els valors mitjana (mides en MB; temps en s):

Conclusions: ZPAQ guanya en ràtio pur però és molt lent, fins i tot en extreure. 7Z (LZMA2) ofereix bona ràtio, amb extracció raonable. Usant Brotli/ZSTD dins de 7Z, la extracció vola (Brotli encara més), a canvi de compressions més llargues que LZMA2 en ultra. RAR prioritza velocitat de compressió sacrificant una mica de ràtio, i si necessites seguretat, pots veure com posar contrasenyes a fitxers comprimits.

3) Binari enorme de 28,7 GB (Linux, Ryzen 5 5600G)

Sobre un fitxer de 28,65–28,7 GB, l'objectiu era comprimir al màxim i comparar ràtios i temps amb xz, pbzip2, 7z i zstd:

• xz -9e -T12: 12,6 GiB a ~15m49s (≈ 44,0%)
• pbzip2 -9: 13,07 GiB a ~4m29s (≈ 44,55%)
• 7z -mx=9: 12,9 GiB a ~16m43s (≈ 43,98%)
• zstd –ultra -22 -T12: 12,48 GiB a ~19m48s (≈ 43,57%)

En «màxima compressió», ZSTD va guanyar per poc en mida, però va trigar més. pbzip2 va sorprendre en velocitat amb una ràtio propera. Aquest cas il·lustra que, sobre binaris molt grans, les diferències absolutes en GB pesen tant com els minuts de CPU, i convé quantificar tots dos.

4) ZIPs de jocs (EU4) i pas de tar+brotli a ZIP amb ZSTD

Un cas real: saus d'EU4 arriben com a ZIPs poc comprimits. Es va provar extreure i recomprimir: rezip estalvia ~17%. Canviant el còdec dins de ZIP, els números per nivell van ser:

A més, els payloads Wasm per transcodificar: ZSTD ~215 kB (136 kB si només codificador), Brotli ~683 kB. En parsing, comptant temps de fetch des de cache (el content-encoding brotli del navegador no és gratis), ZSTD i Brotli van quedar molt semblants: Brotli parseja una mica més ràpid per no descomprimir a user space; ZSTD es beneficia de no tocar el content-encoding i llegeix més lleuger del disc.

Amb pujada de 30 Mb/s, integrant transcodificació + transferència en un ZIP típic de 7,7 MB: original 2,05 s; ZSTD-3 1,70 s; ZSTD-5 1,88 s; ZSTD-7 2,28 s. La recomanació pràctica es va inclinar per ZSTD nivell 7 per estalvi d'emmagatzematge (quan pagues tu el bucket), encara que nivell 3 és temptador si prioritzes latència.

5) Desplegaments .NET (5,4 GB publish)

En un cas de desplegament d'aplicacions .NET amb 5,4 GB de sortida (barreja self-contained i framework-dependent), la guia pràctica és clara: tria per objectiu. Si apuntes a compatibilitat universal, estira ZIP clàssic; si el coll d'ampolla és descompressió i velocitat, ZSTD entra fort; si vols ràtio alta amb CLI i tooling consolidat, 7Z amb LZMA2 segueix sent cavall guanyador.

Descompressió: el factor que més es nota a l'experiència

Diverses proves independents assenyalen a ZSTD com a classe a part en descompressió. Al bench textual, en mirar user+sys s'entén per què ZSTD és òptim per a la compressió del sistema de fitxers (veure com desactivar la compressió automàtica) i empaquetat de paquets: la lectura és àgil i el cost CPU baix. 7zip ofereix una experiència molt bona, i la diferència amb XZ s'explica més per utilitats i multifil que per màgia del còdec.

Codi postal va donar la sorpresa en mètriques user+sys de descompressió quedant menys malament del que s'esperava; si el teu públic té màquines modestes o workflows on prima l'extracció ràpida, no ho descartis sense mesurar. ZPAQ, per la seva banda, torna a recordar-nos el seu perfil: ràtio increïble, però temps d'extracció molt alts, apte per a còpies fredes.

Casos d'ús: com decidir amb dades (RAM, temps, ràtio i cost)

En un escenari de plataforma de contenidors on cal fer backups diaris de 30–100 contenidors, el pressupost operatiu mana. Es va proposar un scoring pragmàtic:

• RAM: objectiu 200 MB en compressió i 100 MB en descompressió per puntuar 5; per cada +50 MB, resta 1 punt.
• Temps: finestra diària de 3 hores per comprimir-ho tot; per contenidor, 6–1,8 minuts. A l'escala, >120 s puntua 0, cada -20 s suma 1, <10 s és 5 punts en descompressió.
• Proporció: amb objectes de ~1,6 GB (p. ex. MariaDB+PHP+WordPress), i emmagatzematge a ~6 $/TB en backends tipus Backblaze/E2, cercar ≥4:1 ajuda a baixar cost d'egress (cura amb AWS a 0,09 $/GB de sortida).

Provant nivells, ZSTD nivell 3 va aconseguir ~3,5:1 a ~3 s amb 207 MB de RAM; Brotli nivell 6 va aconseguir ~4,3:1 a ~30 s amb bon perfil de RAM. Ajustant tuning de ZSTD (estratègia, searchLog, targetLength, minMatch) no es va millorar prou sense penalitzar temps o memòria; en aquesta anàlisi concreta, Brotli nivell 6 va sortir favorit. Curiosament, Brotli nivell 4 va utilitzar més memòria que 3/5 però va igualar ràtio de nivell 5 a la meitat de temps, una opció molt llaminera si 13 MB extra demmagatzematge són assumibles.

Si canvieu l'objectiu (per exemple, desplegaments ràpids o lectura intensiva), els pesos varien i ZSTD tendeix a ser lelecció més equilibrada per la seva decompressió fulgurant i ràtios decents a nivells mitjans.

Compatibilitat, suport i el paper del ZIP amb ZSTD

Una cosa clau: l'estàndard ZIP va incorporar ZSTD (mètode 93) des de l'especificació 6.3.8 (2020). Això permet «ZIP de tota la vida» amb un còdec modern. Com ho suporta l'ecosistema? Avui, Průzkumník Windows,en no crea ni extreu ZIP amb ZSTD; 7-Zip principal ho està integrant, i hi ha forks ja operatius. A Linux, hi ha forks de p7zip. La situació millora, però encara hi ha friccions.

si fas servir Comandant total, pots habilitar lectura 7z amb ZSTD substituint la TCLZMA64.DLL per versions compatibles (p. ex. del paquet TotalCmd.7z de 7-Zip ZS). Per crear 7z amb ZSTD dins de TC, els plugins antics no sempre respecten el còdec triat i cauen a LZMA; convé fer servir 7-Zip ZS complet o el plugin Codecs en una instal·lació 7-Zip existent. Amb 7-Zip ZS tindràs compressió/descàrrega de Brotli, LZ4, Lizard, ZSTD dins del contenidor 7z i maneig de ZIP+ZSTD. Comprova amb 7z i quins còdecs estan actius.

En navegadors i pipelins web, el content-encoding de Brotli sembla un «gratis total», però hi ha matisos: middleware, proxies i frameworks (p. ex. discrepàncies entre mode debug/producció a Next.js) poden refer la compressió o afegir latència. Servir precomprimits tampoc no és sempre senzill (Cloudflare Pages no ho suporta de sèrie). En diversos casos reals, substituir fluxos amb ZSTD a ZIP i descompressió a user space va aportar menys dependències de lentorn i resultats equivalents o millors.

Paràmetres útils i nivells recomanats

En ZSTD, els nivells 3, 5 i 7 ofereixen bons punts doperació. Un estudi creuant transcodificació+transferència amb 30 Mb/s va mostrar nivell 3 com el més ràpid extrem a extrem, però nivell 7 estalviava emmagatzematge (a EU4, 12,5% menys que 5 i 25% menys que 3). AWS Athena documenta preferències per nivells 6–9 quan no es fa servir el 3 per defecte, el que encaixa amb aquesta troballa.

La temptació d'activar long-distance matching és real, però compte: exigiràs que qui descomprimeixi disposi de la mateixa memòria que qui va comprimir. En desplegaments i aplicacions client, aquest requisit pot ser inviable. Millor mantenir finestres i taules dins de pressupostos raonables.

En Brotli, l'ajust estrella sol ser el nivell. Canviar lgwin pot augmentar memòria sense grans guanys si ja vas alt. L'observació que nivell 4 iguala ràtio de 5 a meitat de temps -a costa d'una mica més de RAM- és or quan vols baixar latència sense castigar massa la mida.

Per a XZ, el flag -e aplica variants més lentes del preset buscant una mica més de ràtio. Les taules de manual recorden que la memòria del compressor puja, però la del descompressor es manté. Tot i així, davant de ZSTD, XZ sol perdre en decompressió quan el que vols és obrir paquets a gran velocitat.

Si depens de ZIP clàssic però vols la màxima velocitat de Deflate, llibreries com libdeflate milloren molt el throughput davant de zlib. A l'ecosistema Rust, zip-rs no facilita encara canviar backends en crear ZIPs, per la qual cosa aquesta via pot no estar disponible sense feina addicional.

Article relacionat:

Com accelerar la transferència de fitxers a Windows 11: trucs i paràmetres clau

Isaac

Redactor apassionat del món dels bytes i la tecnologia en general. M'encanta compartir els meus coneixements a través de l'escriptura, i això és el que faré en aquest bloc, mostrar tot el més interessant sobre gadgets, programari, maquinari, tendències tecnològiques, i més. El meu objectiu és ajudar-te a navegar pel món digital de forma senzilla i entretinguda.