XZ(1) | Utilitaires XZ | XZ(1) |
xz, unxz, xzcat, lzma, unlzma, lzcat - Compresser ou décompresser des fichiers .xz et .lzma
xz [option...] [fichier...]
unxz est équivalent à xz --decompress.
xzcat est équivalent à xz --decompress --stdout
lzma est équivalent à xz --format=lzma
unlzma est équivalent à xz --format=lzma
--decompress
lzcat est équivalent à xz --format=lzma --decompress
-- stdout
Lors de l'écriture de scripts qui nécessitent de décompresser des fichiers, il est recommandé de toujours utiliser la commande xz avec les arguments appropriés (xz -d ou xz -dc) au lieu des commandes unxz et xzcat.
xz is a general-purpose data compression tool with command line syntax similar to gzip(1) and bzip2(1). The native file format is the .xz format, but the legacy .lzma format used by LZMA Utils and raw compressed streams with no container format headers are also supported. In addition, decompression of the .lz format used by lzip is supported.
xz compresse ou décompresse chaque fichier en fonction du mode d'opération choisi. Si aucun fichier n'est donné ou fichier est -, xz lit depuis l'entrée standard et écrit les données traitées sur la sortie standard. xz refusera (affichera une erreur et ignorera le fichier) d'écrire les données compressées sur la sortie standard si c'est un terminal. De même, xz refusera de lire des données compressées depuis l'entrée standard si c'est un terminal.
A moins que --sdout ne soit indiqué, les fichiers autres que - sont écrits dans un nouveau fichier dont le nom est dérivé du nom de fichier source :
Si le fichier cible existe déjà, une erreur est affichée et le fichier est ignoré.
Sauf s'il écrit dans la sortie standard, xz affichera un avertissement et ignorera le fichier dans les cas suivants :
Après la compression ou la décompression réussie du fichier, xz copie les permissions du propriétaire, du groupe, la date d'accès, et les modifications d'heure depuis le fichier source du fichier cible. Si la copie du groupe échoue, les permissions sont modifiées pour que le fichier cible ne soit pas accessible aux utilisateurs qui n'ont pas les droits d'accès au fichier source. xz ne prend actuellement pas en charge la copie d'autres métadonnées telles que les listes de contrôle d'accès ou les attributs étendus.
Once the target file has been successfully closed, the source file is removed unless --keep was specified. The source file is never removed if the output is written to standard output or if an error occurs.
Envoyer SIGINFO ou SIGURSR1 au processus xz, lui fait afficher l'information de progression sur l'erreur standard. Cela a un intérêt limité car lorsque l'erreur standard est un terminal, utiliser --verbose affichera automatiquement un indicateur de progression du processus.
L'utilisation de la mémoire par xz varie de quelques centaines de kilo-octets à plusieurs gigaoctects en fonction des paramètres de compression. Les réglages utilisés lors de la compression d'un fichier déterminent les besoins en mémoire pour la décompression. Habituellement la décompression nécessite 5 à 20 de la quantité de mémoire utilisée pour la compression du fichier. Par exemple, décompresser un fichier créé avec xz-9 recquiert habituellement 65 Mio de mémoire. Bien qu'il soit possible d'avoir des fichiers .xz nécessitant plusieurs gigaoctets de mémoire pour être décompressés.
Especially users of older systems may find the possibility of very large memory usage annoying. To prevent uncomfortable surprises, xz has a built-in memory usage limiter, which is disabled by default. While some operating systems provide ways to limit the memory usage of processes, relying on it wasn't deemed to be flexible enough (for example, using ulimit(1) to limit virtual memory tends to cripple mmap(2)).
The memory usage limiter can be enabled with the command line option --memlimit=limit. Often it is more convenient to enable the limiter by default by setting the environment variable XZ_DEFAULTS, for example, XZ_DEFAULTS=--memlimit=150MiB. It is possible to set the limits separately for compression and decompression by using --memlimit-compress=limit and --memlimit-decompress=limit. Using these two options outside XZ_DEFAULTS is rarely useful because a single run of xz cannot do both compression and decompression and --memlimit=limit (or -M limit) is shorter to type on the command line.
If the specified memory usage limit is exceeded when decompressing, xz will display an error and decompressing the file will fail. If the limit is exceeded when compressing, xz will try to scale the settings down so that the limit is no longer exceeded (except when using --format=raw or --no-adjust). This way the operation won't fail unless the limit is very small. The scaling of the settings is done in steps that don't match the compression level presets, for example, if the limit is only slightly less than the amount required for xz -9, the settings will be scaled down only a little, not all the way down to xz -8.
Il est possible de concaténer les fichiers .xz tels quel. xz décompressera de tels fichiers comme s'ils étaient un unique fichier .xz.
It is possible to insert padding between the concatenated parts or after the last part. The padding must consist of null bytes and the size of the padding must be a multiple of four bytes. This can be useful, for example, if the .xz file is stored on a medium that measures file sizes in 512-byte blocks.
La concaténation et le remplissage ne sont pas autorisés avec les fichiers .lzma ou les flux bruts.
Dans la plupart des endroits où un argument entier est attendu, un suffixe optionel permet d'indiquer facilement les grands entiers. Il ne doit pas y avoir d'espace entre l'entier et le suffixe.
La valeur spéciale max peut être utilisée pour indiquer la valeur maximale de l'entier prise en charge par l'option.
Si plusieurs options de mode d'opération sont données, la dernière prend effet.
Préréglage | DictSize | CompCPU | CompMem | DecMem |
-0 | 256 KiB | 0 | 3 MiB | 1 MiB |
-1 | 1 MiB | 1 | 9 MiB | 2 MiB |
-2 | 2 MiB | 2 | 17 MiB | 3 MiB |
-3 | 4 MiB | 3 | 32 MiB | 5 MiB |
-4 | 4 MiB | 4 | 48 MiB | 5 MiB |
-5 | 8 MiB | 5 | 94 MiB | 9 MiB |
-6 | 8 MiB | 6 | 94 MiB | 9 MiB |
-7 | 16 MiB | 6 | 186 MiB | 17 MiB |
-8 | 32 MiB | 6 | 370 MiB | 33 MiB |
-9 | 64 MiB | 6 | 674 MiB | 65 MiB |
Préréglage | DictSize | CompCPU | CompMem | DecMem |
-0e | 256 KiB | 8 | 4 MiB | 1 MiB |
-1e | 1 MiB | 8 | 13 MiB | 2 MiB |
-2e | 2 MiB | 8 | 25 MiB | 3 MiB |
-3e | 4 MiB | 7 | 48 MiB | 5 MiB |
-4e | 4 MiB | 8 | 48 MiB | 5 MiB |
-5e | 8 MiB | 7 | 94 MiB | 9 MiB |
-6e | 8 MiB | 8 | 94 MiB | 9 MiB |
-7e | 16 MiB | 8 | 186 MiB | 17 MiB |
-8e | 32 MiB | 8 | 370 MiB | 33 MiB |
-9e | 64 MiB | 8 | 674 MiB | 65 MiB |
A custom filter chain allows specifying the compression settings in detail instead of relying on the settings associated to the presets. When a custom filter chain is specified, preset options (-0 ... -9 and --extreme) earlier on the command line are forgotten. If a preset option is specified after one or more custom filter chain options, the new preset takes effect and the custom filter chain options specified earlier are forgotten.
Une chaîne de filtre est comparable à une redirection (pipe) sur la ligne de commande. Lors de la compression, les entrées non compressées vont au premier filtre, dont la sortie va au prochain filtre (s'il y en a). La sortie du dernier filtre est écrite sur le fichier compressé. Le nombre maximal de filtres dans la chaîne est quatre, mais habituellement, un chaîne de filtre n'a qu'un ou deux filtres.
Beaucoup de filtres ont des limitations sur l'endroit où ils peuvent se placer dans la chaîne de filtre : quelques filtres ne peuvent fonctionner qu'en tant que dernier filtre dans la chaîne, quelques uns en tant que non dernier filtre, et d'autres à n'importe quelle position dans la chaîne. Suivant le filtre, cette limitation est soit inhérente au profil du filtre, soit existe pour des raisons de sécurité.
Une chaîne de filtres personnalisée est indiquée en utilisant une ou plusieurs options de filtre dans l'ordre où elles sont souhaitées dans la chaîne de filtres. Cela fait, l'ordre des options de filtre est significatif! Lors du décodage des flux bruts (--format=raw), le filtre de chaîne est indiqué dans le même ordre qu'il fût indiqué lors de la compression.
Les filtres prennent des options spécifiques aux filtres sous la forme d'une liste séparée par des virgules. Les virgules supplémentaires dans les options sont ignorées. Toutes les options ont une valeur par défaut, donc vous ne devez indiquer que celles que vous voulez changer.
Pour voir l'entièreté de la chaîne de filtres et ses options, utilisez xz -vv (ce qui est comme utiliser --verbose deux fois). Cela fonctionne aussi pour voir les options de chaîne de filtres utilisées par les préréglages.
Filtre | Alignement | Notes |
x86 | 1 | 32 bits ou 64 bits x86 |
ARM | 4 | |
ARM-Thumb | 2 | |
ARM64 | 4 | 4096-byte alignment is best |
PowerPC | 4 | Grand boutiste seulement |
IA-64 | 16 | Itanium |
SPARC | 4 |
Le mode robot est activé avec l'option --robot. Cela rend la sortie de xz plus facile à analyser par d'autres programmes. Actuellement, --robot n'est seulement pris en charge qu'avec --version, --info-memory et --list. Il sera pris en charge pour la compression et la décompression dans le futur.
xz --robot --version affichera le numéro de version de xz et liblzma dans le format suivant :
XZ_VERSION=XYYYZZZS
LIBLZMA_VERSION=XYYYZZZS
XYYYZZZS sont identiques sur les deux lignes si xz et liblzma sont issus de la même version d'utilitaires XZ.
Exemples : 4.999.9beta est 49990091 et 5.0.0 est 50000002.
xz --robot --info-memory affiche une seule ligne avec trois colonnes séparées par des tabulations :
Dans le futur, la sortie de xz --robot --info-memory pourrait avoir plus de colonnes, mais jamais plus qu'une ligne unique.
xz --robot --list utilise une sortie séparée par des tabulations. La première colonne de toutes les lignes possède une chaîne qui indique le type d'information trouvée sur cette ligne :
Les colonnes des lignes file :
Les colonnes des lignes stream :
Les colonnes des lignes block :
Si --verbose a été indiqué deux fois, les colonnes additionnelles sont inclues sur les lignes block. Elles ne sont pas affichées avec un seul --verbose, car l'obtention de ces informations nécessite de nombreuses recherches et peut donc être lente :
Les colonnes des lignes summary :
Depuis xz 5.1.2alpha:
Les colonnes de la ligne totals :
Si --verbose a été indiqué deux fois, des colonnes supplémentaires sont incluses sur la ligne totals :
Depuis xz 5.1.2alpha:
Les versions futures pourront ajouter de nouveaux types de lignes et de nouvelles colonnes pourront être ajoutées aux types de lignes existants, mais les colonnes existantes ne seront pas modifiées.
Les notifications (pas les avertissements ou les erreurs) affichées sur l'erreur standard n'affectent pas le statut de sortie.
xz analyse les listes d'options séparées par des espaces à partir des variables d'environnement XZ_DEFAULTS et XZ_OPT, dans cet ordre, avant d'analyser les options de la ligne de commandes. Remarquez que seules les options sont analysées depuis l'environnement des variables ; toutes les non-options sont ignorées silencieusement. L'analyse est faite avec getopt_long(3) qui est aussi utilisé pour les arguments de la ligne de commandes.
XZ_OPT=-2v tar caf foo.tar.xz foo
XZ_OPT=${XZ_OPT-"-7e"} export XZ_OPT
La syntaxe de la ligne de commande de xz est quasimment un sur-ensemble de lzma, unlzma et lzcat comme ils sont trouvés dans les utilitaires LZMA 4.32.x . Dans la pluspart des cas, il est possible de remplacer les outils LZMA par les outils XZ sans casser les scripts existants. Il existe cependant certaines incompatibilités qui peuvent parfois poser des problèmes.
La numérotation des préréglages de niveau de compression est différente entre les outils xz et LZMA. La différence la plus importante est la manière dont les tailles de dictionnaire sont affectées aux différents préréglages. La taille de dictionnaire est à peu près égale à celle d'utilisation de la mémoire de la décompression.
Niveau | xz | Utilitaires LZMA |
-0 | 256 KiB | N/A |
-1 | 1 MiB | 64 KiB |
-2 | 2 MiB | 1 MiB |
-3 | 4 MiB | 512 KiB |
-4 | 4 MiB | 1 MiB |
-5 | 8 MiB | 2 MiB |
-6 | 8 MiB | 4 MiB |
-7 | 16 MiB | 8 MiB |
-8 | 32 MiB | 16 MiB |
-9 | 64 MiB | 32 MiB |
Les différences de tailles des dictionnaires affectent aussi l'utilisation de la mémoire du compresseur, mais il y a quelques autres différences entre les outils LZMA et les outils XZ, qui rendent la différence encore plus grande :
Niveau | xz | Utilitaires LZMA 4.32.x |
-0 | 3 MiB | N/A |
-1 | 9 MiB | 2 MiB |
-2 | 17 MiB | 12 MiB |
-3 | 32 MiB | 12 MiB |
-4 | 48 MiB | 16 MiB |
-5 | 94 MiB | 26 MiB |
-6 | 94 MiB | 45 MiB |
-7 | 186 MiB | 83 MiB |
-8 | 370 MiB | 159 MiB |
-9 | 674 MiB | 311 MiB |
Le niveau de préréglage par défaut dans les outils LZMA est -7 alors que pour les outils XZ c'est -6, les deux utilisent ainsi un dictionnaire de 8 Mio par défaut.
The uncompressed size of the file can be stored in the .lzma header. LZMA Utils does that when compressing regular files. The alternative is to mark that uncompressed size is unknown and use end-of-payload marker to indicate where the decompressor should stop. LZMA Utils uses this method when uncompressed size isn't known, which is the case, for example, in pipes.
xz prend en charge la décompression des fichiers .lzma avec ou sans marqueur de fin de charge utile, mais tous les fichiers .lzma créés par xz utiliseront un marqueur de fin de charge utile et ont la taille non compréssée marquée comme inconnue dans l'en-tête .lzma. Cela peut être un problème dans quelques situations inhabituelles. Par exemple, un décompresseur .lzma dans un périphérique embarqué pourrait ne fonctionner qu'avec des fichiers dont la taille non comprimée est connue. Si vous vous heurtez à ce problème, vous devez utiliser les utilitaires LZMA ou LZMA SDK pour créer des fichiers .lzma avec une taille non compressée connue.
Le format .lzma autorise des valeurs lc jusqu'à 8, et des valeurs lp jusqu'à 4. Les outils LZMA peuvent décompresser des fichiers avec tous les lc et lp, mais créez toujours les fichiers avec lc=3 et lp=0. Créer des fichiers avec d'autres valeurs lc et lp est possible avec xz et avec LZMA SDK.
L'implémentation du filtre LZMA1 dans liblzma nécessite que la somme de lc et lp soit inférieure ou égale à 4. Ainsi, les fichiers .lzma qui excèdent cette limitation ne peuvent pas être décompressés avec xz.
Les outils LZMA créent seulement des fichiers .lzma qui ont une taille de dictionnaire de 2^n (une puissance de 2) mais acceptent les fichiers avec toutes les tailles de dictionnaire. Libzlma n'accepte que les fichiers .lzma qui ont une taille dictionnaire de 2^n ou 2^n + 2^(n-1). Cela afin de diminuer les faux positifs lors de la détection des fichiers .lzma.
Ces limitations ne devraient pas poser problème en pratique, car pratiquement tous les fichiers .lzma ont été compressés avec des réglages que liblzma accepte.
Lors de la décompession, l'utilitaire LZMA ignore silencieusement tout ce qui est après le premier flux .lzma. Dans la majorité des situations, c'est un bogue. Cela veut dire aussi que les outils LZMA ne gèrent pas la décompression de fichiers .lzma concaténés.
S'il reste des données après le premier flux .lzma, xz considère que le fichier est corrompu sauf si --single-stream a été utilisé. Cela peut casser des scripts obscurs qui ont supposé que les déchets de fin de ligne sont ignorés.
La sortie compressée exacte produite par les même fichiers non compressés en entrée peut varier en fonction des différentes versions de l'utilitaire XZ, même si les options de compression sont identiques. En effet, il est possible d'améliorer l'encodeur (compression plus rapide ou meilleure) sans affecter le format du fichier. La sortie peut même varier entre différentes compilations de la même version d'utilitaire XZ, si des options de construction différentes sont utilisées.
Cela signifie qu'une fois que --rsyncable a été implémenté, les fichiers résultants ne seront pas nécessairement synchronisables avec rsync à moins que les nouveaux et anciens fichiers n'aient été compressés avec la même version de xz. Ce problème peut être résolu si une partie de l'implémentation est gelée pour garantir la stabilité de la sortie rsyncable à travers les versions de xz.
Les implémentations de décompresseur embarqué comme XZ Embedded ne gèrent pas nécessairement les fichiers créés avec d'autres types de vérification d'intégrité que none et CRC32. Comme la valeur par défaut est --check=crc64, vous devez utiliser --check=none ou --check=crc32 lors de la création de fichiers pour les systèmes embarqués.
En dehors des systèmes embarqués, tous les décompresseurs de format .xz gèrent tous les types de vérification ou sont au moins capables de décompresser le fichier sans effectuer la vérification d'intégrité si ce type de vérification particulière n'est pas pris en charge.
XZ Embedded prend en charge les filtres BCJ, mais seulement avec le décalage de départ par défaut.
Compresser le fichier toto en toto.xz en utilisant le niveau de compression par défaut (-6) et supprimer toto si la compression réussit :
xz toto
Décompresser bidule.xz en bidule et ne pas supprimer bidule.xz même si la compression réussit :
xz -dk bidule.xz
Create baz.tar.xz with the preset -4e (-4 --extreme), which is slower than the default -6, but needs less memory for compression and decompression (48 MiB and 5 MiB, respectively):
tar cf - truc | xz -4e > truc.tar.xz
Un mélange de fichiers compressés et non compressés peuvent être décompressés vers la sortie standard avec une simple commande :
xz -dcf a.txt b.txt.xz c.txt d.txt.lzma > abcd.txt
Sur GNU et *BSD, find(1) et xargs(1) peuvent être utilisés pour mettre en parallèle la compression de plusieurs fichiers :
find . -type f \! -name '*.xz' -print0 \ | xargs -0r -P4 -n16 xz -T1
L'option P passée à xargs(1) fixe le nombre de processus xz en parallèles. La meilleure valeur pour l'option n dépend du nombre de fichiers à compresser. S-il n'y a que quelques fichiers, la valeur sera probablement 1 ; avec des dizaines de milliers de fichiers, 100 ou même plus serait approprié pour réduire le nombre de processus xz que xargs(1) créera éventuellement.
L'option -T1 de xz est là pour le forcer en mode mono-thread, car xargs(1) est utilisé pour contrôler la quantité de mise en parallèle.
Calculer combien d'octets ont été économisés au total après avoir compressé plusieurs fichiers :
xz --robot --list *.xz | awk '/^totals/{print $5-$4}'
Un script peut vouloir savoir qu'il utilise une version suffisamment récente de xz. Le script sh(1) suivant vérifie que le numéro de version de l'outil xz soit au minimum 5.0.0. Cette méthode est compatible avec les vieilles versions bêta, qui ne gèrent pas l'option --robot :
if ! eval "$(xz --robot --version 2> /dev/null)" || [ "$XZ_VERSION" -lt 50000002 ]; then echo "Votre version de xz est trop ancienne." fi unset XZ_VERSION LIBLZMA_VERSION
Régler une limite d'utilisation de la mémoire pour la décompression en utilisant XZ_OPT, mais si une limite a déjà été définie, ne pas l'augmenter :
NEWLIM=$((123 << 20)) # 123 MiB OLDLIM=$(xz --robot --info-memory | cut -f3) if [ $OLDLIM -eq 0 -o $OLDLIM -gt $NEWLIM ]; then XZ_OPT="$XZ_OPT --memlimit-decompress=$NEWLIM" export XZ_OPT fi
L'utilisation la plus simple des chaînes de filtres personnalisées est la personnalisation d'un préréglage LZMA2. Cela peut être utile, car les préréglages ne couvrent qu'un sous-ensemble des réglages de compression potentiellement utiles.
Les colonnes CompCPU des tableaux des descriptions des options -0 à -9 et --extreme sont utiles lors de la personnalisation des préréglages LZMA2. Voici les parties pertinentes recueillies à partir de ces deux tableaux :
Préréglage | CompCPU |
-0 | 0 |
-1 | 1 |
-2 | 2 |
-3 | 3 |
-4 | 4 |
-5 | 5 |
-6 | 6 |
-5e | 7 |
-6e | 8 |
If you know that a file requires somewhat big dictionary (for example, 32 MiB) to compress well, but you want to compress it quicker than xz -8 would do, a preset with a low CompCPU value (for example, 1) can be modified to use a bigger dictionary:
xz --lzma2=preset=1,dict=32MiB toto.tar
Avec certains fichiers, la commande ci-dessus peut être plus rapide que xz-6 tout en compressant bien mieux. Cependant, il faut souligner que seuls certains fichiers bénéficient d'un grand dictionnaire tout en gardant la valeur de CompCPU faible. La siutation la plus évidente où un gros dictionnaire peut baucoup aider, est une archive contenant des fichiers très similaires de quelques megaoctets chacun. La taille de dictionnaire doit être significativement plus grosse que tout fichier individuel pour permettre à LZMA2 de tirer pleinement partie des similarités entre des fichiers consécutifs.
Si une utilisation de la mémoire élevée pour la compression et décompression convient, et que le fichier à compresser a une taille de plusieurs centaines de megaoctets, il peut être utile d'utiliser un plus gros dictionnaire que celui fourni par xz-9 (64 Mio) :
xz -vv --lzma2=dict=192MiB gros_toto.tar
Utiliser -vv (--verbose--verbose) comme dans l'exemple ci-dessus peut être utile pour voir les besoins en mémoire du compresseur et du décompresseur. Rappelez-vous qu'utiliser un dictionnaire plus gros que la taille du fichier non compressé est un gachis de mémoire, donc la commande ci-dessus n'est pas utile pour les petits fichiers.
Sometimes the compression time doesn't matter, but the decompressor memory usage has to be kept low, for example, to make it possible to decompress the file on an embedded system. The following command uses -6e (-6 --extreme) as a base and sets the dictionary to only 64 KiB. The resulting file can be decompressed with XZ Embedded (that's why there is --check=crc32) using about 100 KiB of memory.
xz --check=crc32 --lzma2=preset=6e,dict=64KiB toto
If you want to squeeze out as many bytes as possible, adjusting the number of literal context bits (lc) and number of position bits (pb) can sometimes help. Adjusting the number of literal position bits (lp) might help too, but usually lc and pb are more important. For example, a source code archive contains mostly US-ASCII text, so something like the following might give slightly (like 0.1 %) smaller file than xz -6e (try also without lc=4):
xz --lzma2=preset=6e,pb=0,lc=4 code_source.tar
Using another filter together with LZMA2 can improve compression with certain file types. For example, to compress a x86-32 or x86-64 shared library using the x86 BCJ filter:
xz --x86 --lzma2 libtoto.so
Notez que l'ordre des options de filtre est significatif. Si --x86 est indiqué après --lzma2, xz donnera une erreur, car il ne peut y avoir aucun filtre après LZMA2, et aussi parce que le filtre BCJ x86 ne peut pas être utilisé comme dernier filtre dans la chaîne.
Le filtre Delta associé à LZMA2 peut donner de bons résultats avec les images bitmap. Cela devrait habituellement battre PNG, qui a quelques filtres avancés supplémentaires qu'un simple delta, mais qui utilise Deflate pour la compression effective.
The image has to be saved in uncompressed format, for example, as uncompressed TIFF. The distance parameter of the Delta filter is set to match the number of bytes per pixel in the image. For example, 24-bit RGB bitmap needs dist=3, and it is also good to pass pb=0 to LZMA2 to accommodate the three-byte alignment:
xz --delta=dist=3 --lzma2=pb=0 toto.tiff
If multiple images have been put into a single archive (for example, .tar), the Delta filter will work on that too as long as all images have the same number of bytes per pixel.
xzdec(1), xzdiff(1), xzgrep(1), xzless(1), xzmore(1), gzip(1), bzip2(1), 7z(1)
XZ Utilitaires: <https://tukaani.org/xz/>
XZ Embarqué: <https://tukaani.org/xz/embedded.html>
LZMA SDK: <http://7-zip.org/sdk.html>
2022-12-01 | Tukaani |