Comprimir arquivos antes de enviar: reduza tamanho e tempo

Comprima texto, código fonte, registos, CSVs e formatos de imagem não comprimidos como .bmp ou .tiff antes de enviar — espere redução de 3-10x no tamanho. Não comprima .jpg, .png, .mp4, .mp3, .docx, .xlsx, .pdf ou ficheiros .zip — já estão comprimidos internamente, e uma segunda passagem poupa no máximo 2-3% enquanto gasta CPU. Para agrupar muitos ficheiros pequenos numa única transferência use .zip em modo store (sem compressão). Para o melhor rácio em dados comprimíveis, o 7z com LZMA2 normalmente supera o .zip em 30-40%. O RAR é amplamente equivalente ao 7z mas requer que o destinatário tenha o WinRAR ou 7-Zip instalado — o .zip tem suporte universal.

Quando a compressão realmente ajuda

Os ficheiros de texto comprimem dramaticamente. Um .log de servidor de 10 MB frequentemente encolhe para 800 KB com .zip (12x), e para 550 KB com 7z (18x). A compressão funciona porque os registos contêm padrões altamente repetitivos — marcas de tempo, endereços IP, códigos de estado HTTP — que os algoritmos de compressão exploram eficientemente.

Categorias igualmente comprimíveis: código fonte (.js, .py, .java, .cs, .go) tipicamente 3-5x; dados CSV 4-10x; JSON/XML 5-8x por causa dos nomes de campo repetidos; imagens não comprimidas .bmp (5-10x), .tiff sem compressão (4-8x); bases de dados como dumps .sql e ficheiros SQLite com páginas livres (2-4x); PSD com camadas planas 2-3x se ainda não estiver com RLE interno. Um tarball de repositório Git de um projecto de dimensão moderada comprime frequentemente 4-5x, e é por isso que git archive empacota a árvore em .tar.gz por predefinição.

Quando a compressão é inútil

Os formatos já comprimidos não ficam menores — a entropia já está perto do mínimo teórico após DEFLATE, H.264, quantização DCT do JPEG ou esquema semelhante.

Ficheiros que não beneficiam: .jpg, .jpeg, .heic (compressão com perdas já aplicada), .png (DEFLATE integrado), .mp4, .mov, .mkv (H.264/H.265), .mp3, .aac, .flac, .ogg (áudio já comprimido), .pdf (streams de objectos tipicamente comprimidos com DEFLATE), .docx, .xlsx, .pptx (na verdade são arquivos ZIP de XML — recomprimir é redundante), .zip, .7z, .rar, .gz, .bz2, .xz (arquivos comprimidos; outra passagem é fútil), .apk, .jar, .war (arquivos Java/Android baseados em ZIP).

Comprimir estes ficheiros desperdiça CPU e por vezes aumenta ligeiramente o tamanho do ficheiro por causa da sobrecarga dos metadados do arquivo.

ZIP vs 7z vs RAR: qual escolher

| Formato | Rácio típico | Velocidade | Compatibilidade | Encriptação | |---|---|---|---|---| | .zip (DEFLATE) | Base | Rápido | Universal (nativo Windows, macOS, Linux) | ZIP 2.0 (fraco), AES-256 (ferramentas modernas) | | 7z (LZMA2) | 30-40% melhor que .zip | Mais lento | Requer 7-Zip, Keka ou The Unarchiver | AES-256 integrado | | .rar (RAR5) | ~25-35% melhor que .zip | Médio | Requer WinRAR ou 7-Zip; criar não é gratuito | AES-256 integrado | | .tar.gz | Semelhante ao .zip | Rápido | Nativo macOS, Linux; 7-Zip no Windows | Nenhum nativo | | .tar.zst (Zstandard) | Entre .zip e 7z | Muito rápido | Requer zstd (ainda não universal) | Nenhum nativo |

Para portabilidade, o .zip é a escolha mais segura. Para rácio máximo, o 7z ganha. Para velocidade e eficiência moderna, o Zstandard (.zst) é excelente mas os destinatários precisam de ferramentas que o suportem.

Modo "store" para agrupamento e encriptação de arquivo

Se está a enviar 200 fotografias .jpg numa transferência, ainda quer que estejam num único arquivo para o destinatário clicar em "transferir" uma só vez. Use .zip com nível de compressão 0 (modo "store") — o arquivo é a soma dos tamanhos dos ficheiros mais alguns kilobytes de sobrecarga, e o custo de CPU para o criar é quase zero. No 7-Zip: Adicionar ao arquivo → Nível de compressão → Armazenar. Na linha de comandos: zip -0 bundle.zip *.jpg.

Para conteúdos sensíveis, os ficheiros ZIP protegidos por palavra-passe usando AES-256 (não a encriptação legada ZIP 2.0, que é criptograficamente quebrada) são um transporte razoável. Mas não envie a palavra-passe por e-mail na mesma mensagem que o ZIP — partilhe-a via Signal, iMessage ou um canal separado. Melhor ainda: use um serviço de transferência com protecção por palavra-passe integrada como o HexaTransfer.

Compromisso de CPU vs rede, e compressão com perdas

A compressão é um compromisso tempo/tamanho. A compressão máxima do 7z num arquivo de texto de 5 GB pode demorar 30 minutos num portátil e poupar 2 GB. Se a transferência tem restrição de tamanho (um serviço com limite de 2 GB), vale a pena. Se a transferência tem restrição de tempo e a largura de banda é barata, os mesmos 5 GB carregam em 90 segundos por fibra — a meia hora de compressão teria custado mais tempo do que poupou. Heurística: comprima quando a rede é lenta em relação à CPU; não se incomode quando a rede é rápida.

Por vezes o objectivo não é compressão de arquivo mas compressão de formato de ficheiro: um .wav de 200 MB torna-se um .mp3 de 15 MB a 320 kbps; uma .tiff de 60 MB torna-se um .jpg de alta qualidade de 5 MB; um vídeo 4K .mov recodificado para H.265 pode encolher 3-5x. Use isto com discernimento — para ficheiros master, a conversão com perdas destrói informação. Ferramentas: FFmpeg para vídeo/áudio, Handbrake para vídeo, ImageMagick para imagens.

O que o serviço de transferência faz e a decisão pelo conteúdo

O HexaTransfer e serviços de conhecimento zero semelhantes não conseguem comprimir conteúdos do lado do servidor porque recebem texto cifrado. A compressão tem de acontecer no cliente antes da encriptação — depois de encriptado, o texto cifrado parece aleatório e é incomprimível. Isto significa que a compressão do lado do cliente é a única forma de reduzir o tamanho ao usar um serviço E2EE.

O principal erro é o reflexo de "comprimir sempre antes de enviar". Para um cliente a receber 20 documentos .pdf, um pacote ZIP é prático. Para um cliente a receber um único .mp4 de 800 MB, o ZIP desperdiça tempo de ambos os lados. Em caso de dúvida: envie em bruto. O destinatário pode sempre comprimir depois de receber. Se estiver a agrupar múltiplos ficheiros, use .zip em modo store. Se o conteúdo for pesado em texto, use 7z para poupança real.

Conclusão

Comprima quando os dados são comprimíveis — texto, registos, código fonte, bases de dados. Não comprima quando os dados já estão comprimidos — fotografias, vídeos, áudio, PDFs, documentos de escritório. Para agrupamento, use ZIP em modo store. Para rácio máximo em texto, use 7z com LZMA2. Encripte com palavras-passe de arquivo AES-256 apenas como complemento a um canal de transferência seguro, não como substituto.

Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.