Tar Vs Zip Vs Gz: Diferença e eficiência

6 de fevereiro de 2017

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 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 algo fácil de lembrar, aqui está a diferença entre zip e tar e gz:

.tar == arquivo compactado .zip == (normalmente) arquivo compactado .gz == arquivo (arquivo ou não) compactado usando gzip

Tar vs Zip vs GZ! Diferença explicada e desempenho verificado

Um pouco da história dos arquivos de arquivo

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

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

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

Vale a pena mencionar aqui tar certamente não é a única ferramenta Unix padrão para criar arquivos. Os programadores provavelmente conhecem o ar , pois ele é usado principalmente hoje para criar bibliotecas estáticas, que não são mais do que arquivos de arquivos compilados . Mas ar pode ser usado para criar arquivos de qualquer tipo. Na verdade, os arquivos de pacote .deb usados em sistemas Debian são arquivos ar ! E no MacOS X, os pacotes mpkg são (eram?) Arquivos cpio compactados com gzip. Dito isso, nem ar nem cpio ganhou tanta popularidade quanto tar entre os usuários. Talvez porque o comando tar fosse bom o suficiente e mais simples de usar.Arquivo Tar no Linux e UNIX Não é o tipo de tar que você está procurando Criar arquivos é bom. Mas com o passar do tempo e com o advento da era do computador pessoal, as pessoas perceberam que poderiam economizar muito em armazenamento compactando dados. Portanto, uma década após a introdução do tar , o zip foi lançado no mundo do MS-DOS como um formato de arquivo com suporte para compactação . O esquema de compressão mais comum para zip é deflate , que é uma implementação do algoritmo LZ77. Mas, sendo desenvolvido comercialmente pela PKWARE, o formato zi p sofreu com a sobrecarga de patentes por anos.

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

Um elemento chave da filosofia Unix sendo Faça uma coisa e faça bem , gzip foi projetado para apenas compactar arquivos. Portanto, para criar um arquivo compactado , você deve primeiro criar um arquivo usando o utilitário tar , por exemplo. E depois disso, você compactará esse arquivo. Este é um arquivo .tar.gz (às vezes abreviado como .tgz para aumentar novamente a confusão - e para cumprir as limitações de nome de arquivo 8.3 do MS-DOS há muito esquecidas).

Conforme a ciência da computação evoluiu, outros algoritmos de compressão foram projetados para uma taxa de compressão mais alta. Por exemplo, o algoritmo de Burrows – Wheeler implementado em bzip2 (levando a arquivos .tar.bz2 ). Ou mais recentemente xz que é uma implementação de algoritmo LZMA semelhante ao usado 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 tem suporte nativo no Windows, ele está especialmente presente em ambientes multiplataforma. Você pode até encontrar o formato de arquivo zip em lugares inesperados. Por exemplo, esse formato de arquivo foi mantido pela Sun para arquivos 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 arquivo são arquivos zip disfarçados. Se você estiver curioso, não hesite em descompactar um deles para ver o que há dentro:

sh $ unzip some-file.odt Archive: some-file.odt extraindo: mimetype inflando: meta.xml inflando: settings.xml inflando: content.xm [...] inflando: styles.xml inflando: META-INF/manifest .xml Dito isso, no mundo do Unix, eu ainda favoreceria o tipo de arquivo tar porque o formato de arquivo zip não suporta todos os metadados do sistema de arquivo Unix de forma confiável. Para algumas explicações concretas dessa última afirmação, você deve saber que o formato do arquivo ZIP define apenas um pequeno conjunto de atributos de arquivo obrigatórios para armazenar 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. Mas, como os campos extras são definidos pela implementação, não há garantias nem mesmo para os arquivadores compatíveis de armazenar ou recuperar o mesmo conjunto de metadados. Vamos verificar isso em um arquivo de amostra:

sh $ ls -lsn data/equipe total 0 0 -rw-r - r-- 1 1000 2000 0 Jan 30 12:29 equipe sh $ zip -0r arquivo.zip dados/sh $ zipinfo -v arquivo.zip dados Team Central directory entry # 5: Nesse caso particular, a ferramenta Info-ZIP zip disponível em meu sistema Debian armazenou alguns metadados úteis no campo extra. Mas não há garantia de que esse campo extra seja escrito por todos os arquivadores. E mesmo que presente, não há garantia de que seja compreendido pela ferramenta de extração do arquivo.

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

Teste de eficiência Tar vs Zip vs Gz

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

E para dar uma ideia da taxa de compressão obtida usando diferentes algoritmos, reuni no meu disco rígido cerca de 100 MB de arquivos de formatos de arquivo populares. Aqui estão os resultados obtidos em meu sistema Debian Stretch (todos os tamanhos relatados por du -sh ):

tipo de arquivo .jpg .mp3 .mp4 .odt .png .txt número de arquivos 2163 45 279 2990 2072 4397 espaço no disco 98M 99M 99M 98M 98M 98M 98M tar 94M 99M 98M 93M 92M 89M zip (sem compressão) 92M 99M 98M 91M 91M 86M zip (esvaziar) 87M 98M 93M 85M 77M 28M tar + gzip 86M 98M 93M 82M 77M 27M tar + bz2 87M 98M 93M 42M 71M 22M tar + xz 70M 98M 22M 348K 51M 19M!

Primeiro , Encorajo você a considerar esses resultados com muita cautela: os arquivos de dados eram, na verdade, arquivos pendurados no meu disco rígido e eu não reivindicaria que eles fossem representativos de forma alguma. Então, devo confessar que não escolhi esses tipos de arquivo aleatoriamente. Eu já disse, arquivos .odt já são arquivos zip. Portanto, o ganho modesto obtido comprimindo-os uma segunda vez não é surpreendente (exceto para bzip2 ou xy, mas eu consideraria isso como uma anormalidade estatística causada pela baixa heterogeneidade de meus arquivos de dados - contendo vários backups ou versões de trabalho de os mesmos documentos).

Sobre .jpg , .mp3 e .mp4 agora: talvez você saiba que esses são arquivos de dados compactados. Melhor ainda, você deve ter ouvido que eles usam a 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 é que, após a fase de compressão destrutiva per se , os dados são comprimidos uma segunda vez usando o [algoritmo de comprimento de palavra variável de Huffman] não destrutivo (https://en.wikibooks.org/wiki/JPEG_-_Idea_and_Practice/The_Huffman_coding) para remover a redundância de dados.

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

Para acabar com essas dúvidas, eu o encorajo fortemente a fazer suas próprias comparações. E não hesite em compartilhar suas observações conosco usando a seção de comentários abaixo!

Confira também a versão original desse post em inglês
Esse post foi originalmente escrito por Sylvain Leroux e publicado no site itsfoss.com. Tradução sujeita a revisão.

Tar Vs Zip Vs Gz : Difference And Efficiency

Propaganda
Blog Comments powered by Disqus.
Propaganda