Tar Vs Zip Vs Gz: Diferença E Eficiência

Durante o download de arquivos, não é incomum ver as extensões .tar, .zip ou .gz . Mas você sabe a diferença entre Tar e Zip e Gz? Por que nós os usamos e qual é mais eficiente, tar ou zip ou gz?

Diferença entre tar, zip e gz

Se você está com pressa ou apenas quer ter algo fácil de lembrar, aqui está a diferença entre zip e tar e gz:

.tar == arquivo descompactado

.zip == (normalmente) arquivo compactado

.gz == arquivo (arquivo ou não) comprimido usando gzip

Um pouco de histórico de arquivos

Como muitas coisas sobre sistemas Unix e Unix-like, a história começa há muito tempo atrás, em uma galáxia não tão distante chamada de setenta. Em uma manhã fria de janeiro de 1979, o utilitário tar fez sua aparição como parte do recém-lançado Unix V7.

O utilitário tar foi projetado como uma forma eficiente de gravar muitos arquivos em fitas. Mesmo que hoje em dia as unidades de fita sejam desconhecidas para a grande maioria dos usuários individuais do Linux, os tarballs - o apelido de arquivos tar - ainda são comumente usados ​​para empacotar vários arquivos ou mesmo uma árvore de diretórios inteira (ou mesmo florestas) em um único arquivo.

Uma coisa importante a lembrar é que um arquivo tar simples é apenas um arquivo cujos dados não são compactados. Em outras palavras, se você tar 100 arquivos de 50kB, você vai acabar com um arquivo cujo tamanho será em torno de 5000kB. O único ganho que você pode esperar usando apenas o tar seria evitando o espaço desperdiçado pelo sistema de arquivos, pois a maioria deles aloca espaço em alguma granularidade (por exemplo, no meu sistema, um arquivo longo de um byte usa 4kB de espaço em disco, 1000 eles usarão 4MB, mas o arquivo tar correspondente "apenas" 1MB).

Vale a pena mencionar que o tar certamente não é a única ferramenta Unix padrão para criar arquivos. Os programadores provavelmente sabem como é usado atualmente para criar bibliotecas estáticas, que não são mais que arquivos compilados . Mas ar pode ser usado para criar arquivos de qualquer tipo. De fato, os arquivos de pacotes .deb usados ​​nos sistemas Debian são arquivos ar ! E no MacOS X, os pacotes mpkg são (eram?) Arquivos cpio compactados com gzip. Dito isto, nem o ar nem o cpio ganharam tanto popularidade quanto o tar entre os usuários. Talvez porque o comando tar fosse bom o suficiente e mais simples de usar.

Não é o tipo de alcatrão que você está procurando

Criar arquivos é legal. Mas com o passar do tempo e com o advento da era do computador pessoal, as pessoas perceberam que poderiam economizar muito no armazenamento compactando dados. Então, uma década depois da introdução ou tar, o zip apareceu no mundo do MS-DOS como um formato de arquivo suportando compressão . O esquema de compactação mais comum para zip é o deflate, que é uma implementação do algoritmo LZ77. Mas, sendo desenvolvido comercialmente pela PKWARE, o formato zi p sofreu com o bloqueio de patentes por anos.

Então, em paralelo, o gzip foi criado para implementar o algoritmo LZ77 em um software livre sem quebrar nenhuma patente PKWARE.

Um elemento-chave da filosofia Unix é “Do One Thing e Do It Well”, o gzip foi projetado para compactar apenas arquivos. Assim, para criar um arquivo compactado, você primeiro tem que criar um arquivo usando o utilitário tar, por exemplo. E depois disso, você comprimirá esse arquivo. Este é um arquivo .tar.gz (às vezes abreviado como .tgz para adicionar novamente a essa confusão - e para cumprir com as limitações de nome de arquivo 8.3 MS-DOS há muito esquecidas).

À medida que a ciência da computação evoluiu, outros algoritmos de compactação foram projetados para maior taxa de compactação. Por exemplo, o algoritmo Burrows – Wheeler implementado no bzip2 (levando a arquivos .tar.bz2 ). Ou mais recentemente xz, que é uma implementação do algoritmo LZMA semelhante à usada no utilitário 7zip .

Disponibilidade e limitações

Hoje você pode usar livremente qualquer formato de arquivo no Linux e no Windows.

Mas como o formato zip é suportado nativamente no Windows, este é especialmente presente em ambientes multi-plataforma. Você pode até encontrar o formato de arquivo zip em lugares inesperados. Por exemplo, esse formato de arquivo foi retido pelos archives Sun for JAR usados ​​para distribuir aplicativos Java compilados. Ou para arquivos OpenDocument ( .odf, .odp …) usados ​​pelo LibreOffice ou outros pacotes de escritório. Todos esses formatos de arquivos são arquivos zip disfarçados. Se você está curioso, não hesite em descompactar um deles para ver o que está dentro:

 sh $ unzip some-file.odt Arquivo: some-file.odt extrair: mimetype inflar: meta.xml inflar: settings.xml inflar: content.xm inflar: styles.xml inflar: META-INF / manifest .xml 

Tudo o que foi dito, no mundo Unix-like, eu ainda iria favorecer o tipo de arquivo tar porque o formato de arquivo zip não suporta todos os metadados do sistema de arquivos Unix de forma confiável. Para algumas explicações concretas dessa última instrução, você deve saber que o formato de arquivo ZIP define apenas um pequeno conjunto de atributos de arquivo obrigatórios a serem armazenados para cada entrada: nome do arquivo, data de modificação, permissões. Além desses atributos básicos, um arquivador pode armazenar metadados adicionais no chamado campo extra do cabeçalho ZIP. Porém, como os campos extras são definidos pela implementação, não há garantias, mesmo para arquivadores compatíveis, de armazenar ou recuperar o mesmo conjunto de metadados. Vamos verificar isso em um arquivo de amostra:

 sh $ ls -lsn dados / total da equipe 0 0 -rw-r - r-- 1 1000 2000 0 30 de janeiro 12:29 equipe sh $ zip -0r archive.zip data / 
 sh $ zipinfo -v archive.zip dados / equipe Entrada no diretório central # 5: --------------------------- data / team [.. .] tipo de arquivo aparente: atributos binários do arquivo Unix (octa 100644): -rw-r - r-- Atributos de arquivo do MS-DOS (hex hexagonal): nenhum O campo extra do diretório central contém: - Um subcampo com ID 0x5455 ( tempo universal) e 5 bytes de dados. O campo extra local tem tempos de modificação / acesso UTC / GMT. - Um subcampo com ID 0x7875 (Unix UID / GID (qualquer tamanho)) e 11 bytes de dados: 01 04 e8 03 00 00 04 d0 07 00 00. 

Como você pode ver, as informações de propriedade (UID / GID) fazem parte do campo extra - pode não ser óbvio se você não sabe hexadecimal, nem que os metadados ZIP são armazenados little-endian, mas para abreviar “e803” é "03e8" com é "1000", o arquivo UID. E "07d0" é "d007", que é 2000, o arquivo GID.

Nesse caso em particular, a ferramenta zip do Info-ZIP disponível no meu sistema Debian armazenou alguns metadados úteis no campo extra. Mas não há garantia de que esse campo extra seja gravado por todos os arquivadores. E mesmo presente, não há garantia de que isso seja entendido pela ferramenta usada para extrair o arquivo.

Considerando que nós não podemos rejeitar tradição como uma motivação para ainda usar tarballs, com este pequeno exemplo, você entende porque ainda existem alguns casos (de canto) onde o alcatrão não pode ser substituído por zip . Isso é especialmente verdadeiro quando você deseja preservar todos os metadados de arquivo padrão.

Alcatrão vs Zip vs Teste de Eficiência Gz

Eu falarei aqui sobre eficiência de espaço, não eficiência de tempo - mas como regra geral, mais potencialmente eficiente é um algoritmo de compressão, mais CPU requer.

E para dar uma idéia da taxa de compactação obtida usando algoritmos diferentes, reuni no meu disco rígido cerca de 100 MB de arquivos de formatos de arquivo populares. Aqui está o resultado obtido no meu sistema Debian Stretch (todo o tamanho conforme relatado por du -sh ):

tipo de arquivojpg.mp3.mp4.odt.png.TXT
número de arquivos216345279299020724397
espaço no disco98 milhões99 milhões99 milhões98 milhões98 milhões98 milhões
alcatrão94 milhões99 milhões98 milhões93 milhões92 milhões89 milhões
zip (sem compressão)92 milhões99 milhões98 milhões91 milhões91 milhões86 milhões
zip (desinflar)87 milhões98 milhões93 milhões85 milhões77 milhões28 milhões
tar + gzip86 milhões98 milhões93 milhões82 milhões77 milhões27 milhões
tar + bz287 milhões98 milhões93 milhões42 milhões71 milhões22 milhões
tar + xz70 milhões98 milhões22 milhões348K51 milhões19 milhões

Em primeiro lugar, encorajo-vos a tirar esses resultados com um enorme grão de sal: os ficheiros de dados eram, na realidade, ficheiros pendurados no meu disco rígido e não os afirmaria serem representativos de qualquer forma. Então, devo confessar que não escolhi esses tipos de arquivo aleatoriamente. Eu já disse isso, arquivos .odt já são arquivos zip. Assim, o ganho modesto obtido pela compactação de uma segunda vez não é surpreendente (exceto para bzip2 ou xy, mas eu consideraria isso como uma anormalidade estatística causada pela baixa heterogeneidade dos meus arquivos de dados - contendo vários backups ou versões de trabalho do mesmo documentos).

Em relação a .jpg, .mp3 e .mp4 agora: talvez você saiba que esses arquivos estão compactados. Melhor ainda, você pode ter ouvido que eles usam compressão destrutiva . Isso significa que você não pode reconstruir exatamente a imagem original após uma compactação JPEG. E isso é verdade. Mas o que é pouco conhecido é após a fase de compressão destrutiva per se, os dados são compactados uma segunda vez usando o algoritmo de comprimento de palavra variável não-destrutivo Huffman para remover a redundância de dados.

Por todas essas razões, esperava-se que a compactação de imagens JPEG ou arquivos MP3 / MP4 não resultasse em altos ganhos. Observe que, como um arquivo típico contém os dados altamente compactados e alguns metadados descompactados, ainda podemos ganhar algo. Isso explica por que ainda tenho um ganho perceptível em imagens JPEG, já que tive muitas delas - portanto, o tamanho geral dos metadados não foi tão insignificante em comparação ao tamanho total do arquivo. Mais uma vez, os resultados surpreendentes ao compactar arquivos MP4 usando xz provavelmente estão relacionados às altas semelhanças entre os vários arquivos MP4 usados ​​durante meus testes. Ou não são eles?

Para eventualmente levantar essas dúvidas, eu recomendo fortemente que você faça suas próprias comparações. E não hesite em compartilhar suas observações conosco usando a seção de comentários abaixo!

Recomendado

Como proteger por senha uma pasta no Linux
2019
Lançamento do Linux Lite 3.0
2019
Jogos fantásticos do Linux e onde encontrá-los
2019