Comprimere i file prima dell'invio: riduci dimensione e tempo

Comprimi testo, codice sorgente, log, CSV e formati immagine non compressi come .bmp o .tiff prima di inviare: aspettati riduzioni da 3 a 10x. Non comprimere file .jpg, .png, .mp4, .mp3, .docx, .xlsx, .pdf o .zip — sono già compressi internamente, e un secondo passaggio porta al massimo 2-3% di risparmio bruciando CPU. Per raggruppare molti file piccoli in un singolo upload usa .zip in modalità store (nessuna compressione). Per il rapporto massimo su dati comprimibili, 7z con LZMA2 supera tipicamente .zip del 30-40%. RAR è sostanzialmente equivalente a 7z ma richiede che il destinatario abbia WinRAR o 7-Zip installato — .zip è supportato universalmente.

Quando la compressione è davvero utile

I file di testo si comprimono in modo straordinario. Un file .log da 10 MB spesso si riduce a 800 KB con .zip (12x) e a 550 KB con 7z (18x). La compressione funziona perché i log contengono schemi altamente ripetitivi — timestamp, indirizzi IP, codici di stato HTTP — che gli algoritmi di compressione sfruttano in modo efficiente.

Categorie altrettanto comprimibili:

• Codice sorgente: .js, .py, .java, .cs, .go — tipicamente compressione da 3 a 5x
• Dati CSV: da 4 a 10x in base alla ridondanza del contenuto
• JSON/XML: da 5 a 8x grazie ai nomi di campo ripetuti
• Immagini non compresse: .bmp (5-10x), .tiff non compresso (4-8x)
• Database: dump .sql, file SQLite con pagine libere (2-4x)
• Livelli flat PSD: 2-3x se non già compressi con RLE internamente

Un tarball di un repository Git di dimensioni moderate spesso si comprime di 4-5x, ecco perché git archive racchiude l'albero in .tar.gz di default.

Quando la compressione è inutile

I formati già compressi non diventano più piccoli. I dati sottostanti sono già stati elaborati da DEFLATE, H.264, quantizzazione DCT JPEG o uno schema simile — l'entropia è già vicina al minimo teorico.

File che non beneficiano della compressione:

• .jpg, .jpeg, .heic: compressione lossy già applicata
• .png: compressione DEFLATE già integrata
• .mp4, .mov, .mkv: compressione H.264 o H.265 già applicata
• .mp3, .aac, .flac, .ogg: audio già compresso
• .pdf: gli stream interni degli oggetti sono tipicamente compressi con DEFLATE
• .docx, .xlsx, .pptx: sono in realtà archivi ZIP di XML — ri-comprimerli è ridondante
• .zip, .7z, .rar, .gz, .bz2, .xz: archivi compressi; un secondo passaggio è inutile
• .apk, .jar, .war: archivi Java/Android basati su ZIP

Comprimere questi file spreca CPU e a volte aumenta leggermente la dimensione a causa dei metadati dell'archivio.

ZIP vs 7z vs RAR

| Formato | Rapporto tipico | Velocità | Compatibilità destinatario | Cifratura | |---|---|---|---|---| | .zip (DEFLATE) | Base | Veloce | Universale (integrato in Windows, macOS, Linux) | ZIP 2.0 (debole), AES-256 (strumenti moderni) | | .zip (DEFLATE64) | 5-10% migliore | Veloce | Windows integrato, 7-Zip, alcuni strumenti macOS | Come .zip | | 7z (LZMA2) | 30-40% migliore di .zip | Più lento | Richiede 7-Zip, Keka o The Unarchiver | AES-256 integrato | | .rar (RAR5) | ~25-35% migliore di .zip | Medio | Richiede WinRAR o 7-Zip; creazione non gratuita | AES-256 integrato | | .tar.gz | Simile a .zip | Veloce | Integrato in macOS, Linux; richiede 7-Zip su Windows | Nessuna nativa | | .tar.zst (Zstandard) | Tra .zip e 7z | Molto veloce | Richiede zstd (non ancora universale) | Nessuna nativa |

Per la portabilità, .zip rimane la scelta più sicura. Per il rapporto, vince 7z. Per velocità ed efficienza moderna, Zstandard (.zst) è eccellente ma i destinatari devono avere gli strumenti adatti.

Modalità "store" per il raggruppamento

Se stai inviando 200 foto .jpg in un unico trasferimento, vuoi comunque tenerle in un singolo archivio così il destinatario clicca "scarica" una volta sola. Usa .zip con livello di compressione 0 (modalità "store"). L'archivio è la somma delle dimensioni dei file più qualche kilobyte di overhead di directory — e il costo CPU per crearlo è quasi zero.

In 7-Zip: Aggiungi all'archivio → Livello di compressione → Store. In Finder su macOS: clic destro → Comprimi (usa DEFLATE di default, che non aiuta sulle .jpg ma non peggiora molto). Da riga di comando: zip -0 bundle.zip *.jpg.

Cifratura durante la compressione

I file ZIP protetti da password con AES-256 (non la vecchia cifratura ZIP 2.0) sono una soluzione ragionevole per il trasporto di contenuti sensibili quando non puoi fare affidamento sulla sicurezza del canale di trasferimento. WinRAR, 7-Zip e Archive Utility di macOS supportano tutti la cifratura AES-256 per i file ZIP.

L'ostacolo: lo scambio della password. Non inviare la password nello stesso messaggio del file ZIP. Invia il file e poi condividi la password via Signal, iMessage o un canale separato. Meglio ancora: usa un servizio di trasferimento con protezione tramite password integrata, che gestisce la complessità per te.

La vecchia cifratura ZIP 2.0 (ancora talvolta predefinita in strumenti più datati) è crittograficamente compromessa: recuperabile in secondi con attacchi known-plaintext. Verifica sempre di usare AES-256 se ti affidi alla cifratura dell'archivio per la sicurezza.

Il compromesso: tempo CPU vs byte risparmiati

La compressione è un trade-off tempo/dimensione. La compressione massima con 7z su un archivio di testo da 5 GB potrebbe richiedere 30 minuti su un laptop e risparmiare 2 GB rispetto a .zip. Se il trasferimento è limitato dalla dimensione (un servizio con un tetto di 2 GB), ne vale la pena. Se il trasferimento è limitato dal tempo e la banda è economica, gli stessi 5 GB si caricano in 90 secondi su fibra — la mezz'ora di compressione avrebbe costato più tempo di quello che ha risparmiato.

Regola pratica: comprimi quando la rete è lenta rispetto alla CPU; non farlo quando la rete è veloce rispetto alla CPU.

Dividere archivi di grandi dimensioni

Quando un file supera il tetto di un servizio di trasferimento, dividere in volumi è un'opzione. 7-Zip e WinRAR supportano entrambi archivi multi-parte (.7z.001, .7z.002, o .part1.rar, .part2.rar). Ogni parte può essere caricata come trasferimento separato; il destinatario scarica tutte le parti ed estrae.

Questo funziona ma è fragile — se manca anche una sola parte, l'intero archivio è inutilizzabile. Meglio quando possibile: usa un servizio con un tetto più alto. Il limite da 50 GB di SwissTransfer elimina la necessità di dividere nella maggior parte dei casi reali.

La compressione lossy come alternativa

A volte l'obiettivo non è la compressione dell'archivio ma quella del formato del file. Un file audio .wav da 200 MB diventa un .mp3 320 kbps da 15 MB — lossy ma praticamente trasparente per l'ascolto casuale. Una foto .tiff non compressa da 60 MB diventa un .jpg di alta qualità da 5 MB. Un video .mov 4K ricodificato in H.265 a bitrate ragionevole può ridursi di 3-5x.

Usalo con giudizio. Per i master file, la conversione lossy distrugge informazioni. Per le anteprime o i deliverable, è lo strumento giusto. Strumenti: FFmpeg per video/audio, HandBrake per video, ImageMagick per immagini, e le finestre di dialogo di esportazione di Photoshop, Final Cut Pro o Premiere.

Cosa fa comunque il servizio di trasferimento

La maggior parte dei servizi di trasferimento comprime in qualche misura durante il transito — la compressione TLS è disabilitata per motivi di sicurezza, ma gzip o brotli HTTP sul livello API a volte si attivano per i metadati. Il payload del file vero e proprio non viene compresso lato server perché la maggior parte del traffico è già in formati compressi.

HexaTransfer e i servizi zero-knowledge simili non possono comprimere i payload lato server perché ricevono testo cifrato. La compressione deve avvenire sul client prima della cifratura — dopo la cifratura, il testo cifrato ha un aspetto casuale ed è incomprimibile. Questo significa che la compressione lato client è l'unico modo per ridurre la dimensione quando si usa un servizio E2EE.

Decidi in base al contenuto, non all'abitudine

L'errore principale è il "zippa sempre prima di inviare" fatto per riflesso. Per un cliente che riceve 20 documenti .pdf, un bundle ZIP è comodo. Per un cliente che riceve un solo .mp4 da 800 MB, il ZIP spreca tempo per entrambi. Adatta la scelta al contenuto.

In caso di dubbio: invia raw. Il destinatario può sempre comprimere dopo aver ricevuto. Se stai raggruppando più file, usa .zip in modalità store. Se il contenuto è prevalentemente testo, usa 7z per risparmi reali.

In sintesi

Comprimi quando i dati sono comprimibili — testo, log, codice sorgente, database. Non comprimere quando i dati sono già compressi — foto, video, audio, PDF, documenti Office. Per il raggruppamento, usa ZIP in modalità store. Per il rapporto massimo su testo, usa 7z con LZMA2. Cifra con password AES-256 sull'archivio solo come complemento a un canale di trasferimento sicuro, non come sostituto.

Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.