Converter ZIP para TAR

Quase ninguém escolhe TAR para economizar espaço. A conversão faz sentido quando a próxima ferramenta entende tarballs, mas não aceita ZIP: uma etapa de build, um processo de implantação, um importador de backup, um script de automação ou um ambiente Unix com uma entrada definida como `.tar`. Nesse cenário, o formato de destino não é uma preferência estética. Ele é parte do contrato de entrada, e mudar o contêiner permite que os mesmos arquivos atravessem o processo sem reescrever o conteúdo de cada um.

Pense no TAR produzido aqui como uma cópia de trabalho. O ZIP original continua sendo a referência que você recebeu, enquanto o tarball serve ao sistema que pediu outro empacotamento. Se esse sistema concluir o build ou a importação corretamente, a conversão cumpriu seu papel mesmo que o arquivo final seja maior. Avaliar apenas a quantidade de megabytes levaria à conclusão errada, porque compatibilidade, e não compressão, é o resultado procurado neste par.

ZIP pode comprimir cada item individualmente, normalmente com DEFLATE, e também pode guardar itens sem compressão. TAR faz outra tarefa: coloca cabeçalhos e conteúdos em sequência, sem aplicar um compressor. Ao passar de ZIP para TAR, os itens compactados são abertos e entram no novo arquivo em seu tamanho normal. Por isso, um ZIP de código-fonte, CSV, logs ou XML pode gerar um TAR várias vezes maior. O crescimento não indica perda nem erro; ele mostra que a camada de compressão deixou de existir.

O efeito é menor quando o ZIP contém JPEG, MP4, PDF ou outros arquivos que já foram comprimidos por seus próprios formatos. Nesses casos, compactar o contêiner quase não reduzia os itens, e o TAR tende a crescer apenas pelo empacotamento e pelo preenchimento dos blocos. Para estimar espaço, consulte o tamanho descompactado informado pelo programa que abre o ZIP e reserve uma margem. Essa estimativa é mais útil que comparar somente os 25 MB permitidos para o upload, pois o limite se aplica à entrada compactada, não ao download TAR.

Um arquivo `.tar` reúne vários caminhos, mas não os comprime. Já o nome `.tar.gz` descreve duas etapas: primeiro os itens entram num TAR; depois esse tarball único é comprimido com gzip. As duas extensões aparecem juntas porque cada formato resolve uma parte do trabalho. Se uma instrução pede literalmente um TAR, entregar um TAR.GZ pode falhar, pois o consumidor teria de remover a camada gzip antes de enxergar os membros do arquivo.

A escolha depende do próximo passo. Um sistema que vai ler o tarball imediatamente, montar um contexto de build ou aplicar sua própria compactação pode precisar do TAR simples. Para transportar ou publicar uma árvore de arquivos, o TAR.GZ geralmente é mais adequado porque devolve a economia de espaço. No Quinvert, escolher GZ como destino para um ZIP cria primeiro um TAR e depois o comprime; esta página, por outro lado, termina deliberadamente no arquivo `.tar`, sem uma segunda camada.

Esta conversão não acontece na aba do navegador. O ZIP é enviado ao serviço de conversão, o 7-Zip lista o tamanho declarado, extrai os membros para um diretório temporário e cria o TAR a partir de dentro desse diretório. Esse último detalhe evita acrescentar uma pasta artificial chamada `src` ou algo parecido. Se o ZIP contém `projeto/config/app.yml`, o caminho correspondente parte de `projeto` no tarball, em vez de ficar escondido sob uma pasta criada pelo conversor.

A estrutura de diretórios comum é reconstruída porque os caminhos dos membros orientam a extração. Ainda assim, o processo não copia o contêiner ZIP para dentro de outro contêiner; ele materializa os itens e os empacota novamente. Essa diferença explica por que informações próprias do arquivo ZIP, como método de compressão de cada entrada, comentário do arquivo e eventual senha, não fazem parte do TAR novo. O objetivo é entregar os arquivos ao destino com seus nomes e bytes, não reproduzir todas as características do pacote de origem.

O par está registrado como conversão sem perda porque os arquivos não passam por recodificação. Uma imagem JPEG continua sendo aquele JPEG; um executável não é recompilado; um documento não é aberto e salvo em outro formato. O 7-Zip extrai os bytes de cada membro e o TAR volta a armazená-los. Isso é diferente de converter uma imagem ou um vídeo, operação em que um decodificador produz pixels ou quadros e um novo codificador toma outras decisões.

A expressão “sem perda” se refere ao conteúdo dos membros, não a todo metadado que o ZIP pudesse carregar sobre eles. Para uma entrega em que a exatidão importa, compare hashes dos arquivos depois de extrair o TAR com os hashes obtidos ao extrair o ZIP original. A comparação deve ser feita item por item, fora dos contêineres: os dois arquivos de pacote sempre terão bytes e tamanhos diferentes. Verifique também a lista de caminhos, pois a validade de um build depende tanto do nome e da posição de cada arquivo quanto do conteúdo.

TAR consegue registrar modo de arquivo, usuário e grupo, mas a conversão só pode escrever os atributos disponíveis depois que o ZIP foi extraído no ambiente do servidor. ZIPs criados no Windows muitas vezes não trazem uma representação Unix completa; mesmo quando há bits de modo no contêiner, o caminho de extração e reempacotamento não oferece uma promessa de preservá-los. Proprietário e grupo do TAR também não devem ser lidos como a identidade de quem criou o ZIP. Eles refletem o ambiente temporário usado pelo processo.

Isso exige atenção em árvores com scripts executáveis. Um `deploy.sh` pode conservar todos os bytes e ainda chegar sem o modo que permite executá-lo diretamente. Se o consumidor depende de permissões específicas, defina-as de forma explícita depois da extração ou, melhor, no próprio processo de build. Um `chmod` no script de preparação, um manifesto de pacote ou uma receita de contêiner é mais confiável que herdar modos de um ZIP produzido em outro sistema operacional. Não use este TAR como prova forense de propriedade ou permissões originais.

Os dois formatos conseguem guardar horários, mas não necessariamente com a mesma semântica, precisão ou conjunto de campos. Como os membros são extraídos antes do novo empacotamento, as datas que entram no TAR são as que o 7-Zip e o sistema de arquivos temporário apresentam nessa etapa. Algumas podem coincidir com o ZIP; outras podem perder precisão ou assumir um valor diferente. A implementação não promete preservar criação, último acesso e modificação como um conjunto idêntico.

Se datas fazem parte do resultado esperado, trate-as como dados que precisam de validação. Isso ocorre em importações que selecionam o item mais recente, backups incrementais, ferramentas que evitam recompilar arquivos considerados antigos e auditorias que usam horário como evidência. Para um build reprodutível, é preferível normalizar timestamps no pipeline em vez de aceitar os valores herdados de um pacote recebido. O conteúdo pode estar correto e o processo ainda se comportar de outro modo por causa de uma data diferente.

Não existe campo para informar senha. O extrator é chamado deliberadamente com uma senha vazia, o que impede que um ZIP protegido abra uma pergunta interativa num processo de servidor sem terminal. Dependendo de como o ZIP foi protegido, a listagem pode falhar ou a recusa pode acontecer durante a extração; em ambos os casos, nenhum TAR utilizável é entregue. A interface apresenta a falha da conversão, mas não deve ser usada como detector preciso de senha, porque um arquivo danificado também pode terminar em uma recusa geral.

Abra o ZIP numa ferramenta local, informe a senha e crie uma cópia sem proteção antes de voltar. Faça isso apenas num aparelho e num local de armazenamento apropriados para o conteúdo. A remoção da senha muda a postura de segurança do arquivo: o TAR resultante também não será criptografado. Se a exigência é transportar o pacote de maneira protegida, use um canal seguro ou aplique criptografia adequada ao artefato depois de produzir e validar o tarball.

O plano gratuito aceita até 25 MB no arquivo ZIP enviado. O serviço que fica dentro do contêiner suporta corpos maiores para outros cenários, mas a camada pública consulta o registro deste par e bloqueia o upload acima de 25 MB; portanto, esse é o limite que vale nesta página. Há ainda uma cota de conversões de servidor por dia e uma proteção contra rajadas de solicitações. Para um ZIP maior, a alternativa correta é converter localmente, sem dividir o arquivo às cegas e depois esperar que as partes formem um TAR válido.

Antes de extrair os membros, o serviço soma os tamanhos descompactados declarados pelo ZIP. Se o total passar de 2 GB, a extração é recusada. Essa barreira reduz o risco de arquivos que parecem pequenos e se expandem até consumir todo o armazenamento, mas não é uma garantia absoluta, pois um pacote hostil pode declarar valores enganosos. Cada chamada ao 7-Zip tem limite de sessenta segundos, e o diretório temporário possui capacidade limitada. Um arquivo pode respeitar os 25 MB de upload e ainda falhar por expansão, tempo ou conteúdo inválido.

Ao contrário das conversões que rodam localmente, o ZIP sai do dispositivo. Ele viaja por uma conexão criptografada até o serviço, é gravado no espaço temporário do trabalho e processado num contêiner sem acesso de saída à internet. O bloqueio de saída é configurado na plataforma, não apenas presumido pelo programa. Isso impede que um documento ou item malicioso dentro do arquivo use o processo de conversão para buscar recursos externos durante o trabalho.

Cada solicitação recebe um diretório próprio, e o bloco `finally` do serviço remove esse diretório tanto em sucesso quanto em erro. Upload, itens extraídos e TAR produzido deixam de existir ali quando o trabalho termina. A resposta também é marcada para não ser armazenada em cache pelo Worker. Essas medidas reduzem exposição, mas não transformam um serviço remoto em processamento local. Para segredos de produção, chaves privadas, dados pessoais sensíveis ou material sujeito a uma política que proíbe upload, faça a extração e o TAR no seu próprio computador.