Scroll to navigation

XZ(1) XZ Utils XZ(1)

NOM

xz, unxz, xzcat, lzma, unlzma, lzcat - Compresser ou décompresser des fichiers .xz et .lzma

SYNOPSIS

xz [option...] [fichier...]

ALIAS DES COMMANDES

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.

DESCRIPTION

xz est un outil de compression de données polyvalent avec une syntaxe de ligne de commandes similaire à gzip(1) et bzip2(1). Le format de fichier natif est le format .xz, mais le format historique .lzma utilisé par les outils LZMA et les flux bruts compressés sans conteneur d'en-têtes de format sont aussi pris en charge.

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.

À 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 :

  • Lors de la compression, le suffixe du format de fichier cible (.xz ou .lzma) est ajouté au nom de fichier source pour obtenir le nom de fichier cible.
  • Lors de la décompression, le suffixe .xz ou .lzma est enlevé du nom de fichier pour obtenir le nom de fichier cible. xz reconnaît aussi les suffixes .txz et .tlz et les remplace par le suffixe .tar.

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 :

  • fichier n'est pas un fichier normal. Les liens symboliques ne sont pas suivis et donc ne sont pas considérés comme des fichiers normaux.
  • fichier a plusieurs liens physiques.
  • fichier a un setuid, setgid ou sticky bit positionné.
  • Le mode d'opération est défini pour compresser et le fichier a déjà un suffixe du format de fichier cible (.xz ou .txz lors d'une compression en format .xz, et .lzma ou .tlz lors d'une compression en format .lzma).
  • Le mode d'opération est défini pour décompresser et le fichier n'a pas de suffixe correspondant aux formats de fichier pris en charge (.xz, .txz, .lzma ou .tlz).

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 à partir du 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.

Une fois que le fichier cible a été fermé avec succès, le fichier source est supprimé à moins que --keep n'ait été spécifié. Le fichier source n'est jamais supprimé si la sortie est écrite sur la sortie standard.

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.

Utilisation de la mémoire

L'utilisation de la mémoire par xz varie de quelques centaines de kilo-octets à plusieurs gigaoctets 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 requiert actuellement 65 Mio de mémoire. Pourtant, il est possible d'avoir des fichiers .xz nécessitant plusieurs gigaoctets de mémoire pour être décompressés.

En particulier, les utilisateurs de vieux systèmes peuvent trouver ennuyeux l'utilisation de beaucoup de mémoire. Pour éviter les mauvaises surprises, xz a un limiteur d'utilisation de la mémoire intégré qui est désactivé par défaut. Bien que quelques systèmes d'exploitation fournissent des moyens pour limiter l'utilisation de la mémoire par les processus, leur utilisation s'est avérée insuffisamment flexible (par exemple l'utilisation de ulimit(1) pour limiter la mémoire virtuelle tend à pénaliser mmap(2)).

Le limiteur d'utilisation de la mémoire peut être activé avec l'option --memlimit=limite. Généralement, il est plus pratique d'activer le limiteur par défaut en réglant la variable d'environnement XZ_DEFAULTS, par exemple XZ_DEFAULTS=--memlimit=150MiB. Il est possible de régler les limites indépendamment pour la compression et la décompression en utilisant --memlimit-compress=limite et --memlimit-decompress=limite. Utiliser ces deux options hors de XZ_DEFAULTS est rarement utile, car une simple exécution de xz ne peut pas à la fois compresser et décompresser et --memlimit=limite (ou M limite) est moins long à taper sur la ligne de commandes.

Si la limite d'utilisation de la mémoire est dépassée lors de la décompression, xz affichera une erreur et la décompression échouera. Si la limite est dépassée lors de la compression, xz essaiera d'adapter les réglages pour que la limite ne soit plus dépassée (sauf lors de l'utilisation de --format=raw ou de --no-adjust). De cette façon, l'opération n'échouera pas sauf si la limite est très petite. L'adaptation des réglages est faite par paliers et n'aboutira pas forcément aux réglages prédéfinis du niveau de compression, par ex. si la limite est seulement légèrement plus petite que la quantité requise par xz-9, les réglages seront réduits un tout petit peu, mais pas jusqu'à xz-8.

Concaténation et remplissage avec des fichiers .xz

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.

Il est possible d'insérer du remplissage entre les parties concaténées ou après la dernière partie. Le remplissage doit se composer d'octets nuls et la taille du remplissage doit être un multiple de quatre octets. Cela peut être utile par exemple si le fichier .xz est stocké sur un média qui mesure la taille des fichiers en blocs de 512 octets.

La concaténation et le remplissage ne sont pas autorisés avec les fichiers .lzma ou les flux bruts.

OPTIONS

Suffixes entiers et valeurs spéciales.

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.

Multiplier l'entier par 1024 (2^10). Ki, k, kB, K et KB sont acceptés comme synonymes de KiB.
Multiplier l'entier par 1 048 576 (2^20). Mi, m, M et MB sont acceptés comme synonymes de MiB.
Multiplier l'entier par 1 073 741 824 (2^30). Gi, g, G et GB sont acceptés comme synonymes de GiB.

La valeur spéciale max peut être utilisée pour indiquer la valeur maximale de l'entier prise en charge par l'option.

Mode d'opération

Si plusieurs options de mode d'opération sont données, la dernière prend effet.

Compresser. C'est le mode d'opération par défaut lorsque aucune option de mode opératoire n'est spécifiée ou qu'aucun autre mode d'opération n'est sous-entendu par le nom de la commande (par exemple unxz sous-entend --decompress).
décompresser
Tester l'intégrité des fichiers compressés. Cette option est équivalente à --decompress --stdout sauf que les données décompressées sont rejetées au lieu d'être écrites sur la sortie standard. Aucun fichier n'est créé ou supprimé.
Afficher l'information sur les fichiers compressés. Aucune sortie non-compressée n'est produite et aucun fichier n'est créé ou supprimé. En mode liste, le programme ne peut pas lire les données compressées depuis l'entrée standard ou depuis d'autres sources non adressables.
Le listing par défaut montre les informations basiques des fichiers, un fichier par ligne. Pour des informations plus détaillées, utilisez aussi l'option --verbose. Pour encore plus d'informations, utilisez --verbose deux fois, mais prenez en compte que cela peut être lent, car obtenir des informations supplémentaires nécessite de nombreuses recherches. La largeur de la sortie «bavarde» dépasse 80 caractères, alors canaliser la sortie (par exemple vers less-S) peut être pratique si le terminal n'est pas assez large.
La sortie exacte peut varier suivant les versions de xz et les différents paramètres régionaux. Pour une sortie lisible par la machine, utiliser --robot --list.

Modificateurs d'opération

Ne pas effacer les fichiers d'entrée.
À partir de xz 5.4.0, cette option fait aussi que xz compresser ou décompresse même si l'entrée est un lien symbolique vers un fichier normal, a plus qu'un lien physique, ou a le bit setuid, setgid ou sticky défini. Les bits setuid, setgid et sticky bits ne sont pas copiés dans le fichier cible. Dans les versions antérieures, cela était seulement fait par --force.
Cette option a plusieurs effets :
  • Si le fichier cible existe déjà, l'effacer avant de compresser ou décompresser.
  • Compresser ou décompresser même si l'entrée est un lien symbolique vers un fichier normal, a plus qu'un lien physique ou a le setuid, setgid ou sticky bit positionnés. Les bits setuid, setgid et sticky bits ne sont pas copiés dans le fichier cible.
  • Lorsque xz est utilisé avec --decompress --stdout et qu'il ne peut pas reconnaitre le type du fichier source, copier le fichier source tel quel dans la sortie standard. Celà permet à xzcat --force d'être utilisé comme cat(1) pour les fichiers qui n'ont pas été compressé avec xz. Remarquez que dans le futur, xz devrait prendre en charge de nouveaux formats de fichiers compressés, ce qui permettra à xz de décompresser plus de types de fichiers au lieu de les copier tels quels dans la sortie standard. --format=format peut être utilisé pour contraindre xz à décompresser seulement un format de fichier.
Écrire les données compressées ou décompressées sur la sortie standard plutôt que dans un fichier. Cela necessite --keep.
Décompresser seulement le premier flux .xz et ignorer silencieusement les possibles données d'entrée résiduelles qui suivent le flux. Normalement ces déchets excédentaires provoquent l'affichage d'une erreur par xz.
xz ne décompresse jamais plus d'un flux à partir de fichiers .lzma ou de flux bruts, mais cette option fait aussi que xz ignorera les données résiduelles après le fichier .lzma ou le flux brut.
Cette option n'a aucun effet si le mode d'opération n'est pas --decompress ou --test.
Désactiver la création de fichiers peu denses. Par défaut, lors de la décompression en un fichier normal, xz essaie d'en faire un fichier creux si les données décompressées contiennent de longues séquences de zéros binaires. Cela fonctionne aussi lors de l'écriture sur la sortie standard aussi longtemps que la sortie standard est connectée à un fichier normal et que certaines conditions supplémentaires sont satisfaites pour le faire de manière sécurisée. Créer des fichiers creux peut épargner de l'espace disque et accélérer la décompression en réduisant la quantité d'entrées/sorties sur le disque.
Lors de la compression, utiliser .suf comme suffixe du fichier cible au lieu de .xz ou .lzma. Si xz n'écrit pas sur la sortie standard et si le fichier source a déja le suffixe .suf, un avertissement est affiché et le fichier est ignoré.
Lors de la décompression, reconnaître les fichiers avec le suffixe .suf en complément des fichiers avec le suffixe .xz, .txz, .lzma ou .tlz. Si le fichier source a le suffixe .suf, le suffixe est enlevé pour obtenir le nom de fichier cible.
Lors de la compression ou décompression de flux bruts (--fomat=raw), le suffixe doit toujours être spécifié à moins d'écrire sur la sortie standard, car il n'y a pas de suffixe par défaut pour les flux bruts.
Lire les noms de fichier à traiter depuis fichier ; si fichier est omis, les noms de fichier sont lus sur l'entrée standard. Les noms de fichier doivent se terminer avec le caractère de nouvelle ligne. Un tiret (-) est considéré comme un nom de fichier normal ; ce qui ne signifie pas entrée standard. Si les noms de fichier sont aussi donnés comme arguments de ligne de commande, ils sont traités avant les noms de fichier lus depuis fichier.
Cela est identique à --files[=fichier] sauf que chaque nom de fichier doit se terminer par le caractère null.

Format de fichier basique et options de compression

Indiquer le format de fichier à compresser ou décompresser :
C'est celui par défaut. Lors de la compression, auto est équivalent à xz. Lors de la décompression, le format du fichier en entrée est détecté automatiquement. Notez que les flux bruts (créés avec --format=raw) ne peuvent pas être détectés automatiquement.
Compresser dans le format de fichier .xz ou n'accepter que les fichiers .xz à décompresser.
Compresser au format de fichier .lzma historique, ou n'accepter que les fichiers .lzma lors de la décompression. Le nom alternatif alone est fourni pour la rétrocompatibilité avec les utilitaires LZMA.
Compresser ou décompresser un flux brut (sans en-têtes). Cela est réservé seulement aux utilisateurs aguerris. Pour décoder des flux bruts, vous devez utiliser --format=raw et spécifier explicitement la chaîne de filtre, qui normalement aurait du être stockée dans les en-têtes du conteneur.
Spécifier le type d'intégrité à vérifier. La vérification est calculée à partir des données non-compressées et stockées dans le fichier .xz. Cette option n'a effet que si la compression a été faite dans le format .xz ; le format .lzma ne gère pas les vérifications d'intégrité. Le contrôle d'intégrité (s'il y en a) est vérifié lorsque le fichier .xz est décompressé.
Types de vérification pris en charge :
Ne pas calculer de vérification d'intégrité du tout. C'est généralement une mauvaise idée. Cela peut être utile lorsque l'intégrité des données est vérifiée de toute façon par d'autres manières.
Calculer CRC32 en utilisant le polynôme de IEEE-802.3 (Ethernet)
Calculer CRC64 en utilisant le polynôme de ECMA-182. C'est la manière utilisée par défaut, car c'est légèrement mieux que CRC32 pour détecter les fichiers endommagés et la différence de vitesse est négligeable.
Calculer SHA-256. C'est quelque peu plus lent que CRC32 et CRC64.
L'intégrité des en-têtes .xz est toujours vérifiée avec CRC32. Il n'est pas possible de le changer ou de le désactiver.
Ne pas contrôler la vérification d'intégrité des données lors de la décompression. Les valeurs CRC32 dans les en-têtes .xz seront normalement toujours vérifiées.
N'utilisez pas cette option à moins de savoir ce que vous faites. Les raisons possibles pour utiliser cette option :
  • Essayer de récupérer des données d'un fichier .xz corrompu.
  • Accélérer la décompression. Cela importe surtout avec SHA-256 ou avec les fichiers qui ont été compressés extrêmement bien. Il est recommandé de ne pas utiliser cette option dans ce but à moins que l'intégrité du fichier ne soit vérifiée extérieurement d'une autre manière.
-0 ... -9
Choisir un niveau de compression prédéfini. La valeur par défaut est 6. Si plusieurs niveaux de préréglage sont spécifiés, c'est le dernier qui sera pris en compte. Si une chaîne de filtres personnalisée a déjà été choisie, définir un niveau de compression préréglé efface la chaîne de filtres personnalisée.
Les différences entre les préréglages sont plus significatives qu'avec gzip(1) et bzip2(1). les réglages de compression sélectionnés déterminent les exigences en mémoire pour la décompression, ainsi, utiliser un niveau de préréglage trop élevé peut rendre difficile à décompresser un fichier sur un vieux système avec peu de RAM. Clairement, ce n'est pas une bonne idée d'utiliser -9 aveuglément pour tout comme ça l'est souvent avec gzip(1) et bzip2(1).
-0 ... -3
Ce sont des préréglages relativement rapides. 0 est parfois plus rapide que gzip -9 tout en compressant bien mieux. Les réglages plus élevés ont souvent une rapidité comparable à celle de bzip2(1) avec un taux de compression comparable ou meilleur, même si les résultats dépendent beaucoup du genre de données compressées.
-4 ... -6
Bonne à très bonne compression tout en gardant un usage raisonnable de la mémoire lors de la décompression même pour de vieux systèmes. La valeur par défaut est -6, ce qui est habituellement un bon choix (par exemple pour distribuer des fichiers nécessitants d'être décompressibles même sur de vieux systèmes avec seulement 16o de RAM). (Il peut aussi être intéressant d'utiliser -5e ou -6e. Voir --extreme.)
-7 ... -9
C'est comme -6 mais avec des besoins en mémoire plus élevés pour la compression et la décompression. Ce n'est utile que lorsque les fichiers sont plus gros que 8 Mio, 16 Mio et 32 Mio respectivement.
Sur le même matériel, la vitesse de décompression est sensiblement un nombre constant d'octets de données compressées par seconde. En d'autres termes, meilleure est la compression, plus rapide sera en général la décompression. Cela signifie aussi que la quantité de sortie non compressée produite par seconde peut varier beaucoup.
Le tableau suivant résume les caractéristiques des préréglages :

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    
Descriptions des colonnes :
  • DictSize est la taille du dictionnaire de LZMA2. Utiliser un dictionnaire plus gros que la taille du fichier non compressé est un gaspillage de mémoire. C'est pourquoi il est bon d'éviter d'utiliser les préréglages de -7 à -9 lorsqu'il n'y en a pas vraiment besoin. A -6 et plus bas, la quantité de mémoire gaspillée est généralement assez basse pour ne pas être un problème.
  • CompCPU est une représentation simplifiée des préréglages de LZMA2 qui affectent la vitesse de compression. La taille du dictionnaire aussi affecte la vitesse, alors comme CompCPU est le même pour les niveaux de -6 à -9, les plus haut niveaux tendent à être un peu moins rapides. Pour être encore moins rapide et du coup obtenir peut être une meilleure compression, consultez --extreme.
  • CompMem contient les besoins en mémoire du compresseur en mode mono-thread. Cela devrait à peine varier entre les versions de xz. Les besoins en mémoire de quelques uns des futurs modes multi-thread devraient sensiblement augmenter par rapport au mode mono-thread.
  • DecMem contient les besoins en mémoire du décompresseur. Ce sont les réglages de la compression qui déterminent les besoins en mémoire de la décompression. L'exacte utilisation de la mémoire est légèrement supérieure à la taille du dictionnaire LZMA2, mais les valeurs dans la table ont été arrondies au prochain Mio supérieur.
Utilisez un variant plus lent que les préréglages (-0 à -9) pour espérer avoir un taux de compression légèrement meilleur, mais en cas de malchance cela peut être pire. L'utilisation mémoire du décompresseur n'est pas affectée, mais l'utilisation mémoire du compresseur augmente un peu aux niveaux de préréglages de -0 à -3.
Dans la mesure où il y a deux préréglages avec des tailles de dictionnaire de 4 Mio et 8 o, les préréglages -3e et -5e utilisent des réglages légèrement plus rapides que -4e et -6e, respectivement. De cette manière, il n'y a pas deux préréglages identiques.

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    
Par exemple, il y a un total de quatre préréglages qui utilisent un dictionnaire de 8 Mio et qui sont dans l'ordre du plus rapide au plus lent : -5, -6, -5e et -6e.
Il y a néanmoins des alias trompeurs pour -0 et -9, respectivement. Ils ne sont fournis que pour des besoins de rétro-compatibilité avec les utilitaires LZMA. Évitez d'utiliser ces options.
Lors de la compression dans le format .xz, les données de l'entrée sont réparties en blocs de taille octets. Les blocs sont compressés indépendamment les un des autres, ce qui aide avec le mode multithread (multi-threading) et rend possible la décompression à accès aléatoire limité. Cette option est typiquement utilisée pour outrepasser la taille de bloc en mode multithread, mais cette option peut aussi être utilisée en mode mono-thread.
En mode multithread, environ trois fois la taille octets seront alloués à chaque thread pour mettre en mémoire tampon les entrées et sorties. Par défaut, la taille est trois fois la taille du dictionnaire LZMA2 ou 1 Mio, en fonction de ce qui convient le mieux. Habituellement, une bonne valeur est deux à quatre fois la taille du dictionnaire LZMA2 ou au moins 1 Mio. Utiliser une taille moindre que celle du dictionnaire LZMA2 est un gaspillage de RAM car alors la mémoire tampon du dictionnaire LZMA2 ne sera jamais entièrement utilisée. Les tailles des blocs sont stockées dans les en-têtes de blocs, qui seront utilisés dans une future version de xz pour la décompression multithreadée.
Par défaut, il n'y a pas de répartition de bloc en mode mono-thread. Régler cette option n'affecte pas l'utilisation de la mémoire. Aucune information de taille n'est stockée dans l'en-tête de bloc, par conséquent les fichiers créés en mode single-thread ne seront pas identiques aux fichiers créés en mode multi-thread. Le manque d'information de taille signifie aussi qu'une future version de xz ne sera pas capable de décompresser les fichiers en mode multi-thread.
Lors de la compression dans le format .xz, commencer un nouveau bloc après les intervalles donnés des données non compressées.
Les tailles non-compressées des blocs sont spécifiées sous forme de liste séparée par des virgules. Omettre une taille (deux ou plus virgules consécutives) est un raccourci pour utiliser la taille du bloc précédent.
Si le fichier en entrée est plus grand que la somme des tailles, la dernière valeur est répétée jusqu'à la fin du fichier. Une valeur spéciale de 0 peut être utilisée comme étant la dernière valeur pour indiquer que le reste du fichier devrait être encodé comme un simple bloc.
Si on spécifie des tailles qui excèdent la taille du bloc de l'encodeur (soit la valeur en mode threadé, soit la valeur spécifiée avec --block-size=taille), l'encodeur créera des blocs supplémentaires tout en gardant les limites indiquées dans tailles. Par exemple, si on indique --block-size=10MiB--block-list=5MiB,10MiB,8MiB,12MiB,24MiB et que le fichier fait 80Mio, on aura 11 blocs de 5, 10, 8, 2, 10, 10, 4, 10, 10, et 1 Mio.
En mode multi-threadé les tailles de blocs sont stockées dans les en-têtes du bloc. Cela ne se fait pas en mode mono-threadé, la sortie encodée ne sera donc pas identique à celle faite en mode multi-threadé.
Lors de la compression, si plus que temps_d'attente millisecondes (un entier positif) se sont écoulées depuis le précédent vidage et que lire plus de données bloquerait, toutes les données d'entrée en attente sont vidées de l'encodeur et mises à disposition dans le flux de sortie. Cela peut être utile si xz est utilisé pour compresser les données qui sont diffusées sur un réseau. Des petites valeurs de temps_d'attente rendent les données disponibles à l'extrémité réceptrice avec un léger retard, mais les grandes valeurs de temps_d'attente donnent un meilleur taux de compression.
Cette option est désactivée par défaut. Si cette option est indiquée plus d'une fois, la dernière prend effet. La valeur spéciale de temps_d'attente de 0 peut être utilisée pour explicitement désactiver cette option.
Cette option n'est pas disponible sur les systèmes qui ne sont pas POSIX.
Cette option est encore expérimentale. Actuellement, xz ne convient pas pour décompresser le flux en temps réel en raison de la façon dont xz effectue la mise en mémoire tampon.
Indiquer une limite d'utilisation de la mémoire pour la compression. Si cette option est indiquée plusieurs fois, c'est la dernière qui est prise en compte.
Si les paramètres de compression dépassent la limite, xz ajustera les paramètres à la baisse pour que la limite ne soit plus dépassée et affichera un avis indiquant que l'ajustement automatique a été effectué. De tels ajustements ne sont pas effectués lors de la compression avec --format=raw ou si --no-adjust a été spécifié. Dans ces cas, une erreur est affichée et xz se termine avec le code de retour 1.
La limite peut être indiquée de plusieurs façons :
  • La limite peut être une valeur absolue en octets. Utiliser un suffixe d'entier comme MiB peut être utile. Exemple : --memlimit-compress=80MiB
  • La limite peut être indiquée sous forme d'un pourcentage de la mémoire physique totale (RAM). Cela peut être particulièrement utile quand la variable d'environnement XZ_DEFAULTS est indiquée dans un script d'initialisation de l'interpréteur partagé entre différents ordinateurs. De cette façon la limite est automatiquement plus grande sur les systèmes avec plus de mémoire. Exemple : --memlimit=70%
  • La limite peut être réinitialisée à sa valeur par défaut en la réglant sur 0. Cela équivaut actuellement à régler la limite sur max (aucune limite d'utilisation de la mémoire). Quand la prise en charge du mode multi-thread (multi-threading) sera implémentée, il devrait y avoir une différence entre 0 et max en mode multithreadé, il est donc recommandé d'utiliser 0 au lieu de max tant que les détails n'ont pas été décidés.
Pour le xz en 32 bits, il y a un cas particulier : si la limite est supérieure à 4020o, elle est rabaissée à 4020o. (Les valeurs 0 et max ne sont pas affectées par cela. Il n'y a pas d'option similaire pour la décompression). Celà peut s'avérer utile lorsqu'un exécutable 32-bits a accès à un espace d'adresse de 4 Gio sans s'avérer néfaste dans les autres situations.
Voir aussi la section Utilisation de la mémoire.
Régler une limite d'utilisation de la mémoire pour la décompression. Cela a un effet sur le mode --list. Si l'opération n'est pas possible sans dépasser la limite, xz affichera une erreur et la décompression échouera. Voir --memlimit-compress=limite pour les manières possibles d'indiquer la limite.
C'est équivalent à indiquer --memlimit-compress=limite--memlimit-decompress=limite.
Afficher une erreur et quitter si les réglages de compression dépassent la limite d'utilisation de la mémoire. Le comportement par défaut consiste à ajuster les réglages vers le bas pour que l'utilisation de la mémoire ne soit pas dépassée. L'ajustement automatique est toujours désactivé lors de la création de flux bruts (--format=raw).
Indiquer le nombre de threads à utiliser. Régler threads à la valeur spéciale 0 fait que xz utilisera autant de threads qu'il y a de cœurs de CPU sur le système. Le nombre effectif de threads peut être moins que threads si le fichier en entrée n'est pas assez gros pour la threading avec les réglages donnés ou si l'utilisation de plusieurs threads dépasserait la limite d'utilisation mémoire.
Actuellement, la seule méthode de gestion avec des threads consiste à séparer l'entrée en blocs et de les compresser indépendamment les uns des autres. La taille par défaut des blocs dépend du niveau de compression et peut être remplacée avec l'option --block-size=taille.
La décompression threadée n'a pas encore été implémentée. Cela ne fonctionnera qu'avec des fichiers contenant de multiples blocs avec une information sur la taille dans les en-têtes de bloc. Tous les fichiers compressés en mode multithread sattisfont cette condition, mais pas les fichiers compressés en mode single-thread même si l'option --block-size=taille est utilisée.

Chaînes de filtres de compresseur personnalisées

Une chaîne de filtres personnalisée permet d'indiquer les réglages de la compression en détail au lieu de recourir aux préréglages. Lorsque une chaîne de filtres personnalisée est indiquée, les options préréglées (0 à 9 et --extreme) précédement sur la ligne de commande sont oubliées. Si une option de préréglage est indiquée après une ou plusieurs options de chaîne de filtre personnalisée, le nouveau préréglage prend effet et les options de la chaîne de filtres personnalisée précédement indiquée sont oubliées.

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.

Ajouter le filtre LZMA1 ou LZMA2 à la chaîne de filtres. Ces filtres ne peuvent être utilisés que comme dernier filtre dans la chaîne.
LZMA1 est un filtre historique, qui n'est pris en charge presque uniquement à cause de l'ancien format de fichier .lzma, qui ne prend en charge que LZMA1. LZMA2 est une version mise à jour de LZMA1 pour régler certains problèmes pratiques de LZMA1. Le format xz utilise LZMA2 et ne prend pas du tout en charge LZMA1. Les taux et vitesses de compression de LZMA1 et LZMA2 sont pratiquement identiques.
LZMA1 et LZMA2 partagent le même ensemble d'options :
Réinitialiser toutes les options de LZMA1 ou de LZMA2 à préréglage. préréglage consiste en un entier, qui peut être suivi de modificateurs de préréglage à une lettre. L'entier peut être de 0 à 9, correspondant aux options -0 à -9 de la ligne de commandes. Le seul modificateur pris en charge est actuellement e, qui correspond à --extreme. Si preset n'est pas indiqué, Les valeurs par défaut des options LZMA1 ou LZMA2 sont prises du préréglage 6.
La taille du dictionnaire (historique du tampon) indique combien d'octets des données récement décompressées sont gardés en mémoire. L'algorithme essaie de trouver les séquences d'octets répétées (identiques) dans les données décompressées et les remplace par les données actuellement dans le dictionnaire. Plus gros est le dictionnaire, plus grande est la chance de trouver une correspondance. Ainsi, l'augmentation de la taille du dictionnaire augmente habituellement le taux de compression, mais un dictionnaire plus gros que le fichier non compressé est un gachis de mémoire.
Généralement la taille du dictionnaire est entre 64 Kio et 64 Mio. Le minimum étant 4 Kio. La taille maximale pour la compression est habituellement 1,5 Gio (1536 Mio). Le décompresseur prend en charge les dictionnaires jusqu'à un octet de moins que 4 Gio, ce qui est le maximum pour les formats de flux LZMA1 et LZMA2.
La taille du dictionnaire et le chercheur de correspondance (match finder) (mf) déterminent ensemble l'utilisation de la mémoire de l'encodeur LZMA1 ou LZMA2. La même (ou une plus grosse) taille de dictionnaire est requise pour décompresser que ce qui a été utilisé pour la compression, ainsi l'utilisation de la mémoire du décodeur est déterminée par la taille du dictionnaire utilisée lors de la compression. Les en-têtes de .xz stockent la taille de dictionnaire sous la forme 2^n ou 2^n + 2^(n-1), de sorte que ces tailles sont quelque peu préférées pour la compression. Les autres tailles seront arrondies à la hausse lorsque stockées dans les en-têtes de .xz.
Spécifiez le nombre d'octets de contexte littéraux. Le minimum est 0 et le maximum est 4. La valeur par défaut est 3. En plus, la somme de lc et lp ne doit pas excéder 4.
Tous les octets qui ne peuvent pas être codés comme des correspondances sont codés comme des littéraux. C'est à dire que les littéraux sont simplement des octets 8 bits encodés un à la fois.
Le codage littéral part du principe que les bits lc les plus élevés de l'octet décompressé précédent sont en corrélation avec l'octet suivant. Par exemple dans un texte anglais typique, une lettre majuscule est souvent suivie d'une lettre minuscule, et une lettre minuscule est généralement suivie d'une autre lettre minuscule. Dans le jeu de caractères US-ASCII, les trois bits les plus haut sont 010 pour les lettres majuscules et 011 pour les minuscules. Lorsque lc est au final 3, le codage littéral peut tirer avantage de cette propriété dans les données décompressées.
La valeur par défaut (3) est généralement la bonne. Si vous voulez une compression maximale, essayez lc=4. Cela aide parfois un petit peu, et parfois cela empire la compression. Si cela l'empire, essayez lc=2 aussi.
Indiquer le nombre de bits de position littérale. Le minimum est 0 et le maximum 4; par défaut c'est 0.
Lp affecte le type d'alignement dans les données décompressées qui est présumé lors de l'encodage des littéraux. Voir pb ci dessous pour plus d'information sur l'alignement.
Indiquer le nombre de bits de position. Le minimum est 0 et le maximum 4; par défaut 2.
Pb affecte quel genre d'alignement est présumé en général dans les données non compressées. Par défaut c'est un alignement de quatre octets (2^pb=2^2=4), ce qui est généralement un bon choix lorsqu'il n'y a pas de meilleure estimation.
Quand l'alignement est connu, régler en conséquence pb pourrait réduire un peu la taille du fichier. Par ex. avec les fichiers texte ayant un alignement d'un octet (US-ASCII, ISO-8859-*, UTF-8), indiquer pb=0 peut légèrement améliorer la compression. Pour les textes UTF-16, pb=1 est un bon choix. Si l'alignement est un nombre impair comme 3 octets, pb=0 pourrait être le meilleur choix.
Même si l'alignement présumé peut être ajusté avec pb et lp, LZMA1 et LZMA2 favorisent toujours légèrement l'alignement sur 16 octets. Il peut être utile d'en tenir compte lors de la conception de formats de fichiers susceptibles d'être souvent compressés avec LZMA1 ou LZMA2.
La recherche de correspondance a un effet important sur la vitesse de l'encodeur, l'utilisation de la mémoire et le taux de compression. En général, les chercheurs de correspondance de chaîne de hachage sont plus rapides que les chercheurs de correspondance d'un arbre binaire. Par défaut, cela dépend du préréglage : 0 utilise hc3, 1-3 utilise hc4, et le reste utilise bt4.
Les chercheurs de correspondance suivants sont pris en charge. Les formules d'utilisation de la mémoire ci-dessous sont des approximations grossières qui sont les plus proches de la réalité lorsque dict est une puissance de deux.
Chaîne de hachage avec hachage de 2 et 3 octets
Valeur minimale pour nice : 3
Utilisation de la mémoire :
dict * 7.5 (if dict <= 16 Mio);
dict * 5.5 + 64 MiB (si dict > 16 Mio)
Chaîne de hachage avec hachage de 2, 3 et 4 octets
Valeur minimale pour nice : 4
Utilisation de la mémoire :
dict * 7.5 (si dict <= 32 Mio)
dict * 6.5 (si dict > 32 Mio)
Arbre binaire avec hachage de 2 octets
Valeur minimale pour nice : 2
Utilisation de la mémoire : dict * 9.5
Arbre binaire avec hachage de 2 et 3 octets
Valeur minimale pour nice : 3
Utilisation de la mémoire :
dict * 11.5 (si dict <= 16 Mio);
dict * 9.5 + 64 MiB (si dict > 16 Mio)
Arbre binaire avec hachage de 2, 3 et 4 octets
Valeur minimale pour nice : 4
Utilisation de la mémoire :
dict * 11.5 (si dict <= 32 Mio);
dict * 10.5 (si dict > 32 Mio)
Le mode de compression indique la méthode pour analyser les données produites par le chercheur de correspondance. Les modes pris en charge sont fast et normal. Par défaut c'est fast pour les préréglages de 0 à 3 et normal pour les préréglages de 4 à 9.
Habituellement, fast est utilisé avec les chercheurs de correspondance de chaîne de hachage et normal avec les chercheurs de correspondance d'arbre binaire. C'est aussi ce que font les préréglages.
Spécifier ce qui est considéré comme une bonne longueur pour une correspondance. Une fois que la correspondance d'au moins nice octets est trouvée, l'algorithme arrête de chercher de meilleures correspondances possibles.
nice peut être 2 273 octets. Des valeurs plus élevées ont tendance à donner un meilleur taux de compression au détriment de la vitesse. La valeur par défaut dépend du préréglage.
Spécifier la profondeur de recherche maximale dans l'outil de recherche de correspondances. La valeur par défaut est 0, ce qui fait que le compresseur détermine une profondeur raisonnable en fonction de mf et nice.
Une profondeur raisonnable pour les chaînes de hachage est 4-100 et 16-1000 pour les arbres binaires. Utiliser des valeurs beaucoup plus grandes pour depth peut rendre l'encodeur extrèmement lent avec quelques fichiers. Évitez de fixer la profondeur à plus de 1000, sauf si vous êtes prêt à interrompre la compression au cas où elle prendrait beaucoup trop de temps.
Lors du décodage des flux bruts (--format=raw), LZMA2 nécessite seulement la taille du dictionnaire. LZMA1 nécessite aussi lc, lp et pb.
Ajouter un filtre branch/call/jump (BCJ) à la chaîne de filtres. Ces filtres ne peuvent être utilisés que s'ils ne sont pas le dernier filtre de la chaîne de filtrage.
Un filtre BCJ convertit les adresses relatives du code machine en leurs équivalents absolus. Cela ne change pas la taille des données, mais évite les redondances, ce qui peut aider LZMA2 à produire un fichier .xz 0 à 15 % plus petit. Les filtres BCJ sont toujours réversibles, ce qui fait qu'utiliser un filtre BCJ pour le mauvais type de données n'occasionne pas de perte de données, même si ça pourrait empirer légèrement le taux de compression.
Il est possible d'appliquer un filtre BCJ sur l'ensemble d'un exécutable ; il n'est pas nécessaire de l'appliquer uniquement sur la section exécutable. Appliquer un filtre BCJ sur une archive contenant à la fois des fichiers exécutables et des fichiers non-exécutables pourrait, ou non, donner de bons résultats, donc il n'est généralement pas bon d'appliquer aveuglémént un filtre BCJ lors de la compression de paquets binaires pour leur distribution.
Ces filtres BCJ sont très rapides et utilisent une quantité insignifiante de mémoire. Si un filtre BCJ améliore le taux de compression d'un fichier, il peut en même temps améliorer la vitesse de décompression. Cela parce que sur un même matériel, la vitesse de décompression de LZMA2 est approximativement un nombre fixe d'octets de données compressées par seconde.
Ces filtres BCJ présentent des problèmes connus liés au taux de compression :
  • Quelques types de fichier contiennent du code exécutable (par exemple les fichiers objet, les bibliothèques statiques et les modules du noyau Linux) ont rempli les adresses dans les instructions avec des valeurs de remplissage. Ces filtres BCJ feront toujours la conversion d'adresse, ce qui pourrait péjorer la compression avec ces fichiers.
  • L'application d'un filtre BCJ sur une archive contenant plusieurs exécutables similaires peut rendre le taux de compression moins bon que si l'on n'utilisait pas de filtre BCJ. Cela est dû au fait que le filtre BCJ ne détecte pas les limites des fichiers exécutables et ne remet pas à zéro le compteur de conversion d'adresse pour chaque exécutable.
Les deux problèmes ci-dessus seront réglés dans le futur dans un nouveau filtre. Les vieux filtres BCJ seront toujours utiles dans les systèmes embarqués, car le décodeur du nouveau filtre sera plus gros et utilisera plus de mémoire.
Les différents jeux d'instructions ont un alignement différent :

Filtre Alignement Notes
x86 1 32 bits ou 64 bits x86
PowerPC 4 Grand boutiste seulement
ARM 4 Petit-boutiste seulement
ARM-Thumb 2 Petit-boutiste seulement
IA-64 16 Grand ou petit boutiste
SPARC 4 Grand ou petit boutiste
Dans la mesure où les données filtrées par BCJ sont généralement compressées avec LZMA2, le taux de compression peut être légèrement amélioré si les options de LZMA2 sont indiquées pour la correspondance d'alignement du filtre BCJ sélectionné. Par exemple, avec le filtre IA-64, il est bon d'indiquer pb=4 avec LZMA2 (2^4=16). Le filtre x86 est une exception ; il est généralement approprié de coller à l'alignement quatre octets par défaut de LZMA2 lors de la compression d'exécutables x86.
Tous les filtres BCJ prennent en charge les mêmes options :
Spécifier le décalage de départ qui est utilisé lors de la conversion entre les adresses relatives et absolues. Le décalage doit être un multiple de l'alignement du filtre (voir la table ci-dessus). Sa valeur par défaut est zéro. En pratique, cette dernière convient ; indiquer un décalage personnalisé est la plupart du temps inutile.
Ajouter le filtre Delta à la chaîne de filtres. Le filtre Delta ne peut être utilisé que s'il n'est pas le dernier filtre dans la chaîne.
Actuellement, seul le calcul simple du delta par octet est pris en charge. Il peut être utile lors de la compression, par exemple, des images bitmap non compressées ou de l'audio PCM non compressé. Toutefois, des algorithmes spécialisés peuvent donner des résultats nettement supérieurs à ceux de Delta + de LZMA2. Cela est spécialement vrai avec le son qui est compressé plus vite et mieux par exemple avec flac(1).
options prises en charge :
Indiquer la distance du calcul delta en octets. La distance doit être comprise entre 1 et 256. La valeur par défaut est 1.
Par exemple, avec dist=2 et une entrée huit octets A1 B1 A2 B3 A3 B5 A4 B7, la sortie sera A1 B1 01 02 01 02 01 02.

Autres options

Supprimer les avertissements et les notifications. Indiquer cela deux fois supprimera aussi les erreurs. Cette option n'a aucun effet sur le code de retour. Cela dit, même si un avertissement était supprimé, le code de retour indiquant un avertissement sera encore utilisé.
Être bavard. Si l'erreur standard est connectée à un terminal, xz affichera une barre de progression. Indiquer --verbose deux fois donnera une sortie encore plus bavarde.
La barre de progression montre l'information suivante :
  • Le pourcentage de complétion est montré si la taille du fichier en entrée est connue. Néanmoins, le pourcentage ne peut pas être montré en cas de redirection.
  • Quantité de données compressées produites (compression) ou consommées (décompression).
  • Quantité de données non compressées consommées (compression) ou produites (décompression).
  • Le taux de compression, calculé en divisant la quantité de données compréssées déjà traitées par la quantité de données décompressées déjà traitées.
  • Vitesse de compression ou de décompression. Elle correspond à la quantité de données non compressées consommées (compression) ou produites (décompression) par seconde. Elle apparait quelques secondes après le début du traitement du fichier par xz.
  • Temps écoulé dans le format M:SS ou H:MM:SS.
  • Le temps estimé restant n'est montré que lorsque la taille du fichier en entrée est connu et que quelques secondes se sont écoulées depuis que xz a commencé à traiter le fichier. Le temps est montré dans un format moins précis qui n'a jamais de deux-point(:), par exemple 2 min 30 s.
Lorsque l'erreur standard n'est pas un terminal, --verbose fera écrire à xz le nom de fichier, la taille compressée, la taille décompressée, le taux de compression, et éventuellement aussi la vitesse et le temps écoulé sur une seule ligne de l'erreur standard après avoir compressé ou décompressé le fichier. La vitesse et le temps écoulé sont inclus seulement lorsque l'opération ne prend pas plus que quelques secondes. Si l'opération n'a pas fini, par exemple à cause d'une interruption faite par l'utilisateur, le pourcentage de complétion aussi est écrit si la taille du fichier en entrée est connue.
Ne pas mettre le code de retour à 2 même si une condition méritant un avertissement a été détectée. Cette option n'affecte pas le niveau de verbosité, néanmoins, les deux options --quiet et --no-warn doivent être utilisées pour ne pas afficher d'avertissements, ni altérer le code de retour.
Afficher les messages dans un format analysable par une machine. Ceci est destiné à faciliter l'écriture des frontaux qui voudraient utiliser xz plutôt que liblzma, ce qui pourrait être le cas pour différents scripts. La sortie avec cette option activée est destinée à rester stable sur les différentes versions de xz. Consulter le paragraphe ROBOT MODE pour les détails.
Afficher, dans un format lisible par l'humain, de combien de mémoire physique (RAM) dispose le système selon xz et les limites d'utilisation de la mémoire pour la compression et décompression, et quitter.
Afficher un message d'aide décrivant les options les plus couramment utilisées et quitter.
Afficher un message d'aide décrivant toutes les options de xz et quitter.
Afficher le numéro de version de xz et de liblzma dans un format lisible par un humain. Pour obtenir une sortie analysable par la machine, spécifiez --robot avant --version.

MODE ROBOT

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.

Version

xz --robot --version affichera le numéro de version de xz et liblzma dans le format suivant :

XZ_VERSION=XYYYZZZS
LIBLZMA_VERSION=XYYYZZZS

Version majeure.
Version mineure. Les numéros pairs sont stables. Les numéros impairs sont des versions alpha ou beta.
Niveau de correctif pour les options stables ou juste un compteur pour les options de développement.
Stabilité. 0 est alpha, 1 est bêta et 2 est stable. S devrait toujours être 2 quand YYY est pair.

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.

Information de limite de mémoire

xz --robot --info-memory affiche une seule ligne avec trois colonnes séparées par des tabulations :

1.
Quantité totale de mémoire physique (RAM) en octets
2.
Limite d'utilisation de la mémoire pour la compression en octets. Une valeur spéciale de zéro indique le réglage par défaut, lequel en mode mono-thread indique qu'il n'y a pas de limite.
3.
Limite d'utilisation de la mémoire pour la décompression en octets. Une valeur spéciale de zéro indique le réglage par défaut, ce qui est équivalent à sans limite en mode mono-thread.

Dans le futur, la sortie de xz --robot --info-memory pourrait avoir plus de colonnes, mais jamais plus qu'une ligne unique.

Mode liste

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 :

C'est toujours la première ligne au début de la liste d'un fichier. La seconde colonne de la ligne est le nom de fichier.
Cette ligne contient l'information globale sur le fichier .xz. Cette ligne est toujours écrite après la ligne name.
Ce type de ligne n'est utilisée que lorsque --verbose a été indiquée. Il y a autant de lignes stream qu'il y a de flux dans le fichier .xz.
Ce type de ligne n'est utilisé seulement lorsque --verbose a été indiquée. Il y a autant de lignes block qu'il y a de blocs dans le fichier .xz. Les lignes block sont affichées après toutes les lignes stream ; les différents types de lignes ne sont pas imbriqués.
Ce type de ligne n'est utilisé que lorsque --verbose a été indiqué deux fois. Cette ligne est affichée après toutes les lignes block. Comme la ligne file, la ligne summary contient l'information globale sur le fichier .xz.
Cette ligne est toujours la toute dernière ligne de la sortie. Elle affiche les comptes et les tailles totaux.

Les colonnes des lignes file :

2.
Nombre de flux dans le fichier
3.
Nombre total de blocs dans le ou les flux
4.
Taille compressée du fichier
5.
Taille décompressée du fichier
6.
Taux de compression, par exemple 0.123. Si le taux est supérieur à 9 999, trois tirets (---) sont affichés au lieu du taux.
7.
Liste de noms de contrôles d'intégrité séparés par des virgules. Les chaînes suivantes sont utilisées pour les types de vérification connus : None, CRC32, CRC64 et SHA256. Pour le types de vérification inconnus, Unknown-N est utilisé, où N est un identifiant de vérification sous la forme d'un nombre décimal (un ou deux chiffres).
8.
Taille totale du remplissage du flux dans le fichier

Les colonnes des lignes stream :

2.
Numéro de flux (le premier flux a le numéro 1)
3.
Nombre de blocs dans le flux
4.
Décalage de départ compressé
5.
Décalage de départ décompressé
6.
Taille compressée (ne comprend pas le remplissage du flux)
7.
Taille décompressée
8.
Taux de compression
9.
Nom de la vérification d'intégrité
10.
Taille du remplissage de flux

Les colonnes des lignes block :

2.
Numéro du flux qui contient ce bloc
3.
Numéro du bloc relatif au commencement du flux (le premier bloc a pournuméro 1)
4.
Numéro du bloc relatif au début du fichier
5.
Décalage de départ compressé relatif au début du fichier
6.
Décalage de départ décompressé relatif au début du fichier
7.
Taille compressée totale du bloc (en-têtes inclus)
8.
Taille décompressée
9.
Taux de compression
10.
Nom de la vérification d'intégrité

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 :

11.
Valeur de la vérification d'intégrité en hexadécimal
12.
Taille d'en-tête de bloc
13.
Drapeaux du bloc : c indique que la taille compressée est présente, et u indique que la taille décompréssée est présente. Si le drapeau n'est pas indiqué, un tiret (-) est affiché à la place pour que la longueur de la chaîne reste fixe. De nouveaux drapeaux pourraient être ajoutés à la fin de la chaîne dans le futur.
14.
Taille des données effectivement compressées dans le bloc (en excluant l'en-tête de bloc, le remplissage de bloc et les champs de vérification).
15.
Quantité de mémoire (en octets) nécessaire pour décompresser ce bloc avec cette version de xz.
16.
Chaîne de filtrage. Remarquez que la plupart des options utilisées au moment de la compression ne peuvent pas être connues, car seules les options nécessaires pour la décompression sont stockées dans les en-têtes .xz.

Les colonnes des lignes summary :

2.
Quantité de mémoire (en octets) nécessaire pour décompresser ce fichier avec cette version de xz.
3.
yes ou no indique si tous les en-têtes de bloc stockent à la fois la taille compressée et la taille décompressée.

Depuis xz 5.1.2alpha:

4.
Version minimale de xz nécessaire pour décompresser le fichier.

Les colonnes de la ligne totals :

2.
Nombre de flux
3.
Nombre de blocs
4.
Taille compressée
5.
Taille décompressée
6.
Taux de compression moyen
7.
Liste séparée par des virgules des noms de vérification d'intégrité qui étaient présents dans les fichiers
8.
Taille de remplissage de flux
9.
Nombre de fichiers. Permet de garder l'ordre des colonnes précédentes comme sur les lignes file.

Si --verbose a été indiqué deux fois, des colonnes supplémentaires sont incluses sur la ligne totals :

10.
Quantité maximale de mémoire (en octets) nécessaire pour décompresser les fichiers avec cette version de xz.
11.
yes ou no indique si tous les en-têtes de bloc stockent à la fois la taille compressée et la taille décompressée.

Depuis xz 5.1.2alpha:

12.
Version minimale de xz nécessaire pour décompresser le fichier.

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.

CODE DE RETOUR

0
Tout est bon.
1
Une erreur est survenue.
2
Quelque chose méritant un avertissement s'est produit, mais aucune erreur véritable n'est survenue.

Les notifications (pas les avertissements ou les erreurs) affichées sur l'erreur standard n'affectent pas le code de retour.

ENVIRONNEMENT

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.

Options par défaut propres à l'utilisateur ou pour tout le système. Elles sont le plus souvent définies dans un script d'initialisation de l'interpréteur pour activer le limiteur d'utilisation de la mémoire de xz par défaut. A part pour les scripts d'initialisation de l'interpréteur ou des cas similaires, les sripts ne doivent jamais définir ou désactiver XZ_DEFAULTS.
Cela permet de passer des options à xz lorsqu'il n'est pas possible de définir ces options directement sur la ligne de commande xz. C'est le cas, par exemple, lorsque xz est lancé par un script ou un outil, par exemple tar(1) de GNU :

XZ_OPT=-2v tar caf toto.tar.xz toto
Les scripts peuvent utiliser XZ_OPT, par exemple pour définir des options de compression par défaut spécifiques au script. Il est toujours recommandé d'autoriser les utilisateurs à outrepasser XZ_OPT si cela est raisonnable, comme par exemple dans les scripts sh(1) quelquechose comme ceci devrait être utilisé :

XZ_OPT=${XZ_OPT-"-7e"}
export XZ_OPT

Compatibilité des utilitaires LZMA

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.

Niveaux de préréglage de la compression

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 LZMA Utils 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.

Fichiers .lzma en flux ou non

La taille non compressée du fichier peut être stockée dans l'en-tête .lzma. C'est ainsi que font les outils LZMA avec les fichiers normaux. L'alternative est d'indiquer que la taille décompressée est inconnue et utiliser un marqueur de fin de charge pour indiquer où le décompresseur doit s'arrêter. Les outils LZMA utilisent cette méthode quand la taille décompressée n'est pas connue, ce qui est le cas par exemple dans les redirections.

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.

Fichiers .lzma non pris en charge

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 de problème en pratique, car pratiquement tous les fichiers .lzma ont été compressés avec des réglages que liblzma accepte.

Déchets excédentaires

Lors de la décompression, 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.

NOTES

La sortie compressée peut varier

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.

Décompresseurs .xz embarqués

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.

EXEMPLES

Bases

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

Créer truc.tar.xz avec le préréglage -4e (-4--extreme), lequel est plus lent que par exemle -6 (par défaut), mais nécessite moins de mémoire pour la compression et la décompression (48 Mio et 5 Mio, respectivement) :

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

Compression en parallèle de plusieurs fichiers

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.

Mode robot

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

Chaînes de filtres de compresseur personnalisées

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

Si vous savez qu'un fichier nécessite un dictionnaire relativement gros (par exemple 32 Mio) pour bien compresser, mais que vous vouliez le compresser plus vite que xz-8 ne le ferait, un préréglage avec une valeur basse de CompCPU (par exemple 1) peut être modifié pour utiliser un dictionnaire plus gros :

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.

Parfois le temps de compression importe peu, mais l'utilisation de la mémoire du décompresseur doit être maintenue basse (par exemple, pour rendre possible la décompression d'un fichier sur un système embarqué). La commande suivante utilise -6e (-6 --extreme) comme base, et définit le dictionnaire à seulement 64 Kio. Le fichier qui en résulte peut être décompressé avec XZ Embedded (c'est pourquoi il y a --check=crc32) en utilisant environ 100 Kio de mémoire.

xz --check=crc32 --lzma2=preset=6e,dict=64KiB toto

Si vous voulez réduire au maximum le nombre d'octets, ajuster le nombre de bits de contexte littéral (lc) et le nombre de bits de position (pb) peut parfois être bénéfique. Ajuster le nombre de bits de position littéraux (literal position bits)(lp) devrait aider aussi, mais généralement lc et pb sont plus importants. Par exemple, une archive de code source contient majoritairement du texte US-ASCII, donc quelquechose du style de ce qui suit devrait donner un fichier légèrement (approximativement O.1%) plus petit que xz -6e (essayez aussi sans lc=4) :

xz --lzma2=preset=6e,pb=0,lc=4 code_source.tar

Utiliser un autre filtre avec LZMA2 peut améliorer la compression avec certains types de fichiers. Par exemple, pour compresser une bibliothèque partagée x86-32 ou x86-64 en utilisant le filtre BCJ x86 :

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.

L'image doit être sauvée dans un format non compressé, comme TIFF non compressé. Le paramètre de distance du filtre Delta est défini pour correspondre au nombre d'octets par pixel dans l'image. Par exemple, une image RGB 24 bits nécessite dist=3 et il est aussi recommandé de passer pb=0 à LZMA2 pour s'adapter à l'alignement trois octets :

xz --delta=dist=3 --lzma2=pb=0 toto.tiff

Si plusieurs images ont été mises dans une seule archive (par exemple .tar), le filtre Delta les modifiera pourvu que toutes les images ont le même nombre d'octets par pixel.

VOIR AUSSI

xzdec(1), xzdiff(1), xzgrep(1), xzless(1), xzmore(1), gzip(1), bzip2(1), 7z(1)

XZ Utils: <https://tukaani.org/xz/>
XZ Embedded: <https://tukaani.org/xz/embedded.html>
LZMA SDK: <http://7-zip.org/sdk.html>

TRADUCTION

La traduction française de cette page de manuel a été créée par bubu <bubub@no-log.org>

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org.

1 février 2020 Tukaani