Converter GZ para XZ

Ninguém converte um arquivo gzipado que está prestes a abrir. Quem chega aqui está olhando para algo que se acumulou: um ano de logs rotacionados, dumps noturnos de banco de dados guardados por exigência de auditoria, um conjunto de dados de pesquisa lido uma vez por trimestre, artefatos de CI que ninguém apagou. Gzip foi a escolha certa quando os arquivos foram escritos — é rápido, está em todo lugar — e não é a escolha certa para a segunda metade da vida do arquivo.

Essa distinção é a decisão inteira. Gzip otimiza o momento de escrever e ler; XZ otimiza os anos entre um e outro. Se o archive vai ser buscado e descompactado por algo com pressa, ou por um dispositivo com pouca memória, deixe como está. Se vai ficar num armazenamento frio e ser lido quase nunca, a conversão é quase dinheiro de graça.

O número no registro é a explicação inteira. O gzip, padronizado como RFC 1952 em maio de 1996, usa DEFLATE com janela de histórico de 32 KB: ao comprimir o byte um milhão, consegue enxergar até o byte novecentos e sessenta e oito mil e nada além disso. Qualquer repetição mais antiga é comprimida de novo do zero. O XZ, de 2009, carrega um dicionário que o registro grava em até 64 MB — dois mil vezes mais alcance.

É por isso que o ganho é enorme em algumas entradas e zero em outras. Um ano de linhas de log repete os mesmos quarenta modelos de mensagem por gigabytes, e o gzip redescobre cada um deles milhares de vezes enquanto o XZ aprende uma vez. Contra isso, um GZ com uma fotografia ou um vídeo não tem repetição de longo alcance para achar, porque a redundância já foi removida pelo JPEG ou H.264 antes de o gzip sequer ver o arquivo.

Tempo de compressão é o custo óbvio e o menos importante, porque é pago uma vez por uma máquina que não está esperando por você. XZ é bem mais lento que gzip na mesma tarefa, consequência direta de vasculhar um dicionário duas mil vezes maior — e para um trabalho rodado de madrugada numa pasta de armazenamento, isso simplesmente não é um problema que vale otimizar.

Memória na descompressão é o custo que realmente decide as coisas, e é o que passa despercebido. Gzip precisa dos seus 32 KB de janela para descompactar, ou seja, quase nada; XZ precisa de um buffer proporcional ao dicionário com que o arquivo foi escrito. Num notebook ou servidor isso não é nada. Num roteador, num dispositivo embarcado pequeno ou num contêiner com limite de memória, é a diferença entre o archive abrir e o processo ser encerrado.

Os dois formatos comprimem exatamente um fluxo, então nenhum dos dois sabe o que é uma pasta. Na prática um `.gz` é quase sempre um `.tar.gz`: um TAR carregando nomes e pastas, com gzip embrulhado por cima. A conversão tira as duas camadas e depois recoloca as duas — os membros são reunidos num TAR novo, e esse TAR é comprimido com xz.

O caso que vale conhecer é quando a origem não era um tarball. Um `acesso.log.gz` simples guarda um único arquivo comum, e a reconstrução ainda monta um TAR ao redor, então o que volta é um tarball contendo `acesso.log` em vez de um arquivo comprimido isolado. Isso é inofensivo se você descompacta com `tar xJf` e confuso se você recorre a `unxz` e encontra um arquivo chamado `output.tar`.

Um fluxo gzip tem um campo de cabeçalho para o nome do arquivo original, e é por isso que descompactar `dump.gz` numa máquina Unix pode devolver `dump.sql` mesmo sem nada na extensão avisar. XZ não tem esse campo: guarda uma verificação de integridade e nada sobre de onde os dados vieram.

Isso tem consequência prática nos dois lados desta conversão e já causou um defeito real neste conversor, registrado no código: como o gzip guarda um nome e o xz não, um tarball interno chega de um GZ com um nome sensato e de um XZ com o nome que o extrator escolheu. A correção foi forçar o tipo tar em vez de inferir pelo nome. Para você, a lição é mais simples: a extensão que você põe no XZ baixado é a única identificação que ele vai carregar, então nomeie como `algo.tar.xz` e mantenha assim.

Os dois formatos se verificam sozinhos, e é por isso que esta conversão é segura de rodar sem supervisão. Um fluxo gzip termina com um CRC-32 e o comprimento sem compressão; um fluxo XZ carrega sua própria verificação, CRC-64 por padrão. Nos dois casos, um download truncado ou um bit invertido produz um erro na descompressão em vez de um arquivo que silenciosamente lê incompleto.

O que nenhum dos dois consegue fazer é dizer qual arquivo está danificado, porque nessa camada não existem arquivos — só um fluxo. Um ZIP ou um 7Z registra um checksum por item e pode relatar que um membro entre quarenta está corrompido; um fluxo comprimido só consegue dizer que o fluxo está corrompido.

Esta conversão não roda no seu aparelho. A maioria das ferramentas deste site mantém o arquivo local e diz isso; reempacotar archives é uma das exceções, porque o trabalho precisa de 7-Zip e xz como programas de verdade. O arquivo viaja por conexão criptografada até um contêiner que roda esses programas e não tem acesso próprio à internet.

Cada job recebe um diretório de trabalho num sistema de arquivos baseado em memória, apagado assim que o job termina, e qualquer coisa ainda rodando depois de sessenta segundos é encerrada. O plano gratuito aceita 25 MB por arquivo enviado, o que para um archive gzipado de logs de texto é bastante coisa, mas é um teto real para um conjunto de dados.

BZ2 é a outra resposta tradicional para «o gzip não está comprimindo o bastante», e na maior parte do texto hoje ele perde para o XZ nos dois eixos ao mesmo tempo — uma razão pior e uma descompressão mais lenta. O registro marca BZ2 como legado por esse motivo. Sua única vantagem restante é o outro lado do ponto acima sobre memória: o bzip2 trabalha em blocos de até 900 KB, então descompactar um nunca precisa de muita memória.

Então a escolha não é realmente sobre razão de compressão. Escolha XZ quando a máquina que vai descompactar o archive for um computador comum, o que costuma ser o caso, e escolha BZ2 só quando não for — um equipamento antigo, um contêiner limitado, um sistema onde xz genuinamente não está instalado e não pode estar.

Faça um arquivo primeiro e olhe os dois tamanhos. Um único archive representativo diz mais sobre o que o resto da pasta vai fazer do que qualquer regra geral, porque a resposta é decidida pelo conteúdo, não pelos formatos — a mesma conversão que corta pela metade um archive de logs não faz nada com uma pasta de fotografias. Se o primeiro arquivo mal se move, pare.

Depois confira a listagem, não só o tamanho. Rode `tar tJf` no resultado e compare a contagem de entradas e os caminhos com o que o GZ tinha, principalmente o nível superior: um archive empacotado de dentro de uma pasta e um empacotado da pasta pai diferem por uma pasta a mais em todo caminho, e essa diferença quebra scripts muito depois de qualquer um lembrar de ter convertido algo.