Compressão sem perdas

Compressão sem perdas reduz o tamanho do arquivo preservando todos os bytes do original. A descompressão produz saída bit a bit idêntica à entrada. Custo: economias menores que a compressão com perdas — tipicamente 30-70% de redução de tamanho dependendo do conteúdo.

Como funciona: algoritmos sem perdas encontram padrões estatísticos (substrings repetidas, sequências previsíveis) e os codificam com representações mais curtas. Duas famílias clássicas:

• Baseada em dicionário (LZ77, LZ78, LZW): constrói um dicionário de substrings vistas e emite referências anteriores. A base de DEFLATE, gzip, ZIP.
• Codificação de entropia (Huffman, codificação aritmética, ANS): atribui códigos binários mais curtos a símbolos mais frequentes. Tipicamente combinada com métodos de dicionário.

Formatos comuns sem perdas:

• PNG — imagens (usa DEFLATE)
• FLAC — áudio (preserva PCM de 16-24 bits, tipicamente 50-60% do tamanho do WAV)
• ZIP, gzip, Brotli, Zstandard — dados gerais
• WebP e AVIF — ambos suportam modos sem perdas
• Arquivos de pacote Git — armazenamento de repositório de código-fonte

Use sem perdas quando precisar de reprodução bit a bit perfeita, quando o conteúdo será editado posteriormente ou quando o arquivo é texto/dados estruturados (que não comprimem bem com perdas de qualquer forma).

O teto teórico da informação: o artigo de 1948 de Claude Shannon estabeleceu que a compressão sem perdas não pode descer abaixo da entropia da fonte — a informação média por símbolo. Para dados aleatórios (bytes aleatórios, texto cifrado criptografado, arquivos já comprimidos), a entropia é máxima e a compressão sem perdas alcança essencialmente zero de economia. É por isso que “gzip image.jpg” não ganha quase nada; os bytes JPEG já parecem aleatórios para um compressor. O corolário: se sua taxa de compressão for suspeitosamente boa em dados que deveriam ter alta entropia, você provavelmente encontrou um bug.

Sem perdas em dados com perdas — quando vale a pena: uma confusão comum é optar por FLAC sobre uma fonte MP3 de 128 kbps, esperando melhor qualidade de áudio. O MP3 já descartou informações; o FLAC apenas preserva sem perdas a versão descartada. Para áudio que se originou como PCM de 16 bits (CDs, masters de estúdio), o FLAC é a escolha certa de arquivamento. Para áudio que se originou com perdas, transcodificar para FLAC apenas infla o arquivo. A regra geral: armazene o master no formato sem perdas de maior qualidade que a fonte suporta; entregue via o melhor formato com perdas que o consumidor pode reproduzir. Relacionado: DEFLATE, compressão com perdas, entropia. Referência: Shannon CE, A Mathematical Theory of Communication (Bell Syst Tech J, 1948).

Exemplo prático: comprimindo um arquivo de log de 10 MB

Um log de aplicação típico de 10 MB (linhas JSON com timestamps, nível, mensagem, nomes de campo repetidos) é altamente redundante. Números reais de um benchmark recente no mesmo input: gzip nível padrão ≈ 1,6 MB (84% de redução, 0,2 s de codificação), Brotli nível 6 ≈ 1,1 MB (89%, 0,5 s), Zstandard nível 3 ≈ 1,3 MB (87%, 0,05 s), Zstandard nível 19 ≈ 0,9 MB (91%, 1,8 s). Bytes aleatórios (10 MB de /dev/urandom) comprimem para dentro de alguns bytes de 10 MB em cada algoritmo — incompressível porque tem alta entropia. Imagens PNG já existentes encolhem mais 1-3% sob gzip -9, razão pela qual servidores HTTP normalmente ignoram Content-Encoding: gzip em respostas PNG/JPEG/MP4 para economizar CPU.

Escolhendo um algoritmo em 2026

Para entrega web: Brotli na qualidade 5-6 para ativos estáticos (melhor taxa em tempo de codificação aceitável, suportado em todos os navegadores modernos desde 2017), gzip como fallback para clientes legados. Para armazenamento interno e pipelines: Zstandard, que domina a fronteira de Pareto taxa de compressão vs velocidade na maioria dos níveis de qualidade e agora é o padrão em tar, módulos do kernel Linux, RocksDB e o formato de pacote npm. Para arquivamento de masters insubstituíveis: ainda use um wrapper que inclua checksum (xz com SHA-256, ou zip com CRC + SHA-256 externo) — a compressão em si não detecta corrupção de bits. Referência: RFC 8878 — Compressão Zstandard e o tipo de mídia application/zstd.