Tar Vs Zip Vs Gz: Differenza ed efficienza

Durante il download dei file, non è raro vedere le estensioni .tar, .zip o .gz . Ma conosci la differenza tra Tar e Zip e Gz? Perché li usiamo e che è più efficiente, tar o zip o gz?

Differenza tra tar, zip e gz

Se sei di fretta o vuoi semplicemente ottenere qualcosa di facile da ricordare, ecco la differenza tra zip e tar e gz:

.tar == file di archivio non compresso

.zip == (solitamente) file di archivio compresso

.gz == file (archivio o non) compresso usando gzip

Un po 'di storia dei file di archivio

Come molte cose sui sistemi Unix e Unix, la storia inizia molto tempo fa, in una galassia non molto distante chiamata anni settanta. In una fredda mattina di gennaio 1979, l'utility tar ha fatto la sua apparizione come parte del recentemente rilasciato Unix V7.

L'utilità tar è stata progettata come un modo per scrivere in modo efficiente molti file su nastri. Anche se oggigiorno le unità a nastro sono sconosciute alla stragrande maggioranza dei singoli utenti di Linux, i tarball - il soprannome di tar - sono ancora comunemente usati per impacchettare più file o anche interi alberi di directory (o anche foreste) in un singolo file.

Una cosa fondamentale da ricordare è che un semplice file tar è solo un archivio i cui dati non sono compressi. In altre parole, se si tar 100 file di 50kB, si finirà con un archivio le cui dimensioni saranno intorno a 5000kB. L'unico guadagno che ci si può aspettare usando tar da solo sarebbe evitando lo spazio sprecato dal file system poiché la maggior parte di essi alloca lo spazio con una certa granularità (ad esempio, sul mio sistema, un file lungo un byte utilizza 4kB di spazio su disco, 1000 di loro useranno 4MB ma il corrispondente archivio tar "solo" 1MB).

Vale la pena ricordare che tar non è certamente l'unico strumento Unix standard per creare archivi. I programmatori probabilmente sanno come è usato per lo più oggi per creare librerie statiche, che non sono altro che archivi di file compilati . Ma ar può essere usato per creare archivi di qualsiasi tipo. In effetti, i file del pacchetto .deb usati sui sistemi Debian sono ar archivi! E su MacOS X, i pacchetti mpkg sono (erano?) Archivi cpio compressi con gzip. Detto questo, né arcpio hanno guadagnato tanta popolarità quanto il tar tra gli utenti. Forse perché il comando tar era abbastanza buono e più semplice da usare.

Non il tipo di catrame che stai cercando

Creare archivi è bello. Ma con il passare del tempo, e con l'avvento dell'era dei personal computer, le persone si sono rese conto che potevano fare enormi risparmi sull'archiviazione comprimendo i dati. Quindi, un decennio dopo l'introduzione o tar, zip è uscito nel mondo MS-DOS come formato di archivio a supporto della compressione . Lo schema di compressione più comune per zip è deflate che a sua volta è un'implementazione dell'algoritmo LZ77. Ma essendo sviluppato commercialmente da PKWARE, il formato zi p ha sofferto di ingannare i brevetti per anni.

Quindi, in parallelo, gzip è stato creato per implementare l'algoritmo LZ77 in un software gratuito senza rompere alcun brevetto PKWARE.

Un elemento chiave della filosofia Unix è "Do One Thing and Do It Well", gzip è stato progettato per comprimere solo i file. Quindi, per creare un archivio compresso, devi prima creare un archivio usando l'utilità tar, ad esempio. E dopo, comprimerai quell'archivio. Questo è un file .tar.gz (a volte abbreviato in .tgz per aggiungere di nuovo a tale confusione - e per rispettare le limitazioni del nome del file MS-DOS 8.3 a lungo dimenticate).

Con l'evolversi dell'informatica, altri algoritmi di compressione sono stati progettati per un rapporto di compressione più elevato. Ad esempio, l'algoritmo di Burrows-Wheeler implementato in bzip2 (che porta agli archivi .tar.bz2 ). O più recentemente xz che è un'implementazione dell'algoritmo LZMA simile a quella usata nell'utilità 7zip .

Disponibilità e limitazioni

Oggi puoi utilizzare liberamente qualsiasi formato di file di archivio sia su Linux che su Windows.

Tuttavia, poiché il formato zip è nativamente supportato su Windows, questo è particolarmente presente in ambienti multipiattaforma. Puoi persino trovare il formato del file zip in posti inattesi. Ad esempio, tale formato di file è stato mantenuto da Sun per gli archivi JAR utilizzati per distribuire applicazioni Java compilate. O per i file OpenDocument ( .odf, .odp ...) utilizzati da LibreOffice o altre suite per ufficio. Tutti questi formati di file sono archivi zip sotto mentite spoglie. Se sei curioso, non esitare a decomprimere uno di loro per vedere cosa c'è dentro:

 sh $ decomprimere some-file.odt Archivio: some-file.odt estraendo: mimetype inflating: meta.xml inflating: settings.xml inflating: content.xm [...] gonfiando: styles.xml inflating: META-INF / manifest .xml 

Detto questo, nel mondo Unix, preferirei comunque il tipo di archivio tar in quanto il formato file zip non supporta tutti i metadati del file system Unix in modo affidabile. Per alcune spiegazioni concrete di quest'ultima affermazione, è necessario sapere che il formato file ZIP definisce solo una piccola serie di attributi di file obbligatori da memorizzare per ogni voce: nome file, data di modifica, autorizzazioni. Oltre a questi attributi di base, un archiviatore può memorizzare ulteriori metadati nel cosiddetto campo extra dell'intestazione ZIP. Tuttavia, poiché i campi aggiuntivi sono definiti dall'implementazione, non ci sono garanzie nemmeno per gli archivisti conformi per archiviare o recuperare lo stesso insieme di metadati. Controlliamo su un archivio di esempio:

 sh $ ls -lsn data / squadra totale 0 0 -rw-r - r-- 1 1000 2000 0 gen 30 12:29 squadra sh $ zip -0r archivio.zip dati / 
 sh $ zipinfo -v archive.zip data / team Voce di directory centrale n. 5: --------------------------- data / squadra [.. .] tipo di file apparente: attributi di file Unix binari (100644 ottali): -rw-r - r-- Attributi di file MS-DOS (00 hex): nessuno Il campo extra della directory centrale contiene: - Un sottocampo con ID 0x5455 ( tempo universale) e 5 byte di dati. Il campo extra locale ha orari di modifica / accesso UTC / GMT. - Un sottocampo con ID 0x7875 (Unix UID / GID (qualsiasi dimensione)) e 11 byte di dati: 01 04 e8 03 00 00 04 d0 07 00 00. 

Come potete vedere, le informazioni sulla proprietà (UID / GID) fanno parte del campo extra - potrebbe non essere ovvio se non si conosce l'esadecimale, né che i metadati ZIP siano memorizzati little-endian, ma in breve "e803" è "03e8" con "1000", il file UID. E "07d0" è "d007" che è 2000, il file GID.

In quel caso particolare, lo strumento zip Info-ZIP disponibile sul mio sistema Debian memorizzava alcuni metadati utili nel campo extra. Ma non c'è alcuna garanzia che questo campo extra venga scritto da ogni archiver. E anche se presente, non vi è alcuna garanzia che ciò possa essere compreso dallo strumento utilizzato per estrarre l'archivio.

Considerando che non possiamo rifiutare la tradizione come motivazione per usare ancora i tarball, con questo piccolo esempio, capisci perché ci sono ancora alcuni casi (d'angolo?) In cui tar non può essere sostituito da zip . Ciò è particolarmente vero quando si desidera conservare tutti i metadati di file standard.

Tar vs Zip vs Gz Efficiency Test

Parlerò qui dell'efficienza dello spazio, non dell'efficienza nel tempo, ma come regola empirica, più potenzialmente efficiente è un algoritmo di compressione, più CPU richiede.

E per darti un'idea del rapporto di compressione ottenuto utilizzando diversi algoritmi, ho raccolto sul mio disco rigido circa 100 MB di file dai formati di file più diffusi. Ecco i risultati ottenuti sul mio sistema Debian Stretch (tutte le dimensioni riportate da du -sh ):

tipo di file.jpg.mp3.mp4.odt.png.testo
numero di file216345279299020724397
spazio su disco98M99M99M98M98M98M
catrame94M99M98M93M92M89M
zip (nessuna compressione)92M99M98M91M91M86M
zip (sgonfia)87M98M93M85M77M28M
tar + gzip86M98M93M82M77M27M
tar + bz287M98M93M42M71M22M
tar + xz70M98M22M348K51M19M

Innanzitutto, ti incoraggio a prendere quei risultati con un enorme vantaggio: i file di dati erano in realtà file che gironzolavano sul mio disco rigido, e non li avrei mai rivendicati come rappresentanti in alcun modo. Quindi, devo confessare che non ho scelto quei tipi di file casualmente. L'ho già detto, i file .odt sono già file zip. Quindi il guadagno modesto ottenuto comprimendoli una seconda volta non è sorprendente (eccetto per bzip2 o xy, ma lo considererei un'anomalia statistica causata dalla bassa eterogeneità dei miei file di dati - contenente diversi backup o versioni di lavoro dello stesso documenti).

Riguardo a .jpg, .mp3 e .mp4 ora: forse sai che quelli sono già file di dati compressi. Ancora meglio, potresti aver sentito che usano la compressione distruttiva . Ciò significa che non è possibile ricostruire esattamente l'immagine originale dopo una compressione JPEG. E questo è vero. Ma ciò che è poco noto è dopo la fase di compressione distruttiva di per sé, i dati vengono compressi una seconda volta usando l'algoritmo non distruttivo di word-length variabile Huffman per rimuovere la ridondanza dei dati.

Per tutti questi motivi, ci si aspettava che la compressione di immagini JPEG o file MP3 / MP4 non avrebbe lasciato grandi guadagni. Si noti che un file tipico contiene sia i dati altamente compressi sia alcuni metadati non compressi, ma possiamo ancora ottenere qualcosa. Questo spiega perché ho ancora un notevole guadagno per le immagini JPEG, come ho avuto molti di loro - quindi la dimensione complessiva dei metadati non era trascurabile rispetto alla dimensione totale del file. Ancora una volta, i risultati sorprendenti nella compressione di file MP4 usando xz sono probabilmente correlati alle alte somiglianze tra i vari file MP4 usati durante i miei test. O non lo sono?

Per sollevare finalmente questi dubbi, ti incoraggio fortemente a fare i tuoi confronti. E non esitate a condividere le vostre osservazioni con noi utilizzando la sezione commenti qui sotto!

Raccomandato

Il framework AI Open Source di Facebook PyTorch è alla ricerca di Solid
2019
GalliumOS: la distribuzione Linux per i Chromebook
2019
Come chiudere le applicazioni in esecuzione nel telefono Ubuntu
2019