Compressione lossless

La compressione lossless riduce le dimensioni del file preservando ogni byte dell’originale. La decompressione produce output identico bit per bit all’input. Compromesso: risparmio inferiore rispetto alla compressione lossy — tipicamente una riduzione del 30-70% delle dimensioni a seconda del contenuto.

Come funziona: gli algoritmi lossless trovano pattern statistici (sottostringhe ripetute, sequenze prevedibili) e le codificano con rappresentazioni più brevi. Due famiglie classiche:

• Basata su dizionario (LZ77, LZ78, LZW): costruisce un dizionario di sottostringhe viste ed emette riferimenti all’indietro. La base di DEFLATE, gzip, ZIP.
• Codifica entropica (Huffman, codifica aritmetica, ANS): assegna codici binari più corti ai simboli più frequenti. Tipicamente combinata con metodi basati su dizionario.

Formati lossless comuni:

• PNG — immagini (usa DEFLATE)
• FLAC — audio (preserva PCM a 16-24 bit, tipicamente il 50-60% delle dimensioni di WAV)
• ZIP, gzip, Brotli, Zstandard — dati generici
• WebP e AVIF — entrambi supportano modalità lossless
• File pack di Git — archiviazione di repository di codice sorgente

Usa lossless quando hai bisogno di riproduzione bit-perfetta, quando il contenuto verrà ulteriormente modificato, o quando il file è testo/dati strutturati (che comunque non si comprimono bene in modo lossy).

Il soffitto information-teorico: il paper di Claude Shannon del 1948 ha stabilito che la compressione lossless non può scendere al di sotto dell’entropia della sorgente — l’informazione media per simbolo. Per i dati casuali (byte casuali, testo cifrato crittografato, file già compressi), l’entropia è massima e la compressione lossless ottiene essenzialmente zero risparmio. Ecco perché “gzip image.jpg” non guadagna quasi nulla; i byte JPEG sembrano già casuali a un compressore. Il corollario: se il tuo rapporto di compressione è sospettosamente buono su dati che dovrebbero essere ad alta entropia, probabilmente hai trovato un bug.

Lossless su dati lossy — quando conviene: una confusione comune è usare FLAC su una sorgente MP3 a 128 kbps, aspettandosi una migliore qualità audio. L’MP3 ha già scartato informazioni; FLAC preserva semplicemente in modo lossless la versione scartata. Per l’audio che ha avuto origine come PCM a 16 bit (CD, master da studio), FLAC è la scelta archivistica giusta. Per l’audio che ha avuto origine lossy, transcodificare in FLAC gonfia solo il file. La regola generale: archivia il master nel formato lossless di qualità più alta che la sorgente supporta; consegna tramite il miglior formato lossy che il consumatore può riprodurre. Correlato: DEFLATE, lossy. Riferimento: Shannon CE, A Mathematical Theory of Communication (Bell Syst Tech J, 1948).

Esempio pratico: comprimere un file di log da 10 MB

Un tipico log applicativo da 10 MB (righe JSON con timestamp, livello, messaggio, nomi di campo ripetuti) è altamente ridondante. Numeri reali da un benchmark recente sullo stesso input: gzip livello predefinito ≈ 1,6 MB (riduzione dell’84%, 0,2 s di codifica), Brotli livello 6 ≈ 1,1 MB (89%, 0,5 s), Zstandard livello 3 ≈ 1,3 MB (87%, 0,05 s), Zstandard livello 19 ≈ 0,9 MB (91%, 1,8 s). Byte casuali (10 MB da /dev/urandom) si comprimono entro pochi byte di 10 MB in ogni algoritmo — incomprimibili a causa dell’alta entropia. Immagini già-PNG si riducono di un altro 1-3% sotto gzip -9, motivo per cui i server HTTP tipicamente saltano Content-Encoding: gzip sulle risposte PNG/JPEG/MP4 per risparmiare CPU.

Scegliere un algoritmo nel 2026

Per la consegna web: Brotli a qualità 5-6 per asset statici (miglior rapporto a tempo di codifica accettabile, supportato in ogni browser moderno dal 2017), gzip come fallback per client legacy. Per archiviazione interna e pipeline: Zstandard, che domina la frontiera Pareto rapporto-di-compressione-vs-velocità alla maggior parte dei livelli di qualità ed è ora il predefinito in tar, moduli del kernel Linux, RocksDB e il formato del pacchetto npm. Per l’archiviazione di master insostituibili: usa ancora un wrapper che include un checksum (xz con SHA-256, o zip con CRC + SHA-256 esterno) — la compressione stessa non rileva il bitrot. Riferimento: RFC 8878 — Compressione Zstandard e il tipo di media application/zstd.