Résumé

  • Dans RFC 1952, un fichier gzip est une suite de membres complets. Chacun porte son en-tête, ses blocs compressés et sa propre bande de fin CRC32/ISIZE.
  • Cette structure autorise l’ajout par concaténation : le résultat décompressé s’allonge sans réécriture du préfixe existant, mais sans index ni accès aléatoire pour autant.
  • Les champs facultatifs décrivent le membre ; CRC32 détecte une corruption et ISIZE donne une taille modulo 2^32. Aucun de ces éléments n’authentifie l’auteur de l’ajout.

Une fin qui ne ferme que son membre

Le paradoxe apparaît au moment de l’ajout. Un premier programme a correctement fermé un flux gzip. Un autre place ensuite un nouveau flux gzip juste après le dernier octet. Le premier objet n’a pas été rouvert, pourtant la lecture depuis le début produit davantage de données qu’auparavant.

C’est exactement l’unité choisie par RFC 1952. Le fichier est une série de « membres » consécutifs, sans enveloppe supplémentaire entre eux. Un membre commence par un en-tête reconnaissable, contient des blocs compressés et se termine par son propre contrôle. La fin indique donc « ce membre est clos », pas « aucun octet significatif ne pourra suivre ».

La notice du RFC Editor date le document de P. Deutsch de mai 1996 et le classe Informational. Il faut conserver cette qualification : le texte spécifie un format portable, il ne proclame pas une norme Internet de la filière Standards Track et ne mesure pas le comportement de tous les logiciels ultérieurs.

Ses objectifs expliquent la forme. gzip devait traverser processeurs, systèmes, jeux de caractères et systèmes de fichiers ; fonctionner en flux avec une mémoire intermédiaire bornée ; rester librement implémentable ; et demeurer compatible avec le logiciel existant. L’accès aléatoire n’était pas promis. Une suite peut être déterministe sans offrir un sommaire.

Le nécessaire, le descriptif et le contrôlable

Deux octets fixes identifient gzip. Le champ CM désigne la méthode ; la valeur 8 correspond à DEFLATE. Les drapeaux indiquent les éléments facultatifs et les bits réservés doivent rester nuls. Ces règles appartiennent au noyau d’accord : un lecteur indépendant doit reconnaître la même entrée et savoir où commencent les données comprimées.

MTIME, FNAME, FCOMMENT, FEXTRA et FTEXT n’ont pas la même autorité. Ils peuvent évoquer une date, un nom d’origine, un commentaire, une extension ou la probabilité d’un texte. Un lecteur conforme doit pouvoir franchir ces champs même s’il ne les interprète pas. Le zéro de MTIME signifie d’ailleurs qu’aucune date n’est disponible, et le code de système d’exploitation peut être ignoré.

Ce sont des déclarations transportées, non des preuves de provenance. Un nom peut aider à restaurer un fichier ; il ne démontre pas qui l’a créé. Un commentaire peut documenter une opération ; il n’est pas signé. Une extension est délimitée par sa longueur afin que l’inconnu reste franchissable, pas afin que tout consommateur lui attribue le même sens.

Lorsque FHCRC est présent, il reprend les seize bits faibles d’un CRC32 calculé sur l’en-tête précédent. La bande de fin contient un autre CRC32, portant cette fois sur les données décompressées du membre, puis ISIZE, la taille d’entrée modulo 2^32. La proximité physique ne doit pas masquer les périmètres différents.

Le CRC ferme un contrôle, pas une identité

Un CRC32 réussi est utile. Il rend observable une modification accidentelle des données restituées. Mais toute personne capable de produire un membre peut recalculer le contrôle correspondant. La valeur ne prouve ni auteur, ni chaîne de garde, ni absence d’altération malveillante.

ISIZE a une limite tout aussi précise. Il ne contient que les 32 bits de poids faible de la longueur originale. Deux longueurs séparées par 2^32 peuvent donc produire la même valeur. Et dans un fichier à plusieurs membres, chaque ISIZE décrit son entrée locale ; la taille totale doit être recomposée par le lecteur.

La couche de compression reste séparée. RFC 1951 définit les blocs et codes DEFLATE. RFC 1950 utilise la même technique dans l’enveloppe zlib, avec son propre en-tête et Adler-32. RFC 6713, en enregistrant application/gzip et application/zlib, résume la différence : zlib est présenté comme format de flux, gzip ajoute des champs mieux adaptés au fichier.

Le découplage est une liberté de conception. L’algorithme n’a pas à décider du nom, de la date ou de la répétition des membres. L’enveloppe n’a pas à réinventer la compression. Chaque couche peut évoluer ou être remplacée à sa frontière déclarée.

L’implémentation montre aussi les angles morts

Le manuel actuel de GNU gzip documente l’usage concret : concaténer plusieurs fichiers compressés conduit gunzip à extraire tous les membres. Il précise toutefois que la compression globale est souvent meilleure lorsque les entrées sont réunies avant compression. Surtout, l’option --list n’affiche pour un fichier multi-membre que la taille décompressée et le CRC du dernier membre.

Le même fichier peut ainsi être lu intégralement par le décompresseur et résumé partiellement par l’outil d’inspection. Aucun bug n’est nécessaire pour créer l’écart. Le contrat de chaque commande n’est simplement pas le même. Un audit qui note « CRC correct » sans indiquer le membre et l’outil produit une assurance plus large que son observation.

RFC 9110 conserve gzip comme codage de contenu HTTP par référence à RFC 1952. Cela établit le vocabulaire du protocole, pas l’uniformité de tous les intermédiaires. Le présent dossier ne suppose ni que chaque client accepte plusieurs membres de la même façon, ni que chaque scanner les expose.

Le minimum commun se répète

Running-Code Primacy fournit une discipline postérieure : distinguer le texte publié, le code qui l’exécute et l’usage observé. La règle des membres vient du RFC ; le comportement de concaténation décrit par GNU gzip est une preuve d’implémentation bornée. Ensemble, ils ne deviennent pas une statistique universelle.

Minimum Initial Specification éclaire le compromis. L’identification, la méthode, les longueurs, les bits réservés et les contrôles doivent être stricts, car deux programmes doivent s’accorder. L’affichage d’un commentaire ou l’usage d’une date peut rester une décision locale.

Reality Layers aide enfin à voir deux objets dans le même nom. Symboliquement, il existe « un fichier gzip ». Opérationnellement, il peut contenir plusieurs débuts, plusieurs fins et plusieurs déclarations d’origine. La frontière de membre rend cette pluralité exécutable.