Convertire TAR in ZIP

I tarball non compressi sono quasi sempre output di macchine. `docker save` ne scrive uno. Gli strumenti di backup e i pannelli di hosting li scrivono come intermedio. I dataset vengono scaricati come tar perché la pipeline che li ha creati intendeva comprimerli dopo e non lo ha fatto. I sistemi di build li producono come artefatto da consegnare al passo successivo.

Conta perché dice cosa aspettarsi dentro: molti file, nomi generati da macchina, percorsi profondi e nessun pensiero dato all'archivio come qualcosa che una persona aprirà un giorno. Questa conversione è di solito il momento in cui l'output di una macchina diventa il file di un umano, un lavoro genuinamente diverso dal reimpacchettare un archivio che qualcuno ha assemblato di proposito. Spiega anche perché il tarball è non compresso in primo luogo — il programma che lo ha scritto stava per consegnarlo direttamente a qualcos'altro, e comprimere un artefatto che viaggia dieci centimetri sarebbe stato uno sforzo sprecato.

La maggior parte delle conversioni d'archivio qui scambiano un compressore per un altro e la dimensione si muove un po' in una direzione o nell'altra. Questa parte dal nulla. La compressione di TAR, nel nostro registro, è registrata come nessuna — scrive intestazioni e contenuti file in sequenza e non tocca mai un loro byte.

Quindi uno ZIP dello stesso contenuto è compresso dove il TAR non lo era, e sul materiale che i tarball di solito contengono — file sorgente, JSON, log, configurazione, livelli container pieni di testo — la differenza è grande piuttosto che marginale. È la rara conversione dove il guadagno di compatibilità e il guadagno di dimensione puntano nella stessa direzione, motivo per cui non serve un argomento a favore o contro: non c'è alcuno scambio in atto qui oltre alla perdita dei metadati Unix descritta più sotto. Ogni altra coppia d'archivio su questo sito chiede di rinunciare a qualcosa in cambio di qualcos'altro, e questa per lo più no.

TAR è un flusso di blocchi fissi da 512 byte e nient'altro. Ogni membro costa un blocco intestazione che porta il suo nome, dimensione, modalità e timestamp, più il suo contenuto arrotondato al multiplo di 512 successivo, e l'intero archivio è terminato da due blocchi di zeri. Non c'è indice né directory centrale da nessuna parte nel file.

Su un archivio di pochi file grandi quell'overhead è invisibile. Su uno che ne contiene migliaia piccoli — un `node_modules`, un checkout, una directory di piccoli documenti JSON — il solo riempimento può essere una frazione seria del file. Anche uno ZIP ha overhead per voce, ma sono decine di byte invece di un arrotondamento a mezzo kilobyte, e le voci sono compresse sopra.

ZIP scrive una directory centrale alla fine che elenca ogni voce e dove inizia. Un programma può quindi leggere il contenuto di un grande archivio senza decomprimerne nulla, ed estrarre un file senza toccare gli altri. È ciò che fa comportare uno ZIP come una cartella in Explorer.

Un TAR non ha alcun indice, quindi elencarlo significa leggerlo dall'inizio, ed estrarre un file dal mezzo significa attraversare tutto ciò che lo precede. Quel design è una conseguenza dell'età e dello scopo del formato — è stato scritto nel 1979 per unità a nastro, dove cercare all'indietro non era un'opzione — ed è il motivo per cui ogni strumento che sfoglia archivi è più contento con uno ZIP.

Un TAR memorizza una modalità, un utente e un gruppo per ogni membro, ed è per questo che i flussi di lavoro di deployment e packaging lo usano. ZIP non ha alcun posto per nulla di ciò che gli strumenti desktop rispettino, quindi non passa attraverso la conversione.

La regola generale tra le coppie d'archivio qui è che i membri escono byte per byte e ciò che il contenitore sapeva su di loro è ciò che è a rischio — una password, e su alcuni formati i permessi e i timestamp. Per un tarball questa è la parte da considerare, perché un tar da una build o un'esportazione container dipende molto più probabilmente da un bit eseguibile di quanto lo faccia uno ZIP fatto da qualcuno su un desktop.

Il guadagno di dimensione descritto sopra non è automatico. Se il tarball contiene fotografie, video, PDF o file già compressi prima di essere archiviati, DEFLATE ha quasi nulla da trovare e lo ZIP arriva vicino al TAR meno il suo riempimento.

Vale la pena controllarlo prima di presumere che la conversione risolva un problema di trasferimento. Un tar da 25 MB di JPEG non diventerà uno ZIP da 6 MB, e nessun compressore su questo sito o altrove lo renderà tale; i byte sono stati spesi quando le fotografie sono state codificate. Ciò che si ottiene ancora è un file unico che ogni macchina può aprire, spesso la vera ragione per convertire in primo luogo.

Questa coppia gira sul nostro convertitore piuttosto che nel browser. Il TAR viene caricato su una connessione cifrata, estratto con 7-Zip in una directory temporanea, ricompresso come ZIP dall'interno di quella directory, e restituito; il caricamento e ogni intermedio vengono eliminati quando il lavoro finisce.

Lo spazio temporaneo è un filesystem in memoria limitato, scartato insieme al container che ha eseguito il lavoro. I limiti sono 25 MB per caricamento sul livello gratuito e un tetto rigido di sessanta secondi per lavoro, con un rifiuto netto per qualsiasi archivio che dichiari di espandersi oltre 2 GB. Un tar è non compresso, quindi quella dichiarazione raramente si discosta molto dalla dimensione del file stesso.

Se la destinazione è una macchina Linux invece di un desktop, convertire in ZIP risolve un problema che non si ha. La mossa idiomatica è tenere il TAR e comprimerlo — convertire il tarball in GZ produce il `.tar.gz` che ogni strumento Unix scompatta in un comando, e mantiene le modalità e la proprietà che il tar portava.

Si sceglie ZIP quando una persona su Windows o macOS deve aprire il file, o quando un modulo di caricamento lo richiede. Si sceglie un tarball compresso quando il file torna nello strumentario. La differenza non è gusto tecnico; è chi sta dall'altra parte.

Lo ZIP guadagna un controllo che il tarball non ha mai avuto. Il campo `chksum` di Tar copre solo il blocco intestazione, quindi un membro corrotto si estrae silenziosamente con i byte sbagliati; ZIP memorizza un CRC-32 per voce e segnala quella cattiva per nome. Ogni membro viene copiato senza essere ricodificato — un contenitore lossless non ha nulla da ricodificare in primo luogo. Il conteggio delle voci e i percorsi nello ZIP dovrebbero corrispondere esattamente al tarball, e qualsiasi archiviatore elencherà entrambi senza estrarre nulla, il che rende il confronto un lavoro di trenta secondi.

L'unica cosa che merita un'occhiata deliberata è il livello superiore. Un tar scritto da una directory genitore porta una cartella iniziale in ogni percorso e uno scritto dall'interno no, e lo ZIP riproduce fedelmente quello che ha trovato. Se i propri file escono un livello più in profondità del previsto, è la disposizione del tarball stesso che traspare piuttosto che qualcosa introdotto dalla conversione — e vale la pena saperlo prima che uno script che codifica il percorso venga eseguito contro di esso.

Un tar prodotto da `docker save` è un buon esempio di archivio che non è davvero una cartella. Contiene blob di livello, un manifesto e metadati JSON i cui nomi sono lunghe stringhe esadecimali, e nulla di ciò è pensato per essere letto da una persona. Convertirlo in ZIP funziona perfettamente bene e dà esattamente quella struttura, compressa, in un file che la propria macchina aprirà.

Ciò che non dà è l'immagine. Ricostruirne una richiede che il tar venga ridato a un runtime container, che si aspetta il tar e non uno ZIP, quindi una copia convertita è utile per ispezionare o inoltrare l'artefatto e non per ripristinarlo. La stessa cautela si applica agli strumenti di backup che scrivono tarball con propri file indice dentro: l'archivio converte in modo pulito, e se lo strumento che lo ha creato accetterà la versione convertita è una domanda separata da controllare prima di scartare l'originale.