Convertire ZIP in XZ

Il tempo di compressione lo paga una macchina, una volta sola. Il trasferimento lo paga chiunque scarichi il file, ogni volta, e su un bucket a consumo o una CDN si paga in denaro oltre che in secondi. Questa asimmetria è l’intero argomento per l’XZ, ed è per questo che il suo riepilogo nel nostro registro lo chiama lo standard per download sorgente e pacchetti.

Dice anche esattamente quando non preoccuparsene. Un archivio che un collega aprirà una volta non ha economia da ottimizzare: i secondi spesi a impacchettare sono gli unici secondi coinvolti in tutta la vita del file, e gzip avrebbe già finito.

L’XZ è un compressore piuttosto che un archivio. Il registro lo registra come formato flusso con un membro solo e segnala l’assenza di qualsiasi struttura di directory come problema noto — non c’è dove in un file .xz far vivere un nome, un percorso o un bit di permesso.

I contenuti del vostro ZIP vengono quindi disposti in un TAR, che porta tutto ciò, e l’XZ comprime il tarball come oggetto singolo. Non è un espediente inventato per questo convertitore; è la disposizione usata da tutto l’ecosistema Unix, ed è per questo che l’estensione che vedete su ogni release sorgente è .tar.xz.

Il numero è la storia. Il DEFLATE, usato sia da ZIP sia da gzip, codifica una ripetizione come riferimento a qualcosa negli ultimi 32 KB. L’LZMA2 nell’XZ può riferirsi a qualcosa fino a 64 MB indietro — duemila volte la distanza — e codifica quei riferimenti con un range coder che costa meno bit dei codici Huffman di DEFLATE.

Dove si vede è in qualsiasi archivio la cui ripetizione è sparsa: un albero sorgente dove la stessa intestazione di licenza apre duecento file, un dataset di esportazioni CSV simili, una cartella di documenti costruiti da un modello. Dove si vede meno è uno ZIP di fotografie o video.

Un grande dizionario non è gratis all’altra estremità. Il decompressore deve tenere quella finestra in memoria per risolvere i riferimenti, quindi la memoria necessaria per estrarre segue approssimativamente il dizionario con cui il file è stato impacchettato piuttosto che la dimensione del file stesso.

Su qualsiasi desktop o server è irrilevante. Smette di esserlo su hardware piccolo — un router, una scheda con microcontrollore, un agente di build limitato — che è l’unico posto dove la modesta finestra di 32 KB di gzip è un vantaggio invece di una limitazione.

Condividono una famiglia di compressione e il registro dà a entrambi un dizionario fino a 64 MB, quindi sul rapporto c’è poco da scegliere fra loro. La differenza è ciò che circonda i dati compressi. Il 7Z è un contenitore con la propria directory di voci, la propria cifratura e i propri checksum. L’XZ è un compressore avvolto attorno a un flusso.

Per la distribuzione, il flusso vince per convenzione: ogni macchina Linux e macOS ha tar e xz, e quasi nessuna ha 7-Zip installato di default. Per un archivio che tenete e sfogliate piuttosto che pubblicare, il 7Z è la forma migliore perché potete elencarlo ed estrarre un file senza disfare due livelli.

Entrambi i formati si verificano da soli. Uno ZIP memorizza un CRC per voce, quindi un membro danneggiato viene rilevato quando viene estratto. L’XZ porta un controllo sul suo flusso compresso — CRC-32, CRC-64 o SHA-256 a seconda di come è stato scritto — e rifiuta di darvi dati che non corrispondono.

Ciò che cambia è la granularità. In uno ZIP il controllo è per file, quindi una voce cattiva è un file cattivo. In un .xz il controllo copre il flusso, quindi il danno viene segnalato per l’intero archivio e il tar dentro potrebbe essere irrecuperabile oltre il danno.

Un flusso gzip può registrare il nome del file originale; un flusso XZ non registra nulla del genere. È compressione con un’intestazione che descrive il controllo e i filtri, senza alcun posto per un nome o un timestamp.

Ciò mette tutto il peso di descrivere il file su come lo chiamate. I download qui prendono il vostro nome originale più l’estensione di destinazione, quindi release-1.4.zip torna come release-1.4.xz; rinominarlo in release-1.4.tar.xz prima di pubblicarlo è la differenza fra un download che le persone riconoscono e uno che devono sondare.

La conversione gira sul nostro convertitore piuttosto che nel vostro browser, quindi lo ZIP viene caricato su una connessione cifrata, estratto con 7-Zip, tarrato, compresso con xz e restituito. Caricamento, intermedi e uscita vengono cancellati quando il lavoro finisce.

Le conseguenze sono il tetto di 25 MB per file del livello gratuito, un limite di sessanta secondi per lavoro, un rifiuto per qualsiasi archivio che dichiari più di 2 GB di contenuto non compresso, e un fallimento pulito piuttosto che un blocco su uno ZIP protetto da password.

I progetti che fanno bene spediscono due file. Il .tar.xz è per chi lo estrarrà in una shell o uno script, dove il download più piccolo è banda reale. Lo ZIP resta per chi su Windows vuole fare doppio clic, guardare dentro, e non pensare mai agli algoritmi di compressione.

Non è indecisione; sono due pubblici con vincoli genuinamente diversi, e un file solo non può servire entrambi senza penalizzarne uno. Se spedite solo un artefatto, spedite quello che i vostri scaricatori possono davvero aprire.

Se lo ZIP fa parte di una build pensata per essere riproducibile, sappiate che riimpacchettare non è un’operazione neutra. I byte dei membri sono preservati esattamente, ma l’archivio attorno viene scritto di nuovo: ordine delle voci, timestamp e le scelte proprie del compressore vengono dalla macchina che fa l’impacchettamento.

Conta solo se qualcosa a valle fa il checksum dell’archivio piuttosto che dei suoi contenuti. Le pipeline di release che pubblicano un hash accanto al download dovrebbero generare quell’hash dal file che stanno davvero spedendo, calcolato dopo il riimpacchettamento finale.