Compresión sin pérdida

La compresión sin pérdida reduce el tamaño del archivo preservando cada byte del original. La descompresión produce una salida bit a bit idéntica a la entrada. Contrapartida: menos ahorro que la compresión con pérdida — normalmente una reducción de tamaño del 30-70% dependiendo del contenido.

Cómo funciona: los algoritmos sin pérdida encuentran patrones estadísticos (subcadenas repetidas, secuencias predecibles) y los codifican con representaciones más cortas. Dos familias clásicas:

• Basados en diccionario (LZ77, LZ78, LZW): construyen un diccionario de subcadenas vistas y emiten referencias inversas. La base de DEFLATE, gzip, ZIP.
• Codificación de entropía (Huffman, codificación aritmética, ANS): asignan códigos binarios más cortos a los símbolos más frecuentes. Típicamente combinados con métodos de diccionario.

Formatos sin pérdida comunes:

• PNG — imágenes (usa DEFLATE)
• FLAC — audio (preserva PCM de 16-24 bits, típicamente el 50-60% del tamaño de WAV)
• ZIP, gzip, Brotli, Zstandard — datos generales
• WebP y AVIF — ambos admiten modos sin pérdida
• Archivos pack de Git — almacenamiento de repositorios de código fuente

Usa sin pérdida cuando necesites reproducción bit a bit perfecta, cuando el contenido se vaya a editar más adelante, o cuando el archivo sea texto o datos estructurados (que de todas formas no se comprimen bien con pérdida).

El techo teórico de la información: el artículo de 1948 de Claude Shannon estableció que la compresión sin pérdida no puede bajar de la entropía de la fuente — la información media por símbolo. Para datos aleatorios (bytes aleatorios, texto cifrado, archivos ya comprimidos), la entropía es máxima y la compresión sin pérdida logra básicamente cero ahorro. Por eso “gzip image.jpg” no gana casi nada; los bytes JPEG ya parecen aleatorios para un compresor. El corolario: si tu ratio de compresión es sospechosamente bueno en datos que deberían ser de alta entropía, probablemente encontraste un bug.

Sin pérdida sobre datos con pérdida — cuándo vale la pena: una confusión común es recurrir a FLAC sobre una fuente MP3 de 128 kbps, esperando mejor calidad de audio. El MP3 ya descartó información; FLAC solo preserva sin pérdida la versión descartada. Para audio que se originó como PCM de 16 bits (CDs, masters de estudio), FLAC es la elección de archivo correcta. Para audio que se originó con pérdida, transcodificar a FLAC solo infla el archivo. La regla general: almacena el master en el formato sin pérdida de mayor calidad que admita la fuente; entrega a través del mejor formato con pérdida que pueda reproducir el consumidor. Relacionado: DEFLATE, con pérdida, entropía. Referencia: Shannon CE, A Mathematical Theory of Communication (Bell Syst Tech J, 1948).

Ejemplo práctico: comprimir un archivo de registro de 10 MB

Un típico registro de aplicación de 10 MB (líneas JSON con marcas de tiempo, nivel, mensaje, nombres de campo repetidos) es altamente redundante. Números reales de un benchmark reciente sobre la misma entrada: gzip nivel predeterminado ≈ 1,6 MB (reducción del 84%, codificación en 0,2 s), Brotli nivel 6 ≈ 1,1 MB (89%, 0,5 s), Zstandard nivel 3 ≈ 1,3 MB (87%, 0,05 s), Zstandard nivel 19 ≈ 0,9 MB (91%, 1,8 s). Los bytes aleatorios (10 MB de /dev/urandom) se comprimen a unos pocos bytes de 10 MB en cada algoritmo — incompresibles por su alta entropía. Las imágenes PNG ya existentes se reducen otro 1-3% bajo gzip -9, razón por la que los servidores HTTP normalmente omiten Content-Encoding: gzip en respuestas PNG/JPEG/MP4 para ahorrar CPU.

Elegir un algoritmo en 2026

Para entrega web: Brotli a calidad 5-6 para activos estáticos (mejor ratio a tiempo de codificación aceptable, compatible con todos los navegadores modernos desde 2017), gzip como alternativa para clientes heredados. Para almacenamiento interno y pipelines: Zstandard, que domina la frontera de Pareto ratio de compresión vs velocidad en la mayoría de los niveles de calidad y ahora es el valor predeterminado en tar, módulos del kernel de Linux, RocksDB y el formato de paquete npm. Para archivado de masters irrecuperables: sigue usando un envoltorio que incluya una suma de verificación (xz con SHA-256, o zip con CRC + SHA-256 externo) — la compresión en sí no detecta la putrefacción de bits. Referencia: RFC 8878 — Compresión Zstandard y el tipo de medio application/zstd.