Converter TAR para GZ

TARs simples são mais raros que os compactados e aparecem em lugares reconhecíveis. O `docker save` grava um. Scripts de backup instruídos a empacotar mas não a comprimir gravam um. Alguns fluxos de NAS e fita produzem um porque a compressão acontece em outro ponto da cadeia. E gente grava um por acidente, porque `tar cf` e `tar czf` diferem por um único caractere, e só um deles deixa o arquivo menor.

O resultado é um arquivo que é aproximadamente a soma de tudo que está dentro dele mais uma quantidade surpreendente de sobrecarga. Isso é tranquilo num disco local e caro em qualquer outro lugar: num upload por conexão lenta, num bucket que cobra por gigabyte-mês, num limite de anexo de e-mail, num cache de CI buscado a cada build. Esta conversão é o único reempacotamento deste site em que a resposta é quase sempre sim, porque não há custo de compatibilidade — `.tar.gz` é mais universalmente entendido do que um `.tar` puro.

A estrutura do TAR é de 1979 e é encantadoramente simples: um cabeçalho de 512 bytes descrevendo um arquivo, depois o arquivo em si preenchido até o próximo limite de 512 bytes, depois o próximo cabeçalho, e dois blocos de zeros no final marcando o término. Nada é comprimido e nada é indexado. O formato foi desenhado para drives de fita, onde blocos de tamanho fixo eram o ponto.

O custo disso aparece em arquivos pequenos. Um arquivo de um byte ocupa 1.024 bytes num TAR — um bloco de cabeçalho completo e um bloco de dados completo. Dez mil arquivos de configuração, código-fonte ou documentos JSON com uma média de algumas centenas de bytes cada carregam vários megabytes de cabeçalhos e preenchimento que não contêm informação nenhuma. O gzip é extremamente bom exatamente nisso: longas sequências de bytes zero comprimem para quase nada, então boa parte da economia num arquivo de muitos arquivos pequenos vem de remover sobrecarga em vez de comprimir o conteúdo.

O gzip usa DEFLATE com uma janela de histórico de 32 KB, que é o número que decide tudo sobre esta conversão. Dentro de qualquer trecho de 32 KB, ele encontra sequências repetidas e substitui elas por referências, e depois codifica em Huffman o que sobrou. Em texto, código, logs, XML, JSON e configuração, isso é uma economia grande e confiável.

O que ele perde é repetição de longo alcance. Se o mesmo cabeçalho de licença aparece em duzentos arquivos espalhados por um tarball de 40 MB, o gzip comprime ele duzentas vezes separadamente porque nunca consegue ver dois deles ao mesmo tempo. Essa é a lacuna que o XZ e o 7Z existem para fechar, e é por isso que eles vencem o gzip substancialmente em arquivos com muitos arquivos parecidos. A resposta do gzip é que ele é rápido, faz streaming, e está instalado em absolutamente tudo — o que, para um arquivo sendo movido em vez de armazenado, normalmente é a troca melhor.

Vale dizer isso claramente porque surpreende quem espera um envelope colocado ao redor do arquivo existente. A conversão descompacta o TAR que você envia, depois grava um novo TAR a partir do conteúdo extraído e comprime esse com gzip. Os arquivos internos são idênticos byte a byte; o tarball ao redor deles é novo.

Duas consequências seguem disso. Primeiro, um checksum publicado contra o TAR original não vai bater com nada aqui, porque você não está mais com o TAR original — se um hash precisa ser verificado, comprima o arquivo com `gzip` na sua própria máquina em vez disso, o que deixa o tarball intocado. Segundo, o que o contêiner antigo registrava sobre seus membros pode mudar: a nota do registro para este par diz exatamente isso, e permissões e timestamps são os campos em risco. Para um pacote de código-fonte ou um arquivamento de documentos, isso é irrelevante, e para um artefato de implantação, não é.

Um fluxo gzip tem um campo de cabeçalho para o nome do arquivo original, o que explica `gunzip backup.gz` numa máquina Unix poder produzir um arquivo chamado `backup.tar` mesmo nada no comando tendo dito isso. É uma pequena cortesia que o formato oferece, e o motivo de um arquivo gzip ser um pouco menos anônimo que um xz ou bzip2, que não guardam nome nenhum.

Não confie nisso para nada importante. Várias ferramentas gravam um nome genérico nesse campo, várias outras ignoram na extração, e um arquivo transferido por um sistema que reescreve pacotes perde isso completamente. A extensão que você dá ao download é o rótulo que realmente vai ser lido, então faça ela `.tar.gz` em vez de `.gz`, e poupe quem está do outro lado de desembrulhar um mistério.

Um fluxo gzip é decodificado do início ao fim com uma janela fixa de 32 KB e sem índice nenhum, o que parece uma limitação e é a fonte da sua maior vantagem. Significa que o arquivo pode ser consumido conforme chega: `curl https://… | tar xzf -` descompacta um download que nunca toca o disco, um backup pode ser encanado direto para o gzip e para um host remoto, e um coletor de logs pode comprimir na hora sem saber quanto dado vem por aí.

O registro sinaliza isso no próprio formato, e é o motivo de o gzip não ter sido substituído por nada mais forte em vinte anos de tentativas. Formatos com dicionário grande precisam de memória proporcional a ele; formatos com um diretório central precisam do final do arquivo antes de conseguir listar o começo. Se o seu tarball vai ser encanado, servido por HTTP, ou descompactado por algo pequeno, o gzip não é a escolha de meio-termo — é a escolha correta.

Os três não estão em ordem de melhor para pior; estão em pontos diferentes da mesma curva. O gzip é o mais rápido para comprimir e descomprimir e dá a menor economia. O XZ dá de longe a maior economia em texto, a um custo grande de tempo de compressão e de memória para descompactar. O BZ2 fica entre os dois em taxa, é lento para descomprimir, e o registro marca ele como legado.

Decida pelo que acontece com o arquivo em seguida. Algo que vai ser buscado e descompactado repetidamente, por máquinas que você não controla, por um cano — gzip. Algo que vai ficar em armazenamento frio por anos e ser lido quase nunca — XZ. Algo que precisa bater com um nome de artefato que um sistema de build já espera — o que esse nome disser, sem raciocínio necessário. Converter um tarball é barato o bastante para testar dois e comparar os tamanhos ser uma forma legítima de decidir.

Não para o seu navegador. A maioria das ferramentas aqui roda no seu próprio aparelho e diz isso; reempacotamento de arquivo é uma das exceções, porque precisa do 7-Zip e do gzip como programas de verdade. O arquivo viaja por uma conexão criptografada até um contêiner que roda eles e não tem acesso de saída à internet.

Cada trabalho recebe um diretório temporário num sistema de arquivos baseado em memória, apagado quando o trabalho termina, qualquer que seja o resultado, e qualquer coisa ainda rodando depois de sessenta segundos é encerrada em vez de deixada moendo. O plano gratuito aceita 25 MB por arquivo enviado, e este é o par em que esse limite morde mais forte — um TAR não tem compressão, então 25 MB de TAR são 25 MB de conteúdo real, onde 25 MB de 7Z podem ser dez vezes mais.

`tar xzf arquivo.tar.gz` trata as duas camadas numa única passada no macOS, Linux e nos BSDs, e o Windows moderno traz um `tar` que faz o mesmo pelo PowerShell ou pelo prompt de comando. Compactadores gráficos no Windows normalmente desembrulham a camada gzip e deixam você com um `.tar` para abrir de novo, comportamento que faz gente procurar um formato de contêiner único no lugar.

Antes de o original ir embora, compare a listagem: `tar tzf` no resultado contra `tar tf` na origem, mesma contagem e mesmos caminhos. O nível superior é o que vale olhar, porque um arquivo empacotado de dentro de uma pasta e um empacotado a partir da pasta pai diferem por uma pasta líder em cada entrada, e um script que esperava um e recebeu o outro falha meses depois por motivos que ninguém mais lembra. Assim que as duas listagens baterem, o TAR sem compressão não tem mais trabalho a fazer.