Convertir 7Z en XZ

Les deux formats utilisent le même algorithme de compression LZMA2, et la différence n’est pas dans la qualité de la compression mais dans l’empaquetage. 7Z est un conteneur qui sait faire beaucoup de choses : multi-volume, chiffrement AES, en-têtes chiffrés, compression LZMA, LZMA2, Bzip2, PPMd, Delta et d’autres. XZ est un conteneur minimal qui ne sait faire qu’une chose : compresser un flux unique avec LZMA2, et y placer une somme de contrôle.

La conversion décompresse le contenu du 7Z et le recompresse en XZ. Le résultat est un fichier qui se décompresse avec unxz sous Unix, avec 7-Zip sous Windows, et qui est portable partout où l’un de ces deux est installé. Pour un usage Unix natif, c’est la cible ; pour un usage Windows généraliste, c’est souvent 7Z qu’il faut garder.

La conversion est sans perte, et c’est ce que le registre signifie en marquant cette paire lossless. Le 7Z est décompressé, le contenu binaire est exactement ce qu’il était à l’intérieur, et XZ est construit en compressant ce même contenu. La somme de contrôle CRC64 du XZ peut être vérifiée contre unxz, et le SHA-256 du contenu décompressé est identique à celui qu’avait le contenu dans 7Z.

Cette garantie est ce qui rend la conversion utile. Un fichier d’archive peut voyager dans deux formats sans que personne ne s’inquiète de savoir s’il a été altéré en route, et c’est précisément la propriété qu’une archive doit avoir. La conversion préserve cela et le rend visible, et c’est l’unique cas où la conversion est strictement équivalente à une ré-émission.

7Z admet un format multi-volume, où une grande archive est découpée en fichiers .7z.001, .7z.002, .7z.003, et le contenu n’est complet qu’une fois tous lus. Le 7Z que cette conversion attend est un fichier unique, et un multi-volume déclenche un message d’erreur plutôt qu’une conversion silencieuse et incorrecte.

La raison est que les volumes 7Z ne sont pas des fragments autonomes : la table de distribution des volumes et la déduplication traversent les frontières. Convertir le premier volume en XZ donnerait un fichier qui n’est ni l’archive ni un sous-ensemble cohérent, et c’est volontairement refusé. Pour convertir un multi-volume, il faut d’abord le recombiner en 7Z unique, ce que 7-Zip fait en une commande : copy /B fichier.7z.001 + fichier.7z.002 + fichier.7z.003 fichier.7z. Une fois recombiné, le fichier peut entrer dans cette conversion.

7Z admet le chiffrement AES-256 du contenu, ce que XZ ne fait pas. Une archive 7Z chiffrée doit être déchiffrée avant la conversion, et c’est l’étape qui demande le mot de passe à l’utilisateur. Le convertisseur refuse 7Z chiffré parce qu’il n’a aucun moyen d’extraire le contenu, et c’est explicite dans le message d’erreur.

Pour un usage légitime, c’est la bonne séquence : déchiffrer localement avec 7-Zip, puis convertir 7Z résultant en XZ. Le mot de passe ne quitte pas la machine, et XZ qui sort n’est pas chiffré, ce qui est cohérent avec ce que XZ sait faire. Pour un usage qui veut garder le chiffrement, 7Z est la cible, pas XZ.

7Z peut chiffrer aussi les noms de fichiers et les métadonnées, ce que XZ ne peut pas représenter parce que XZ ne porte que le contenu compressé. Les permissions UNIX, les horodatages, les liens symboliques, les fichiers creux — toutes ces informations sont dans l’en-tête 7Z et perdues quand on extrait vers XZ qui n’a pas d’en-tête.

Pour une archive de données binaires où seul le contenu compte — un jeu de données, un corpus, un dump — c’est sans importance. Pour une archive de projet où les permissions et les liens comptent, c’est une perte réelle, et la conversion est la mauvaise réponse. Le bon outil pour ce cas est tar.xz, qui combine le conteneur tar avec la compression xz et préserve tout l’en-tête.

Pour le même contenu, XZ est en général légèrement plus gros que 7Z d’origine, parce que 7Z permet des optimisations de dictionnaire au niveau du paquet entier tandis que XZ n’a qu’un seul flux. La différence est typiquement 1 à 3 pour cent, ce qui est invisible pour un usage normal et visible sur un corpus de plusieurs gigaoctets où chaque pour cent compte.

Si la taille compte plus que la portabilité, garder 7Z d’origine est la bonne réponse. Si la portabilité Unix compte plus que la taille, XZ est la bonne réponse. Le 7Z est en général lisible par unxz après quelques installations ; XZ est en général lisible par 7-Zip immédiatement, ce qui est la moitié de la portabilité.

7Z peut appliquer un filtre Delta avant la compression, ce qui réduit l’entropie des données quand des octets consécutifs diffèrent peu — typique des images de disque, des exécutables, des captures de paquets. XZ n’a pas de filtre Delta intégré, et la conversion recompresse sans le filtre, ce qui peut dégrader le taux de compression sur ce type de contenu.

Pour les exécutables, 7Z utilise aussi le filtre BCJ qui pré-traite les sauts relatifs de x86, ARM et d’autres architectures. Le filtre est sans perte et n’altère pas le code exécuté, mais il rend la compression bien meilleure. XZ a des filtres BCJ équivalents, et la conversion les applique quand elle détecte un type de fichier correspondant, ce qui est la bonne réponse quand le contenu est identifiable.

XZ porte en interne plusieurs sommes de contrôle : CRC32, CRC64 et optionnellement SHA-256. La conversion calcule le CRC64 et l’écrit dans le pied de fichier, et c’est la valeur qu’unxz -t vérifiera. Pour une vérification supplémentaire, xz --extreme recalcule la compression à un niveau plus élevé et compare avec le fichier d’origine, ce qui prend plus de temps mais détecte la corruption que les sommes internes ne voient pas.

La conversion elle-même vérifie la somme de contrôle du 7Z source avant de décompresser, et refuse de continuer si la décompression produit moins d’octets que l’en-tête n’annonçait. C’est la garantie que le contenu qui entre dans XZ est ce que l’archive disait contenir, et c’est la seule façon de savoir qu’une conversion n’a pas glissé silencieusement.

XZ a un niveau de compression de 6 par défaut, sur une échelle de 0 à 9. Le niveau 6 est ce que xz --preset-default utilise, et c’est le bon compromis entre temps de compression et taille résultante pour la plupart des usages. Le niveau 9 --preset-extreme prend plusieurs fois plus de temps pour un gain typique de 1 à 2 pour cent, et n’est utile que pour un corpus destiné à être compressé une fois et décompressé souvent.

La conversion utilise le niveau par défaut, parce que c’est ce que la grande majorité des cas veut. Pour un cas qui veut autre chose, la conversion post-hoc avec xz -9 fichier.tar produit le résultat en une commande, et c’est l’édition qui vaut la peine quand on sait que le fichier sera archivé pour des années.

Cette conversion est particulière : elle est exécutée côté serveur, dans un conteneur, parce que la compression 7Z et XZ demande un binaire natif que le navigateur ne peut pas fournir. Le fichier est téléversé sur api.quinvert.com, écrit dans un répertoire temporaire, traité par 7-Zip, et le résultat est retourné. Le répertoire temporaire est supprimé dans un bloc finally qui s’exécute aussi sur les chemins d’erreur, et le résultat est servi avec Cache-Control: no-store.

Pour un usage avec un contenu sensible — un projet non publié, un dépôt de code privé, un jeu de données sous embargo — c’est la conversion qu’il faut regarder de plus près. La limite est 25 Mo par fichier, 100 conversions par visiteur par jour, fuseau UTC, et le compteur est réinitialisé à minuit UTC. Pour un contenu plus sensible, garder 7Z et le servir depuis votre propre infrastructure est la bonne réponse.