ZIP ou TAR: qual escolher, e porque é que isso importa

A diferença de estrutura, num parágrafo

Um ficheiro TAR é uma pilha. Para cada membro escreve um cabeçalho de 512 bytes — o nome, as permissões, o dono, o tamanho em octal, a data de modificação, uma soma de verificação, um indicador de tipo — depois os bytes do ficheiro e depois enchimento até ao bloco inteiro de 512 bytes seguinte. Dois blocos de zeros marcam o fim. Sem índice, sem compressão e sem contabilidade engenhosa: é esse todo o formato, e quase não mudou desde que foi desenhado para unidades de fita, de onde vem o nome.

Um ZIP é um arquivador. Cada membro é comprimido por si com deflate e escrito com o seu próprio cabeçalho local; no fim do ficheiro vem um diretório central que lista cada membro, o seu tamanho, o seu tamanho comprimido e onde começa. Um leitor abre os últimos quilobytes, lê o diretório e conhece todo o conteúdo sem tocar num byte dos dados. É esse desenho que permite a um cliente de correio mostrar-lhe o interior de um anexo antes de o extrair.

Todo o resto deste artigo decorre desses dois parágrafos. O tamanho, a extração de um só ficheiro, as permissões, as ligações simbólicas, o comportamento perante a corrupção — nada disso é arbitrário, e nada exige decorar uma tabela comparativa assim que se imagina uma pilha de um lado e um arquivador do outro.

Porque é que o .tar.gz ganha com muitos ficheiros pequenos e parecidos

O deflate funciona procurando repetições dentro de uma janela deslizante e substituindo a segunda cópia por uma referência curta. Num ZIP essa janela é reposta no início de cada membro, por isso um compressor que olha para um ficheiro JavaScript de 193 bytes quase não tem com que trabalhar: os imports, o esqueleto e a chaveta final estão nos outros cinquenta e nove ficheiros, e ele nunca os verá. Num .tar.gz entrega-se-lhe um fluxo contínuo de 63 488 bytes onde essas cinquenta e nove cópias estão ali mesmo, a algumas centenas de bytes de distância.

A medição torna-o concreto. Os mesmos sessenta ficheiros: 1 809 bytes em .tar.gz contra 14 686 em .zip. Não é uma questão de afinação. Passar esses sessenta por um escritor ZIP em todos os níveis de compressão de 1 a 9 produziu nove vezes o mesmo arquivo de 14 490 bytes, byte a byte — o botão não está ligado a nada, porque dentro de um ficheiro de 193 bytes não há nada em que o nível máximo se possa esforçar mais. No nível 0, que armazena em vez de comprimir, o ZIP ficava em 18 328 bytes, portanto a compressão faz mesmo alguma coisa; simplesmente fá-lo no sítio errado.

Vire o corpus do avesso e a vantagem evapora-se. Comprima um único ficheiro de texto de 92 KB: 33 202 bytes como ZIP de um membro, 33 110 bytes como gzip — 92 bytes de diferença, três por mil. Não há redundância entre ficheiros quando só há um ficheiro. A regra, portanto, não é «o tar.gz é melhor», é: quantos mais membros e mais pequenos e parecidos forem, maior é a diferença; um só ficheiro grande, diferença nenhuma.

O custo: sem índice, e sem forma de tirar um só ficheiro

A compressão sólida é precisamente a razão por que um .tar.gz não se abre pelo meio. O fluxo comprimido é uma cadeia longa em que o byte um milhão depende de tudo o que vem antes, por isso um programa a quem se pede o último de sessenta ficheiros tem de descomprimir os cinquenta e nove primeiros para lá chegar. Um ZIP faz o contrário: os arquivos construídos para este artigo trazem um registo de diretório central por cada membro, e um leitor salta lá, encontra a posição e descomprime 193 bytes.

A mesma assimetria decide o que acontece quando um arquivo é danificado. Corrompa alguns bytes num ZIP e perde normalmente o membro a que pertencem; o diretório central continua a listar o resto e uma ferramenta de reparação consegue muitas vezes recuperá-lo. Corrompa alguns bytes perto do início de um .tar.gz e tudo o que vem depois do dano fica inalcançável, porque o estado do descompressor desapareceu. Se escreve em suportes pouco fiáveis, ou transfere por uma ligação que cai, essa diferença não tem nada de académica.

Permissões e ligações simbólicas: o que este conversor perdeu mesmo

A árvore de teste não era só sessenta ficheiros. Tinha também um diretório, um ficheiro marcado como executável e uma ligação simbólica a apontar para outro ficheiro. Empacotados pelas ferramentas do sistema, os dois formatos guardaram tudo. O .tar levava um modo 000755 no executável e um indicador de tipo 2 na ligação. O .zip levava 62 entradas de diretório central: os sessenta ficheiros, o diretório como 040755, o executável como 0100755 e latest.js como 0120755 — uma ligação simbólica de dezassete bytes, sendo esses bytes o caminho para onde aponta.

Este último facto merece uma pausa, porque a lenda diz que o ZIP não consegue transportar metadados Unix. Consegue. O formato reserva um campo exatamente para isso, e a ferramenta zip padrão do Unix preenche-o. O que é verdade é que esse campo é facultativo, que é quem escreve que decide se o preenche, e que muitíssimos escritores não o preenchem.

O conversor desta página é um deles, e executá-lo tornou isso visível. O seu leitor de TAR só guarda as entradas cujo indicador de tipo diz «ficheiro normal», por isso o diretório e a ligação simbólica foram descartados sem uma palavra: entraram sessenta membros, saíram sessenta e desapareceram dois objetos. A sua representação interna de um membro é um caminho e um bloco de bytes, sem campo para as permissões: o 000755 do cabeçalho tar não tem para onde ir. Inspecionar o ZIP produzido confirma-o: 60 entradas, todas declaradas como vindas de um sistema tipo DOS, cada campo de permissões a zero. Sem diretório, sem ligação, sem bit de execução.

Para o trabalho a que esta página serve — um .tar.gz que alguém lhe enviou e cujo conteúdo quer numa máquina que não o abre — nada disso importa. Para reempacotar uma entrega, uma cópia de segurança ou qualquer coisa com scripts lá dentro, tudo isso importa, e mais vale reempacotar com as ferramentas do sistema. Saber em qual dos dois casos está é toda a perícia.

Qual é que quem recebe consegue abrir sem instalar nada

É isto que costuma decidir, e a resposta honesta mudou. O ZIP lê-se no Explorador do Windows desde 2001 e no Utilitário de Arquivo do macOS desde o início; nunca houve uma máquina em que enviar um ZIP fosse uma má aposta. Com o TAR era ao contrário: fora do Unix era preciso um programa de terceiros, ou seja, pedir a um colega que instalasse software antes de poder ler o seu anexo.

Essa distância fechou-se. O Windows 11 acrescentou a leitura nativa de .tar, .tar.gz, .tgz, .tar.bz2, .tar.xz, .tar.zst, .rar e .7z no Explorador de Ficheiros, anunciada em 2023 e entregue nas versões seguintes. Num Windows 11 atual, um .tar.gz abre com duplo clique sem instalar nada. O senão é tudo o que não seja um Windows 11 atual: máquinas com Windows 10, imagens empresariais bloqueadas, a pré-visualização web de um cliente de correio, um gestor documental, um telemóvel. O ZIP funciona em todos eles.

A regra prática é, portanto, assimétrica, e não diz qual formato é melhor. Se armazena, implanta ou move ficheiros entre máquinas que controla: .tar.gz — mais pequeno em árvores de código, e guarda os metadados. Se envia a uma pessoa: ZIP, a não ser que saiba o que ela usa. Converter de um para o outro leva segundos, e é para isso que serve a ferramenta desta página; faça apenas a conversão no sentido que não perde nada que lhe importe.

Perguntas frequentes

Um .tgz é a mesma coisa que um .tar.gz?

Sim, byte a byte. .tgz é uma contração que existe porque o MS-DOS só permitia três caracteres depois do ponto, e sobreviveu ao seu motivo. Tudo o que lê um lê o outro. O mesmo vale para .tbz2 e .tar.bz2, .txz e .tar.xz, .tzst e .tar.zst. O conversor daqui fareja os bytes em vez da extensão, por isso aceita qualquer uma dessas grafias — e aceita também um ficheiro cujo nome esteja errado, que é mais vezes a situação real.

Porque é que o meu .tar é maior do que os ficheiros lá dentro?

Porque o TAR não comprime e porque arredonda. Cada membro custa um cabeçalho de 512 bytes mais os seus próprios bytes preenchidos até um bloco inteiro de 512, e o arquivo termina com 1 024 bytes de zeros. Na árvore de teste, isso transformou 11 604 bytes de código num .tar de 63 488 bytes — cinco vezes e meia mais, porque sessenta ficheiros de 193 bytes ocupam cada um um quilobyte completo de cabeçalho e enchimento. Não é um defeito: é o aspeto de um formato pensado para ser escrito em fita em blocos fixos. Comprima-o e o enchimento, feito de zeros, quase desaparece.

Converter um .tar.gz para ZIP vai torná-lo maior?

Muitas vezes sim, e por vezes muito. O sentido da conversão desfaz precisamente o que tornava o .tar.gz pequeno: o arquivo é desempacotado em ficheiros individuais, e depois cada um é comprimido por si. Na árvore de teste de sessenta ficheiros, o ZIP de saída ocupava 14 490 bytes contra 1 809 à entrada — oito vezes mais para o mesmo conteúdo. Se o arquivo tiver alguns ficheiros grandes já comprimidos (fotografias, vídeo, um despejo de base de dados comprimido antes de entrar), a diferença será quase nula. Se tiver uma árvore de código, espere um salto.

O nível de compressão da ferramenta serve para alguma coisa?

Entre «nenhuma» e as outras duas, sim: armazenar em vez de comprimir dava 18 328 bytes contra 14 490 na árvore de teste. Entre «normal» e «máxima», nessa mesma árvore, não — as duas produziram ficheiros idênticos, tal como todos os níveis intermédios. Num único documento de 92 KB, a definição máxima poupou 39 bytes face à predefinida. Os níveis de compressão ganham o seu salário em membros grandes e cheios de texto; num monte de pequenos são um botão ligado a nada. Escolha «nenhuma» quando o conteúdo já estiver comprimido e só quiser um recipiente, e deixe em normal nos restantes casos.

Posso manter as permissões ao converter TAR para ZIP aqui?

Não, e a ferramenta não o diz. A sua representação interna de um membro é um caminho e um bloco de bytes, sem campo para o modo, por isso as permissões dos cabeçalhos tar são lidas de passagem e nunca reescritas; o ZIP produzido para este artigo tinha o campo de permissões a zero nos seus sessenta membros. As ligações simbólicas e as entradas de diretório são descartadas pela mesma razão — só se guardam os membros marcados como ficheiros normais. Se isso importar, reempacote com tar e zip na linha de comandos, onde ambos os formatos transportam os metadados de forma nativa. Se só quer ler o arquivo de alguém numa máquina que não o abre, nada disto o afeta.