Resumen

  • RFC 1952 no define el archivo gzip como un único bloque: permite una serie de miembros consecutivos, cada uno con cabecera, bloques comprimidos y tráiler propios.
  • Añadir otro miembro válido extiende la salida descomprimida sin reescribir el prefijo, pero no crea un índice, acceso aleatorio ni compresión óptima entre miembros.
  • CRC32 e ISIZE verifican datos y longitud módulo 2^32 dentro de un miembro. Los nombres, comentarios y fechas opcionales tampoco prueban procedencia.

El apéndice que no requiere abrir el pasado

Pensemos en un registro comprimido que ya ocupa gigabytes. Para añadir una nueva jornada hay dos posibilidades. Se puede descomprimir y recomprimir todo, o se puede escribir al final un nuevo flujo gzip completo. En el segundo caso, los bytes antiguos conservan su posición y su huella; el resultado lógico, sin embargo, crece cuando un lector procesa ambos miembros.

RFC 1952 hace de esa operación parte del formato. Un archivo gzip contiene una serie de miembros pegados uno tras otro, sin índice exterior ni separador añadido. Cada miembro proporciona su propia estructura de inicio y cierre. El lector sabe continuar porque el siguiente byte puede volver a ser el comienzo reconocible de otro miembro.

El registro del RFC Editor identifica a P. Deutsch como autor, mayo de 1996 como fecha y «Informational» como estado. No es un estándar de la vía Standards Track. El documento fija una especificación y reglas de conformidad; no certifica que todo programa posterior comparta cada decisión práctica.

Sus objetivos eran portabilidad, procesamiento en flujo con almacenamiento intermedio limitado, implementación libre de patentes y compatibilidad con gzip. El acceso aleatorio quedó fuera. Esta última exclusión evita una lectura anacrónica: poder concatenar unidades no equivale a poder saltar directamente a cualquiera de ellas.

La cabecera no concede la misma fuerza a todos sus campos

Dos octetos fijos identifican el formato. CM selecciona el método y el valor 8 señala DEFLATE. Los bits de FLG anuncian campos opcionales; los reservados deben ser cero. Esas reglas permiten que productores y consumidores independientes encuentren la carga comprimida con el mismo recorrido.

Después aparecen datos menos vinculantes. MTIME puede indicar una fecha; cero declara que no existe. FNAME puede guardar un nombre original y FCOMMENT una observación humana. FEXTRA se delimita mediante una longitud para que un lector pueda omitir subcampos desconocidos. FTEXT ofrece una indicación tentativa. El código de sistema operativo puede ignorarse.

La diferencia entre transportar y demostrar es decisiva. Un nombre dentro de la cabecera no autentica el origen. Una fecha no prueba cuándo se incorporó el miembro al archivo actual. Un comentario no establece custodia. Son metadatos útiles bajo una relación de confianza externa, no una firma incorporada.

FHCRC, si existe, toma los dieciséis bits bajos del CRC32 de los bytes anteriores de la cabecera. El tráiler contiene el CRC32 de los datos sin comprimir y un ISIZE de 32 bits. Son tres superficies: integridad reducida de cabecera, detección de corrupción en el contenido recuperado y residuo de longitud.

El módulo impide convertir tamaño en certeza absoluta

ISIZE guarda la longitud original módulo 2^32. Por eso no es un contador absoluto para entradas arbitrariamente grandes. Además, cada miembro tiene su propio ISIZE. El total de un archivo concatenado se obtiene procesando y sumando miembros, no leyendo una cifra global del último tráiler.

CRC32 tampoco identifica al productor. Un accidente puede cambiar los datos y romper la comparación; quien crea deliberadamente un miembro puede calcular un CRC coherente. El éxito dice «estos bytes concuerdan con este control», no «esta persona autorizada escribió estos bytes».

La carga utiliza una capa distinta. RFC 1951 especifica DEFLATE. RFC 1950 define zlib, otra envoltura de DEFLATE con cabecera y Adler-32 propios. RFC 6713 registró después los tipos application/gzip y application/zlib, distinguiendo la orientación de archivo de gzip frente al formato de flujo zlib.

Separar método y envoltura evita que una mejora local invada todo el sistema. El decodificador DEFLATE no necesita decidir si debe restaurar un nombre. El miembro gzip puede declarar metadatos sin modificar los códigos comprimidos. La modularidad no elimina los límites; los hace nombrables.

Una implementación confirma la utilidad y revela el coste

El manual de GNU gzip explica que varios archivos comprimidos pueden concatenarse y que gunzip extrae todos sus miembros. También señala que comprimir las entradas juntas suele producir mejor compresión y que --list informa del CRC y tamaño sin comprimir del último miembro, no del conjunto.

Así nace una discrepancia legítima entre herramientas. La orden de descompresión recorre la secuencia; la orden de listado ofrece una vista más estrecha. Un sistema de seguridad que interprete esa vista como inventario completo puede omitir datos sin que el archivo viole el formato.

El uso como codificación HTTP aparece en RFC 9110, que remite a RFC 1952 para gzip. La referencia conserva el significado del formato, pero no demuestra una conducta idéntica en todos los proxies, clientes o escáneres. Esa variación requiere pruebas de implementación.

El acuerdo mínimo está en la costura

Running-Code Primacy permite separar documento, código y operación. El RFC prueba la estructura publicada; GNU gzip prueba un comportamiento mantenido y documentado. Ninguno autoriza a generalizar sobre cada instalación.

Minimum Initial Specification ayuda a ver por qué la especificación puede ser pequeña sin ser ambigua. Identificación, método, longitudes, bits reservados y tráiler deben coincidir. Mostrar el comentario o usar el código de sistema operativo puede seguir siendo local.

Reality Layers aporta la distinción final. «Un archivo» es la capa simbólica. La realidad ejecutable puede contener varios miembros, cierres y afirmaciones descriptivas. El nombre común no desaparece, pero ya no basta para describir el control.