xz, unxz, xzcat, lzma, unlzma, lzcat - Compresser ou décompresser des fichiers .xz et .lzma
SYNTAXE
xz [option...] [fichier...]
ALIAS DE 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.
Lorsque vous écrivez des scripts qui doivent décompresser des fichiers, il est recommandé d'utiliser toujours 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 commande similaire à gzip(1) et bzip2(1). Le format de fichier natif est le format .xz, mais les formats .lzma hérités utilisés par LZMA Utils et les flux compressés bruts sans en-têtes de format de conteneur sont également pris en charge. De plus, la décompression du format .lz utilisé par lzip est prise en charge.
xz compresse ou décompresse chaque fichier en fonction du mode d'opération sélectionné. Si aucun fichier n'est spécifié ou si le fichier est -, xz lit à partir de l'entrée standard et écrit les données traitées vers la sortie standard. xz refusera (affichera une erreur et ignorera le fichier) d'écrire des données compressées vers la sortie standard si c'est un terminal. De même, xz refusera de lire des données compressées à partir de l'entrée standard si c'est un terminal.
Sauf si --stdout est spécifié, 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, .lzma ou .lz est supprimé du nom de fichier pour obtenir le nom de fichier cible. xz reconnaît également 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 si l'écriture se fait vers la sortie standard, xz affichera un avertissement et ignorera le fichier si l'une des conditions suivantes est remplie :
Le fichier n'est pas un fichier régulier. Les liens symboliques ne sont pas suivis et ne sont donc pas considérés comme des fichiers réguliers.
Le fichier a plus d'un lien physique.
Le fichier a les bits setuid, setgid ou sticky définis.
Le mode d'opération est défini sur la compression et le fichier a déjà un suffixe du format de fichier cible (.xz ou .txz lors de la compression au format .xz, et .lzma ou .tlz lors de la compression au format .lzma).
Le mode d'opération est défini sur la décompression et le fichier n'a pas de suffixe de l'un des formats de fichier pris en charge (.xz, .txz, .lzma, .tlz ou .lz).
Après avoir compressé ou décompressé le fichier avec succès, xz copie le propriétaire, le groupe, les permissions, la date et l’heure d’accès et la date et l’heure de modification du fichier source vers le fichier cible. Si la copie du groupe échoue, les permissions sont modifiées de sorte que le fichier cible ne soit pas accessible aux utilisateurs qui n’avaient pas la permission d’accéder au fichier source. xz ne prend pas encore 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é, sauf si l’option --keep a été spécifiée. Le fichier source n’est jamais supprimé si la sortie est écrite sur la sortie standard ou si une erreur se produit.
L’envoi de SIGINFO ou SIGUSR1 au processus xz fait que celui-ci affiche des informations de progression sur la sortie standard d’erreur. Ceci n’est utile que de manière limitée, car lorsqu’il s’agit d’un terminal, l’utilisation de l’option --verbose affichera automatiquement un indicateur de progression mis à jour.
Utilisation de la mémoire
L’utilisation de la mémoire de xz varie de quelques centaines de kilo-octets à plusieurs gigaoctets, en fonction des paramètres de compression. Les paramètres utilisés lors de la compression d’un fichier déterminent les exigences de mémoire du décompresseur. En général, le décompresseur a besoin de 5 % à 20 % de la quantité de mémoire dont le compresseur avait besoin lors de la création du fichier. Par exemple, la décompression d’un fichier créé avec xz -9 nécessite actuellement 65 Mo de mémoire. Cependant, il est possible d’avoir des fichiers .xz qui nécessitent plusieurs gigaoctets de mémoire pour être décompressés.
Les utilisateurs de systèmes plus anciens peuvent trouver la possibilité d’une très grande utilisation de la mémoire gênante. Pour éviter les mauvaises surprises, xz dispose d’un limiteur d’utilisation de la mémoire intégré, qui est désactivé par défaut. Bien que certains systèmes d’exploitation fournissent des moyens de limiter l’utilisation de la mémoire des processus, il a été jugé que s’y fier n’était pas assez flexible (par exemple, l’utilisation de ulimit(1) pour limiter la mémoire virtuelle a tendance à entraver mmap(2)).
Le limiteur d’utilisation de la mémoire peut être activé avec l’option de ligne de commande --memlimit=limite. Il est souvent plus pratique d’activer le limiteur par défaut en définissant la variable d’environnement XZ_DEFAULTS, par exemple, XZ_DEFAULTS=--memlimit=150MiB. Il est possible de définir les limites séparément pour la compression et la décompression en utilisant les options --memlimit-compress=limite et --memlimit-decompress=limite. L’utilisation de ces deux options en dehors de XZ_DEFAULTS est rarement utile, car une seule exécution de xz ne peut pas effectuer à la fois la compression et la décompression, et --memlimit=limite (ou -M limite) est plus court à taper sur la ligne de commande.
Si la limite d’utilisation de la mémoire spécifiée est dépassée lors de la décompression, xz affichera une erreur et la décompression du fichier échouera. Si la limite est dépassée lors de la compression, xz essaiera de réduire les paramètres afin que la limite ne soit plus dépassée (sauf en utilisant les options --format=raw ou --no-adjust). De cette façon, l’opération ne échouera pas, sauf si la limite est très faible. La réduction des paramètres est effectuée par étapes qui ne correspondent pas aux préréglages des niveaux de compression. Par exemple, si la limite est légèrement inférieure à la quantité requise pour xz -9, les paramètres seront réduits seulement un peu, et non pas jusqu’à xz -8.
Concaténation et ajout de remplissage avec les fichiers .xz
Il est possible de concaténer les fichiers .xz tels quels. xz décompressera ces fichiers comme s'il s'agissait d'un seul fichier .xz.
Il est possible d'insérer un remplissage entre les parties concaténées ou après la dernière partie. Le remplissage doit être composé 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 support qui mesure la taille des fichiers en blocs de 512 octets.
La concaténation et l'ajout de 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 optionnel est pris en charge pour indiquer facilement les grands entiers. Il ne doit y avoir aucun espace entre l'entier et le suffixe.
KiB : Multiplier l'entier par 1 024 (2^10). Ki, k, kB, K et KB sont acceptés comme synonymes de KiB.
MiB : Multiplier l'entier par 1 048 576 (2^20). Mi, m, M et MB sont acceptés comme synonymes de MiB.
GiB : 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 entière maximale prise en charge par l'option.
Mode d'opération
Si plusieurs options de mode d'opération sont spécifiées, la dernière option est prise en compte.
-z, --compress
Compresser. Il s'agit du mode d'opération par défaut lorsqu'aucune option de mode d'opération n'est spécifiée et qu'aucun autre mode d'opération n'est implicite à partir du nom de la commande (par exemple, unxz implique --decompress).
Après une compression réussie, le fichier source est supprimé, sauf si l'écriture se fait vers la sortie standard ou si l'option --keep a été spécifiée.
-d, --decompress, --uncompress
Décompresser. Après une décompression réussie, le fichier source est supprimé, sauf si l'écriture se fait vers la sortie standard ou si l'option --keep a été spécifiée.
-t, --test
Tester l'intégrité des fichiers compressés. Cette option est équivalente à --decompress --stdout, sauf que les données décompressées sont supprimées au lieu d'être écrites vers la sortie standard. Aucun fichier n'est créé ou supprimé.
-l, --list
Afficher des informations sur les fichiers compressés. Aucune sortie dé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 à partir de la sortie standard ou à partir d'autres sources non accessibles de manière aléatoire.
La liste par défaut affiche des informations de base sur les fichiers, un fichier par ligne. Pour obtenir des informations plus détaillées, utilisez également l'option --verbose. Pour encore plus d'informations, utilisez --verbose deux fois, mais notez que cela peut être lent, car l'obtention de toutes les informations supplémentaires nécessite de nombreux accès aléatoires. La largeur de la sortie détaillée dépasse 80 caractères, de sorte que l'envoi de la sortie à, par exemple, less -S peut être pratique si le terminal n'est pas assez large.
La sortie exacte peut varier en fonction des versions de xz et des paramètres régionaux. Pour une sortie lisible par machine, utilisez les options --robot et --list.
Modificateurs d'opération
-k, --keep
Ne supprime pas les fichiers d'entrée.
Depuis xz 5.2.6, cette option permet également à xz de compresser ou de décompresser même si l'entrée est un lien symbolique vers un fichier régulier, possède plus d'un lien physique ou a les bits setuid, setgid ou sticky définis. Les bits setuid, setgid et sticky ne sont pas copiés dans le fichier cible. Dans les versions antérieures, cela n'était fait que avec l'option --force.
-f, --force
Cette option a plusieurs effets :
Si le fichier cible existe déjà, il est supprimé avant la compression ou la décompression.
Compresse ou décompresse même si l'entrée est un lien symbolique vers un fichier régulier, possède plus d'un lien physique ou a les bits setuid, setgid ou sticky définis. Les bits setuid, setgid et sticky ne sont pas copiés dans le fichier cible.
Lorsqu'elle est utilisée avec --decompress --stdout et que xz ne peut pas reconnaître le type du fichier source, copie le fichier source tel quel vers la sortie standard. Cela permet d'utiliser xzcat --force comme [cat]({filename}../../cat)(1) pour les fichiers qui n'ont pas été compressés avec xz. Notez que dans le futur, xz pourrait prendre en charge de nouveaux formats de fichiers compressés, ce qui pourrait amener xz à décompresser davantage de types de fichiers au lieu de les copier tels quels vers la sortie standard. L'option --format=format peut être utilisée pour limiter xz à la décompression d'un seul format de fichier.
-c, --stdout, --to-stdout
Écrit les données compressées ou décompressées vers la sortie standard au lieu d'un fichier. Ceci implique l'option --keep.
--single-stream
Décompresse uniquement le premier flux .xz et ignore silencieusement les données d'entrée restantes qui pourraient suivre le flux. Normalement, de telles données parasites provoquent l'affichage d'une erreur par xz.
xz ne décompresse jamais plus d'un flux à partir des fichiers .lzma ou des flux bruts, mais cette option permet toujours à xz d'ignorer les données parasites potentielles 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.
Depuis xz 5.7.1alpha, l'option --single-stream implique --keep.
--no-sparse
Désactive la création de fichiers éparses. Par défaut, lors de la décompression dans un fichier régulier, xz tente de créer un fichier éparse si les données décompressées contiennent de longues séquences de zéros binaires. Cela fonctionne également lors de l'écriture vers la sortie standard, à condition que la sortie standard soit connectée à un fichier régulier et que certaines conditions supplémentaires soient remplies pour que cela soit sûr. La création de fichiers éparses peut permettre de gagner de l'espace disque et d'accélérer la décompression en réduisant la quantité d'E/S disque.
-S .suf, --suffix=.suf
Lors de la compression, utilise .suf comme suffixe pour le fichier cible au lieu de .xz ou .lzma. Si l'on n'écrit pas vers la sortie standard et que le fichier source a déjà le suffixe .suf, un avertissement est affiché et le fichier est ignoré.
Lors de la décompression, reconnaît les fichiers avec le suffixe .suf en plus des fichiers avec les suffixes .xz, .txz, .lzma, .tlz ou .lz. Si le fichier source a le suffixe .suf, le suffixe est supprimé pour obtenir le nom de fichier cible.
Lors de la compression ou de la décompression de flux bruts (--format=raw), le suffixe doit toujours être spécifié, sauf si l'on écrit vers la sortie standard, car il n'y a pas de suffixe par défaut pour les flux bruts.
--files[=fichier]
Lire les noms de fichiers à traiter à partir du fichier ; si le fichier est omis, les noms de fichiers sont lus à partir de l'entrée standard. Les noms de fichiers doivent être terminés par un caractère de nouvelle ligne. Un tiret (-) est interprété comme un nom de fichier normal ; il ne signifie pas l'entrée standard. Si les noms de fichiers sont également spécifiés en tant qu'arguments de ligne de commande, ils sont traités avant les noms de fichiers lus à partir du fichier.
--files0[=fichier]
Ceci est identique à --files[=fichier], sauf que chaque nom de fichier doit être terminé par un caractère nul.
Options de base pour le format de fichier et la compression
-F format, --format=format
Spécifiez le format de fichier à compresser ou à décompresser :
auto C'est la valeur par défaut. Lors de la compression, auto est équivalent à xz. Lors de la décompression, le format du fichier d'entrée est détecté automatiquement. Notez que les flux bruts (créés avec --format=raw) ne peuvent pas être détectés automatiquement.
xz Compressez au format de fichier .xz, ou acceptez uniquement les fichiers .xz lors de la décompression.
lzma, seul
Compressez au format de fichier .lzma hérité, ou acceptez uniquement les fichiers .lzma lors de la décompression. Le nom alternatif seul est fourni pour la compatibilité avec LZMA Utils.
lzip Acceptez uniquement les fichiers .lz lors de la décompression. La compression n'est pas prise en charge.
Les versions 0 et 1 du format .lz sont prises en charge. Les fichiers de version 0 ont été produits par lzip 1.3 et les versions antérieures. Ces fichiers ne sont pas courants, mais peuvent être trouvés dans les archives de fichiers, car quelques paquets sources ont été publiés dans ce format. Certaines personnes peuvent également posséder d'anciens fichiers personnels dans ce format. La prise en charge de la décompression pour la version 0 du format a été supprimée dans lzip 1.18. lzip 1.4 et les versions ultérieures créent des fichiers dans la version 1 du format.
raw Compressez ou décompressez un flux brut (sans en-têtes). Ceci est destiné uniquement aux utilisateurs avancés. Pour décoder les flux bruts, vous devez utiliser --format=raw et spécifier explicitement la chaîne de filtres, qui serait normalement stockée dans les en-têtes du conteneur.
-C check, --check=check
Spécifiez le type de vérification d'intégrité. La vérification est calculée à partir des données non compressées et stockée dans le fichier .xz. Cette option n'a d'effet que lors de la compression au format .xz ; le format .lzma ne prend pas en charge les vérifications d'intégrité. La vérification d'intégrité (le cas échéant) est vérifiée lorsque le fichier .xz est décompressé.
Types de vérification pris en charge :
none Ne calculez aucune vérification d'intégrité. Ce n'est généralement pas une bonne idée. Cela peut être utile lorsque l'intégrité des données est vérifiée par d'autres moyens.
crc32 Calculez CRC32 en utilisant le polynôme de IEEE-802.3 (Ethernet).
crc64 Calculez CRC64 en utilisant le polynôme de ECMA-182. C'est la valeur par défaut, car elle est légèrement meilleure que CRC32 pour détecter les fichiers corrompus et la différence de vitesse est négligeable.
sha256 : Calcule le hachage SHA-256. Ceci est un 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 la modifier ou de la désactiver.
--ignore-check
Ne vérifiez pas l’intégrité des données compressées lors de la décompression. Les valeurs CRC32 dans les en-têtes .xz seront toujours vérifiées normalement.
N’utilisez cette option que si vous savez ce que vous faites. Les raisons possibles d’utiliser cette option sont les suivantes :
Essayer de récupérer des données à partir d’un fichier .xz corrompu.
Accélérer la décompression. Cela est important surtout avec SHA-256 ou avec les fichiers qui se sont extrêmement bien compressés. Il est recommandé de ne pas utiliser cette option à cette fin, à moins que l’intégrité du fichier ne soit vérifiée de manière externe par un autre moyen.
-0 ... -9
Sélectionnez un niveau de préréglage de compression. La valeur par défaut est -6. Si plusieurs niveaux de préréglage sont spécifiés, le dernier prend effet. Si une chaîne de filtres personnalisée a déjà été spécifiée, la définition d’un niveau de préréglage de compression efface la chaîne de filtres personnalisée.
Les différences entre les préréglages sont plus importantes qu’avec gzip(1) et bzip2(1). Les paramètres de compression sélectionnés déterminent les exigences de mémoire du décompresseur. L’utilisation d’un niveau de préréglage trop élevé peut rendre la décompression fastidieuse sur un ancien système avec peu de RAM. Plus précisément, il n’est pas bon d’utiliser aveuglément -9 pour tout, comme on le fait 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 beaucoup mieux. Les préréglages plus élevés ont souvent une vitesse comparable à bzip2(1) avec un taux de compression comparable ou meilleur, bien que les résultats dépendent beaucoup du type de données compressées.
-4 ... -6
Bonne à très bonne compression tout en maintenant une utilisation raisonnable de la mémoire du décompresseur, même pour les anciens systèmes. -6 est la valeur par défaut, ce qui est généralement un bon choix pour distribuer des fichiers qui doivent être décompressibles même sur les systèmes disposant de seulement 16 Mo de RAM. (-5e ou -6e peuvent également valoir la peine d’être considérés. Voir --extreme.)
-7 ... -9
Ce sont comme -6 mais avec des exigences de mémoire plus élevées pour le compresseur et le décompresseur. Ils ne sont utiles que lors de la compression de fichiers de plus de 8 Mo, 16 Mo et 32 Mo, respectivement.
Sur le même matériel, la vitesse de décompression est approximativement un nombre constant d’octets de données compressées par seconde. En d’autres termes, plus la compression est bonne, plus la décompression sera généralement rapide. Cela signifie également que la quantité de sortie décompressée produite par seconde peut varier considérablement.
Le tableau suivant résume les caractéristiques des préréglages :
Préréglage TailleDict CompCPU CompMem DecMem -0 256 Ko 0 3 Mo 1 Mo -1 1 Mo 1 9 Mo 2 Mo -2 2 Mo 2 17 Mo 3 Mo -3 4 Mo 3 32 Mo 5 Mo -4 4 Mo 4 48 Mo 5 Mo -5 8 Mo 5 94 Mo 9 Mo -6 8 Mo 6 94 Mo 9 Mo -7 16 Mo 6 186 Mo 17 Mo -8 32 Mo 6 370 Mo 33 Mo -9 64 Mo 6 674 Mo 65 Mo
Descriptions des colonnes :
DictSize est la taille du dictionnaire LZMA2. Il est inutile d’utiliser un dictionnaire plus grand que la taille du fichier non compressé, car cela gaspille de la mémoire. C’est pourquoi il est préférable d’éviter d’utiliser les paramètres prédéfinis -7 à -9 lorsqu’il n’y a pas de réel besoin. Pour les niveaux -6 et inférieurs, la quantité de mémoire gaspillée est généralement suffisamment faible pour ne pas poser de problème.
CompCPU est une représentation simplifiée des paramètres LZMA2 qui affectent la vitesse de compression. La taille du dictionnaire affecte également la vitesse, de sorte que même lorsque CompCPU est identique pour les niveaux -6 à -9, les niveaux supérieurs ont tendance à être légèrement plus lents. Pour obtenir une compression encore plus lente et donc potentiellement meilleure, voir --extreme.
CompMem contient les besoins en mémoire du compresseur en mode monothread. Cela peut varier légèrement entre les versions de xz.
DecMem contient les besoins en mémoire du décompresseur. Autrement dit, les paramètres de compression déterminent les besoins en mémoire du décompresseur. L’utilisation réelle de la mémoire du décompresseur est légèrement supérieure à la taille du dictionnaire LZMA2, mais les valeurs du tableau ont été arrondies au prochain MiB entier.
Les besoins en mémoire du mode multithread sont considérablement plus élevés que ceux du mode monothread. Avec la valeur par défaut de --block-size, chaque thread nécessite 3 * 3 * DictSize plus CompMem ou DecMem. Par exemple, quatre threads avec le paramètre prédéfini -6 nécessitent de 660 à 670 MiB de mémoire.
-e, --extreme
Utilise une variante plus lente du niveau de paramètre prédéfini de compression sélectionné (-0 à -9) dans l’espoir d’obtenir une compression légèrement meilleure, mais dans le pire des cas, cela peut également la rendre moins bonne. L’utilisation de la mémoire du décompresseur n’est pas affectée, mais l’utilisation de la mémoire du compresseur augmente légèrement aux niveaux de paramètre prédéfini -0 à -3.
Étant donné qu’il existe deux paramètres prédéfinis avec des tailles de dictionnaire de 4 MiB et 8 MiB, les paramètres prédéfinis -3e et -5e utilisent des paramètres légèrement plus rapides (CompCPU plus faible) que -4e et -6e, respectivement. De cette façon, aucun des paramètres prédéfinis n’est identique.
Paramètre prédéfini 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 existe un total de quatre paramètres prédéfinis qui utilisent un dictionnaire de 8 MiB, dont l’ordre, du plus rapide au plus lent, est -5, -6, -5e et -6e.
--fast
--best Il s’agit d’alias quelque peu trompeurs pour -0 et -9, respectivement. Ils sont fournis uniquement pour assurer la compatibilité avec LZMA Utils. Évitez d’utiliser ces options.
--block-size=size
Lors de la compression au format .xz, divise les données d’entrée en blocs de taille octets. Les blocs sont compressés indépendamment les uns des autres, ce qui facilite le multithreading et permet une décompression avec accès aléatoire limité. Cette option est généralement utilisée pour remplacer la taille de bloc par défaut en mode multithread, mais cette option peut également être utilisée en mode monothread.
En mode multithread, environ trois fois la taille en octets sera allouée dans chaque thread pour la mise en mémoire tampon des données d'entrée et de sortie. La taille par défaut est trois fois la taille du dictionnaire LZMA2 ou 1 Mo, la valeur la plus élevée étant retenue. Une bonne valeur est généralement de 2 à 4 fois la taille du dictionnaire LZMA2, ou au moins 1 Mo. L'utilisation d'une taille inférieure à la taille du dictionnaire LZMA2 est un gaspillage de mémoire, car le tampon du dictionnaire LZMA2 ne sera jamais entièrement utilisé. En mode multithread, les tailles des blocs sont stockées dans les en-têtes de bloc. Ces informations de taille sont nécessaires pour la décompression multithread.
En mode monothread, aucun découpage en blocs n'est effectué par défaut. La définition de cette option n'affecte pas l'utilisation de la mémoire. Aucune information de taille n'est stockée dans les en-têtes de bloc, de sorte que les fichiers créés en mode monothread ne seront pas identiques aux fichiers créés en mode multithread. Le manque d'informations de taille signifie également que xz ne pourra pas décompresser les fichiers en mode multithread.
--block-list=éléments
Lors de la compression au format .xz, commencez un nouveau bloc avec une chaîne de filtres personnalisée après les intervalles de données non compressées spécifiés.
Les éléments sont une liste séparée par des virgules. Chaque élément est constitué d'un numéro de chaîne de filtres facultatif compris entre 0 et 9, suivi de deux points (:) et de la taille obligatoire des données non compressées. L'omission d'un élément (deux virgules ou plus consécutives) est une forme abrégée pour utiliser la taille et les filtres de l'élément précédent.
Si le fichier d'entrée est plus grand que la somme des tailles dans les éléments, le dernier élément est répété jusqu'à la fin du fichier. Une valeur spéciale de 0 peut être utilisée comme dernière taille pour indiquer que le reste du fichier doit être encodé comme un seul bloc.
Une chaîne de filtres alternative pour chaque bloc peut être spécifiée en combinaison avec les options --filters1=filtres ... --filters9=filtres. Ces options définissent des chaînes de filtres avec un identifiant compris entre 1 et 9. La chaîne de filtres 0 peut être utilisée pour faire référence à la chaîne de filtres par défaut, ce qui équivaut à ne pas spécifier de chaîne de filtres. L'identifiant de la chaîne de filtres peut être utilisé avant la taille non compressée, suivi de deux points (:). Par exemple, si l'on spécifie --block-list=1:2MiB,3:2MiB,2:4MiB,,2MiB,0:4MiB, alors des blocs seront créés en utilisant :
La chaîne de filtres spécifiée par --filters1 et 2 MiB d'entrée
La chaîne de filtres spécifiée par --filters3 et 2 MiB d'entrée
La chaîne de filtres spécifiée par --filters2 et 4 MiB d'entrée
La chaîne de filtres spécifiée par --filters2 et 4 MiB d'entrée
La chaîne de filtres par défaut et 2 MiB d'entrée
La chaîne de filtres par défaut et 4 MiB d'entrée pour chaque bloc jusqu'à la fin de l'entrée.
Si l'on spécifie une taille qui dépasse la taille de bloc de l'encodeur (soit la valeur par défaut en mode threadé, soit la valeur spécifiée avec --block-size=size), l'encodeur créera des blocs supplémentaires tout en conservant les limites spécifiées dans les éléments. Par exemple, si l'on spécifie --block-size=10MiB --block-list=5MiB,10MiB,8MiB,12MiB,24MiB et que le fichier d'entrée est de 80 MiB, on obtiendra 11 blocs : 5, 10, 8, 10, 2, 10, 10, 4, 10, 10 et 1 MiB.
En mode multi-thread, les tailles des blocs sont stockées dans les en-têtes de bloc. Ceci n'est pas fait en mode mono-thread, donc la sortie encodée ne sera pas identique à celle du mode multi-thread.
--flush-timeout=timeout
Lors de la compression, si plus de `timeout` millisecondes se sont écoulées depuis la dernière vidange et que la lecture de nouvelles données bloquerait, toutes les données en attente sont vidangées de l'encodeur et mises à disposition dans le flux de sortie. Cela peut être utile si xz est utilisé pour compresser des données diffusées sur un réseau. De petites valeurs de `timeout` rendent les données disponibles à l'extrémité réceptrice avec un faible délai, mais de grandes valeurs de `timeout` offrent un meilleur taux de compression.
Cette fonctionnalité est désactivée par défaut. Si cette option est spécifiée plus d'une fois, la dernière est prise en compte. La valeur spéciale de `timeout` de 0 peut être utilisée pour désactiver explicitement cette fonctionnalité.
Cette fonctionnalité n'est pas disponible sur les systèmes non POSIX.
Cette fonctionnalité est encore expérimentale. Actuellement, xz ne convient pas pour décompresser le flux en temps réel en raison de la manière dont xz effectue la mise en mémoire tampon.
--no-sync
Ne synchronisez pas le fichier cible et son répertoire avec le périphérique de stockage avant de supprimer le fichier source. Cela peut améliorer les performances lors de la compression ou de la décompression de nombreux petits fichiers. Cependant, si le système plante peu de temps après la suppression, il est possible que le fichier cible n'ait pas été écrit sur le périphérique de stockage, mais que l'opération de suppression ait été effectuée. Dans ce cas, ni le fichier source original ni le fichier cible ne sont disponibles.
Cette option n'a d'effet que lorsque xz va supprimer le fichier source. Dans les autres cas, la synchronisation n'est jamais effectuée.
La synchronisation et --no-sync ont été ajoutées dans xz 5.7.1alpha.
--memlimit-compress=limit
Définir une limite d'utilisation de la mémoire pour la compression. Si cette option est spécifiée plusieurs fois, la dernière est prise en compte.
Si les paramètres de compression dépassent la limite, xz tentera de les ajuster à la baisse afin que la limite ne soit plus dépassée et affichera un message indiquant qu'un ajustement automatique a été effectué. Les ajustements sont effectués dans l'ordre suivant : réduction du nombre de threads, passage en mode mono-thread si même un seul thread en mode multi-thread dépasse la limite, et enfin réduction de la taille du dictionnaire LZMA2.
Lors de la compression avec --format=raw ou si --no-adjust a été spécifié, seul le nombre de threads peut être réduit car cela peut être fait sans affecter la sortie compressée.
Si la limite ne peut être respectée même avec les ajustements décrits ci-dessus, un message d'erreur est affiché et xz se termine avec un code de sortie de 1.
La limite peut être spécifiée de plusieurs manières :
La limite peut être une valeur absolue en octets. L’utilisation d’un suffixe entier tel que MiB peut être utile. Exemple : --memlimit-compress=80MiB
La limite peut être spécifiée en pourcentage de la mémoire physique totale (RAM). Cela peut être utile, en particulier lors de la définition de la variable d’environnement XZ_DEFAULTS dans un script d’initialisation de shell partagé entre différents ordinateurs. De cette façon, la limite est automatiquement plus grande sur les systèmes dotés de plus de mémoire. Exemple: --memlimit-compress=70%
La limite peut être réinitialisée à sa valeur par défaut en la définissant à 0. Cela équivaut actuellement à définir la limite à une valeur maximale (pas de limite d’utilisation de la mémoire).
Pour xz 32 bits, il existe un cas particulier : si la limite dépasserait 4 020 MiB, la limite est définie à 4 020 MiB. Sur MIPS32, 2 000 MiB sont utilisés à la place. (Les valeurs 0 et max ne sont pas affectées par cela. Une fonctionnalité similaire n’existe pas pour la décompression.) Cela peut être utile lorsqu’un exécutable 32 bits a accès à un espace d’adressage de 4 Go (2 Go sur MIPS32) tout en évitant, on l’espère, de causer des problèmes dans d’autres situations.
Voir également la section Utilisation de la mémoire.
--memlimit-decompress=limite
Définit une limite d’utilisation de la mémoire pour la décompression. Cela affecte également le mode --list. Si l’opération n’est pas possible sans dépasser la limite, xz affichera une erreur et la décompression du fichier échouera. Voir --memlimit-compress=limite pour les façons possibles de spécifier la limite.
--memlimit-mt-decompress=limite
Définit une limite d’utilisation de la mémoire pour la décompression multithread. Cela ne peut affecter que le nombre de threads ; cela n’empêchera jamais xz de décompresser un fichier. Si la limite est trop basse pour permettre un multithreading, la limite est ignorée et xz continuera en mode monothread. Notez que si --memlimit-decompress est également utilisé, il s’appliquera toujours aux modes monothread et multithread, de sorte que la limite effective pour le multithreading ne sera jamais supérieure à la limite définie avec --memlimit-decompress.
Contrairement aux autres options de limite d’utilisation de la mémoire, --memlimit-mt-decompress=limite a une limite par défaut spécifique au système. La commande xz --info-memory peut être utilisée pour afficher la valeur actuelle.
Cette option et sa valeur par défaut existent parce que, sans aucune limite, le décompresseur multithread pourrait allouer une quantité de mémoire démesurée avec certains fichiers en entrée. Si la limite par défaut est trop basse sur votre système, n’hésitez pas à augmenter la limite, mais ne la définissez jamais à une valeur supérieure à la quantité de RAM utilisable, car avec des fichiers d’entrée appropriés, xz tentera d’utiliser cette quantité de mémoire, même avec un faible nombre de threads. Le manque de mémoire ou l’utilisation de la mémoire virtuelle n’amélioreront pas les performances de la décompression.
Voir --memlimit-compress=limite pour les façons possibles de spécifier la limite. Définir la limite à 0 réinitialise la limite à la valeur par défaut spécifique au système.
-M limite, --memlimit=limite, --memory=limite Ceci est équivalent à spécifier --memlimit-compress=limite --memlimit-decompress=limite --memlimit-mt-decompress=limite.
--no-adjust
Affiche une erreur et quitte si la limite d'utilisation de la mémoire ne peut pas être respectée sans ajuster les paramètres qui affectent la sortie compressée. Cela empêche xz de passer du mode encodeur multithread au mode monothread et de réduire la taille du dictionnaire LZMA2. Même lorsque cette option est utilisée, le nombre de threads peut être réduit pour respecter la limite d'utilisation de la mémoire, car cela n'affectera pas la sortie compressée.
L'ajustement automatique est toujours désactivé lors de la création de flux bruts (--format=raw).
-T threads, --threads=threads
Spécifie le nombre de threads de travail à utiliser. Définir threads sur une valeur spéciale de 0 fait que xz utilise jusqu'à autant de threads que les processeurs du système le permettent. Le nombre réel de threads peut être inférieur à threads si le fichier d'entrée n'est pas assez grand pour le threading avec les paramètres donnés ou si l'utilisation de plus de threads dépasserait la limite d'utilisation de la mémoire.
Le compresseur monothread et le compresseur multithread produisent des sorties différentes. Le compresseur monothread donnera la plus petite taille de fichier, mais seule la sortie du compresseur multithread peut être décompressée en utilisant plusieurs threads. Définir threads sur 1 utilisera le mode monothread. Définir threads sur toute autre valeur, y compris 0, utilisera le compresseur multithread, même si le système ne prend en charge qu'un seul thread matériel. (xz 2.x utilisait le mode monothread dans cette situation.)
Pour utiliser le mode multithread avec un seul thread, définissez threads sur +1. Le préfixe + n'a aucun effet avec les autres valeurs. Une limite d'utilisation de la mémoire peut toujours amener xz à passer au mode monothread, à moins que --no-adjust ne soit utilisé. La prise en charge du préfixe + a été ajoutée dans xz 5.4.0.
Si un nombre de threads automatique a été demandé et qu'aucune limite d'utilisation de la mémoire n'a été spécifiée, alors une limite douce spécifique au système sera utilisée pour limiter éventuellement le nombre de threads. Il s'agit d'une limite douce dans le sens où elle est ignorée si le nombre de threads devient un, de sorte qu'une limite douce n'empêchera jamais xz de compresser ou de décompresser. Cette limite douce par défaut ne fera pas passer xz du mode multithread au mode monothread. Les limites actives peuvent être visualisées avec xz --info-memory.
Actuellement, la seule méthode de threading consiste à diviser l'entrée en blocs et à les compresser indépendamment les uns des autres. La taille de bloc par défaut dépend du niveau de compression et peut être remplacée par l'option --block-size=size.
La décompression multithread ne fonctionne que sur les fichiers qui contiennent plusieurs blocs avec des informations de taille dans les en-têtes de bloc. Tous les fichiers suffisamment volumineux compressés en mode multithread satisfont à cette condition, mais les fichiers compressés en mode monothread ne le font pas, même si --block-size=size a été utilisé.
La valeur par défaut pour threads est 0. Dans xz 5.4.x et les versions antérieures, la valeur par défaut est 1.
Chaînes de filtres de compresseur personnalisées
Une chaîne de filtres personnalisée permet de spécifier les paramètres de compression en détail au lieu de s'appuyer sur les paramètres associés aux préréglages. Lorsqu'une chaîne de filtres personnalisée est spécifiée, les options de préréglage (-0 ... -9 et --extreme) qui apparaissent plus tôt sur la ligne de commande sont oubliées. Si une option de préréglage est spécifiée après une ou plusieurs options de chaîne de filtres personnalisées, le nouveau préréglage prend effet et les options de chaîne de filtres personnalisées spécifiées précédemment sont oubliées.
Une chaîne de filtres est comparable au « piping » en ligne de commande. Lors de la compression, l’entrée non compressée est transmise au premier filtre, dont la sortie est transmise au filtre suivant (le cas échéant). La sortie du dernier filtre est écrite dans le fichier compressé. Le nombre maximal de filtres dans la chaîne est de quatre, mais une chaîne de filtres ne contient généralement qu’un ou deux filtres.
De nombreux filtres ont des limitations sur leur position dans la chaîne de filtres : certains filtres ne peuvent fonctionner qu’en tant que dernier filtre de la chaîne, certains que comme filtre autre que le dernier, et certains peuvent fonctionner à n’importe quelle position dans la chaîne. Selon le filtre, cette limitation est soit inhérente à la conception du filtre, soit elle existe pour éviter des problèmes de sécurité.
Une chaîne de filtres personnalisée peut être spécifiée de deux manières différentes. Les options `--filters=filters` et `--filters1=filters ... --filters9=filters` permettent de spécifier une chaîne de filtres entière dans une seule option en utilisant la syntaxe de chaîne de filtres liblzma. Alternativement, une chaîne de filtres peut être spécifiée en utilisant une ou plusieurs options de filtre individuelles dans l’ordre souhaité dans la chaîne de filtres. Ainsi, l’ordre des options de filtre individuelles est important ! Lors du décodage de flux bruts (`--format=raw`), la chaîne de filtres doit être spécifiée dans le même ordre que lors de la compression. Toutes les options de filtre ou de préréglage individuelles spécifiées avant l’option de chaîne complète (`--filters=filters`) seront ignorées. Les filtres individuels spécifiés après l’option de chaîne complète réinitialiseront la chaîne de filtres.
Tant l’option de chaîne complète que les options de filtre individuelles 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. Chaque option a une valeur par défaut, il est donc préférable de spécifier uniquement celles que vous souhaitez modifier.
Pour voir la chaîne de filtres et les options, utilisez `xz -vv` (c’est-à-dire, utilisez `--verbose` deux fois). Cela fonctionne également pour afficher les options de la chaîne de filtres utilisées par les préréglages.
`--filters=filters`
Spécifie la chaîne de filtres complète ou un préréglage dans une seule option. Chaque filtre peut être séparé par des espaces ou par deux tirets (`--`). Il peut être nécessaire de mettre `filters` entre guillemets dans la ligne de commande du shell afin qu’il soit analysé comme une seule option. Pour indiquer les options, utilisez `:` ou `=`. Un préréglage peut être préfixé par `-` suivi de zéro ou plusieurs indicateurs. Le seul indicateur pris en charge est `e` pour appliquer les mêmes options que `--extreme`.
`--filters1=filters ... --filters9=filters`
Spécifie jusqu’à neuf chaînes de filtres supplémentaires qui peuvent être utilisées avec `--block-list`.
Par exemple, lors de la compression d’une archive contenant des fichiers exécutables suivis de fichiers texte, la partie exécutable pourrait utiliser une chaîne de filtres avec un filtre BCJ et la partie texte uniquement le filtre LZMA2.
--filters-help
Affiche un message d'aide décrivant comment spécifier les préréglages et les chaînes de filtres personnalisées dans les options --filters et --filters1=filters ... --filters9=filters, et se termine avec succès.
--lzma1[=options]
--lzma2[=options]
Ajoute un filtre LZMA1 ou LZMA2 à la chaîne de filtres. Ces filtres ne peuvent être utilisés qu'en dernier filtre de la chaîne.
LZMA1 est un filtre hérité, qui est pris en charge presque uniquement en raison du format de fichier .lzma hérité, qui ne prend en charge que LZMA1. LZMA2 est une version mise à jour de LZMA1 pour corriger certains problèmes pratiques de LZMA1. Le format .xz utilise LZMA2 et ne prend pas en charge LZMA1. Les vitesses et les taux de compression de LZMA1 et LZMA2 sont pratiquement les mêmes.
LZMA1 et LZMA2 partagent le même ensemble d'options :
preset=preset
Réinitialise toutes les options LZMA1 ou LZMA2 au préréglage. Le préréglage consiste en un entier, suivi éventuellement d'un modificateur de préréglage à une seule lettre. L'entier peut aller de 0 à 9, correspondant aux options de ligne de commande -0 ... -9. Le seul modificateur pris en charge est actuellement e, qui correspond à --extreme. Si aucun préréglage n'est spécifié, les valeurs par défaut des options LZMA1 ou LZMA2 sont extraites du préréglage 6.
dict=size
La taille du dictionnaire (tampon d'historique) indique combien d'octets des données non compressées traitées récemment sont conservés en mémoire. L'algorithme tente de trouver des séquences d'octets répétitives (correspondances) dans les données non compressées et de les remplacer par des références aux données actuellement dans le dictionnaire. Plus le dictionnaire est grand, plus il est probable de trouver une correspondance. Par conséquent, l'augmentation de la taille du dictionnaire améliore généralement le taux de compression, mais un dictionnaire plus grand que le fichier non compressé est un gaspillage de mémoire.
La taille typique du dictionnaire se situe entre 64 Ko et 64 Mo. Le minimum est de 4 Ko. Le maximum pour la compression est actuellement de 1,5 Go (1 536 Mo). Le décompresseur prend déjà en charge les dictionnaires jusqu'à un octet de moins que 4 Go, ce qui est la taille maximale pour les formats de flux LZMA1 et LZMA2.
La taille du dictionnaire et le moteur de recherche de correspondances (mf) déterminent ensemble l'utilisation de la mémoire de l'encodeur LZMA1 ou LZMA2. La même taille de dictionnaire (ou plus grande) est requise pour la décompression que celle utilisée lors de la compression, l'utilisation de la mémoire du décodeur est donc déterminée par la taille du dictionnaire utilisée lors de la compression. Les en-têtes .xz stockent la taille du dictionnaire soit sous la forme 2^n, soit sous la forme 2^n + 2^(n-1), ces tailles sont donc quelque peu préférables pour la compression. Les autres tailles seront arrondies lors de leur stockage dans les en-têtes .xz.
lc=lc Spécifie le nombre de bits de contexte littéral. Le minimum est de 0 et le maximum est de 4 ; la valeur par défaut est de 3. De plus, la somme de lc et lp ne doit pas dépasser 4.
Tous les octets qui ne peuvent pas être codés sous forme de correspondances sont codés sous forme de littéraux. Autrement dit, les littéraux sont simplement des octets de 8 bits qui sont codés un par un.
Le codage littéral suppose que les lc bits les plus significatifs de l'octet non compressé précédent sont liés au prochain octet. 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 significatifs sont 010 pour les lettres majuscules et 011 pour les lettres minuscules. Lorsque lc est d'au moins 3, le codage littéral peut tirer parti de cette propriété dans les données non compressées.
La valeur par défaut (3) est généralement bonne. Si vous souhaitez une compression maximale, testez lc=4. Parfois, cela améliore légèrement la compression, et parfois, cela la détériore. Si cela la détériore, testez également lc=2.
lp=lp Spécifiez le nombre de bits de position des littéraux. Le minimum est 0 et le maximum est 4 ; la valeur par défaut est 0.
Lp affecte le type d’alignement supposé dans les données décompressées lors de l’encodage des littéraux. Voir pb ci-dessous pour plus d’informations sur l’alignement.
pb=pb Spécifiez le nombre de bits de position. Le minimum est 0 et le maximum est 4 ; la valeur par défaut est 2.
Pb affecte le type d’alignement supposé dans les données décompressées en général. La valeur par défaut signifie un alignement de quatre octets (2^pb = 2^2 = 4), ce qui est souvent un bon choix lorsqu’il n’y a pas de meilleure hypothèse.
Lorsque l’alignement est connu, définir pb en conséquence peut légèrement réduire la taille du fichier. Par exemple, pour les fichiers texte ayant un alignement d’un octet (US-ASCII, ISO-8859-*, UTF-8), définir pb=0 peut améliorer légèrement la compression. Pour le texte 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 supposé peut être ajusté avec pb et lp, LZMA1 et LZMA2 favorisent toujours légèrement un alignement de 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.
mf=mf Le détecteur de correspondances a un effet important sur la vitesse de l’encodeur, l’utilisation de la mémoire et le taux de compression. Généralement, les détecteurs de correspondances de type chaîne de hachage sont plus rapides que les détecteurs de correspondances de type arbre binaire.
La valeur par défaut dépend du préréglage : 0 utilise hc3, 1 à 3 utilisent hc4, et les autres utilisent bt4.
Les détecteurs de correspondances suivants sont pris en charge. Les formules d’utilisation de la mémoire ci-dessous sont des approximations approximatives, qui se rapprochent le plus de la réalité lorsque dict est une puissance de deux.
hc3 Chaîne de hachage avec hachage de 2 et 3 octets
Valeur minimale pour nice : 3 Utilisation de la mémoire : dict * 7,5 (si dict <= 16 Mo) ; dict * 5,5 + 64 Mo (si dict > 16 Mo)
hc4 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 Mo) ; dict * 6,5 (si dict > 32 Mo)
bt2 Arbre binaire avec hachage de 2 octets
Valeur minimale pour nice : 2 Utilisation de la mémoire : dict * 9,5
bt3 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 Mo) ; dict * 9,5 + 64 Mo (si dict > 16 Mo)
bt4 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 Mo) ; dict * 10,5 (si dict > 32 Mo)
mode=mode
Le mode de compression spécifie la méthode à utiliser pour analyser les données produites par le moteur de recherche de correspondances. Les modes pris en charge sont rapide et normal. La valeur par défaut est rapide pour les préréglages 0 à 3 et normal pour les préréglages 4 à 9.
En général, le mode rapide est utilisé avec les moteurs de recherche de correspondances de type Chaîne de hachage et le mode normal avec les moteurs de recherche de type Arbre binaire. C'est également ce que font les préréglages.
nice=nice
Spécifie la longueur minimale considérée comme acceptable pour une correspondance. Une fois qu'une correspondance d'au moins « nice » octets est trouvée, l'algorithme cesse de rechercher d'éventuelles meilleures correspondances.
La valeur de « nice » peut être comprise entre 2 et 273 octets. Des valeurs plus élevées ont tendance à donner un meilleur taux de compression au prix de la vitesse. La valeur par défaut dépend du préréglage.
depth=depth
Spécifie la profondeur de recherche maximale dans le moteur de recherche de correspondances. La valeur par défaut est la valeur spéciale 0, ce qui permet au compresseur de déterminer une profondeur raisonnable à partir de « mf » et « nice ».
Une profondeur raisonnable pour les chaînes de hachage est de 4 à 100 et de 16 à 1000 pour les arbres binaires. L'utilisation de valeurs très élevées pour la profondeur peut rendre l'encodeur extrêmement lent avec certains fichiers. Évitez de définir la profondeur à plus de 1000, à moins que vous ne soyez prêt à interrompre la compression si elle prend trop de temps.
Lors du décodage de flux bruts (--format=raw), LZMA2 n'a besoin que de la taille du dictionnaire. LZMA1 a également besoin de lc, lp et pb.
--x86[=options]
--arm[=options]
--armthumb[=options]
--arm64[=options]
--powerpc[=options]
--ia64[=options]
--sparc[=options]
--riscv[=options]
Ajoute un filtre de branche/appel/saut (BCJ) à la chaîne de filtres. Ces filtres ne peuvent être utilisés qu'en tant que filtre non final dans la chaîne de filtres.
Un filtre BCJ convertit les adresses relatives du code machine en leurs équivalents absolus. Cela ne modifie pas la taille des données, mais cela augmente la redondance, ce qui peut aider LZMA2 à produire des fichiers .xz 0 à 15 % plus petits. Les filtres BCJ sont toujours réversibles, donc l'utilisation d'un filtre BCJ pour un type de données incorrect n'entraîne aucune perte de données, bien qu'elle puisse légèrement dégrader le taux de compression. Les filtres BCJ sont très rapides et utilisent une quantité insignifiante de mémoire.
Ces filtres BCJ présentent des problèmes connus liés au taux de compression :
Certains types de fichiers contenant du code exécutable (par exemple, les fichiers objets, les bibliothèques statiques et les modules du noyau Linux) ont les adresses dans les instructions remplies de valeurs de remplissage. Ces filtres BCJ effectueront tout de même la conversion d'adresse, ce qui dégradera la compression avec ces fichiers.
Si un filtre BCJ est appliqué à une archive, il est possible qu'il dégrade le taux de compression par rapport à l'absence d'un filtre BCJ. Par exemple, s'il existe des exécutables similaires ou identiques, le filtrage aura probablement pour effet de rendre les fichiers moins similaires, ce qui dégradera la compression. Le contenu des fichiers non exécutables dans la même archive peut également avoir de l'importance. En pratique, il faut essayer avec et sans un filtre BCJ pour voir lequel est le meilleur dans chaque situation.
Différents jeux d'instructions ont un alignement différent : le fichier exécutable doit être aligné sur un multiple de cette valeur dans les données d'entrée pour que le filtre fonctionne.
Filtre
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).
Taux de compression, qui est calculé en divisant la quantité de données compressées traitées jusqu'à présent par la quantité de données non compressées traitées jusqu'à présent.
Vitesse de compression ou de décompression. Ceci est mesuré comme la quantité de données non compressées consommées (compression) ou produites (décompression) par seconde. Ceci est affiché après que quelques secondes se sont écoulées depuis le début du traitement du fichier par xz.
Temps écoulé au format M:SS ou H:MM:SS.
Le temps restant estimé est affiché uniquement lorsque la taille du fichier d'entrée est connue et que quelques secondes se sont déjà écoulées depuis le début du traitement du fichier par xz. Le temps est affiché dans un format moins précis qui n'a jamais de deux-points, par exemple, 2 min 30 s.
Lorsque la sortie d'erreur standard n'est pas un terminal, l'option --verbose fait que xz affiche le nom du fichier, la taille compressée, la taille non compressée, le taux de compression et éventuellement également la vitesse et le temps écoulé sur une seule ligne vers la sortie d'erreur standard après avoir compressé ou décompressé le fichier. La vitesse et le temps écoulé sont inclus uniquement lorsque l'opération a pris au moins quelques secondes. Si l'opération n'est pas terminée, par exemple en raison d'une interruption de l'utilisateur, le pourcentage d'achèvement est également affiché si la taille du fichier d'entrée est connue.
-Q, --no-warn
Ne pas définir le code de sortie sur 2 même si une condition justifiant un avertissement a été détectée. Cette option n'affecte pas le niveau de verbosité, ainsi les options --quiet et --no-warn doivent être utilisées pour ne pas afficher les avertissements et pour ne pas modifier le code de sortie.
--robot
Afficher les messages dans un format facile à analyser par une machine. Ceci est destiné à faciliter l'écriture d'interfaces qui souhaitent utiliser xz au lieu de liblzma, ce qui peut être le cas pour divers scripts. La sortie avec cette option activée est destinée à être stable entre les versions de xz. Voir la section MODE ROBOT pour plus de détails.
--info-memory
Afficher, dans un format lisible par l'homme, la quantité de mémoire physique (RAM) et le nombre de threads de processeur que xz pense que le système possède, ainsi que les limites d'utilisation de la mémoire pour la compression et la décompression, et quitter avec succès.
-h, --help
Afficher un message d'aide décrivant les options les plus couramment utilisées, et quitter avec succès.
-H, --long-help
Afficher un message d'aide décrivant toutes les fonctionnalités de xz, et quitter avec succès
-V, --version
Afficher le numéro de version de xz et de liblzma dans un format lisible par l'homme. Pour obtenir une sortie analysable par une machine, spécifiez --robot avant --version.
MODE ROBOT
Le mode robot est activé avec l'option --robot. Cela facilite l'analyse de la sortie de xz par d'autres programmes. Actuellement, --robot est pris en charge uniquement avec --list, --filters-help, --info-memory et --version. Il sera pris en charge pour la compression et la décompression à l'avenir.
Mode Liste
xz --robot --list utilise une sortie séparée par des tabulations. La première colonne de chaque ligne contient une chaîne qui indique le type d'information trouvé sur cette ligne :
name Il s'agit toujours de la première ligne lorsque vous commencez à lister un fichier. La deuxième colonne de la ligne
est le nom du fichier.
file Cette ligne contient des informations générales sur le fichier .xz. Cette ligne est toujours affichée
après la ligne name.
stream Ce type de ligne est utilisé uniquement lorsque l'option --verbose est spécifiée. Il existe autant de lignes stream
que de streams dans le fichier .xz.
block Ce type de ligne est utilisé uniquement lorsque l'option --verbose est spécifiée deux fois. Il existe autant de lignes block
que de blocks dans le fichier .xz. Les lignes block sont affichées après toutes les lignes stream ; différents types de lignes ne sont pas entrelacés.
summary
Ce type de ligne est utilisé uniquement lorsque l'option --verbose est spécifiée deux fois. Cette ligne est affichée après toutes les lignes block. Comme la ligne file, la ligne summary contient des informations générales sur le fichier .xz.
totals Cette ligne est toujours la dernière ligne de la sortie de la liste. Elle affiche les décomptes et
les tailles totaux.
Les colonnes des lignes file : ### Nombre de streams dans le fichier ### Nombre total de blocks dans les streams ### Taille compressée du fichier ### Taille non compressée du fichier ### Rapport de compression, par exemple, 0.123. Si le rapport est supérieur à 9.999, trois tirets (---) sont affichés à la place du rapport. ### Liste de noms de contrôle d'intégrité séparés par des virgules. Les chaînes suivantes sont utilisées pour les types de contrôle connus : None, CRC32, CRC64 et SHA-256. Pour les types de contrôle inconnus, Unknown-N est utilisé, où N est l'ID de contrôle sous forme décimale (un ou deux chiffres). ### Taille totale du remplissage de stream dans le fichier
Les colonnes des lignes stream : ### Numéro de stream (le premier stream est 1) ### Nombre de blocks dans le stream ### Décalage de début compressé ### Décalage de début non compressé ### Taille compressée (ne comprend pas le remplissage de stream) ### Taille non compressée ### Rapport de compression ### Nom du contrôle d'intégrité Taille du remplissage de stream
Les colonnes des lignes block : ### Numéro du stream contenant ce block ### Numéro de block par rapport au début du stream (le premier block est 1) ### Numéro de block par rapport au début du fichier ### Décalage de début compressé par rapport au début du fichier ### Décalage de début non compressé par rapport au début du fichier ### Taille compressée totale du block (inclut les en-têtes) ### Taille non compressée ### Rapport de compression Nom du contrôle d'intégrité
Si l'option --verbose a été spécifiée deux fois, des colonnes supplémentaires sont incluses dans les lignes block. Celles-ci ne sont pas affichées avec un seul --verbose, car l'obtention de ces informations nécessite de nombreux accès aléatoires et peut donc être lente : Valeur du contrôle d'intégrité en hexadécimal Taille de l'en-tête de block Indicateurs de block : c indique que la taille compressée est présente, et u indique que la taille non compressée est présente. Si l'indicateur n'est pas défini, un tiret (-) est affiché pour maintenir la longueur de la chaîne. De nouveaux indicateurs peuvent être ajoutés à la fin de la chaîne à l'avenir. Taille réelle des données compressées dans le block (cela exclut l'en-tête de block, le remplissage de block et les champs de contrôle) Quantité de mémoire (en octets) nécessaire pour décompresser ce block avec cette version de xz Chaîne de filtres. Notez que la plupart des options utilisées au moment de la compression ne peuvent pas être connues, car seules les options nécessaires à la décompression sont stockées dans les en-têtes .xz.
Les colonnes des lignes de résumé : ### Quantité de mémoire (en octets) requise pour décompresser ce fichier avec cette version de xz Oui ou non indiquant si tous les en-têtes de blocs contiennent à la fois la taille compressée et la taille décompressée. Depuis xz 5.1.2alpha : ### Version minimale de xz requise pour décompresser le fichier
Les colonnes de la ligne des totaux : ### Nombre de flux ### Nombre de blocs ### Taille compressée ### Taille décompressée ### Ratio de compression moyen ### Liste des noms des contrôles d’intégrité présents dans les fichiers, séparés par des virgules ### Taille du remplissage de flux ### Nombre de fichiers. Ceci est présent pour maintenir l’ordre des colonnes précédentes comme dans les lignes de fichier.
Si l’option --verbose a été spécifiée deux fois, des colonnes supplémentaires sont incluses dans la ligne des totaux : Quantité maximale de mémoire (en octets) requise pour décompresser les fichiers avec cette version de xz Oui ou non indiquant si tous les en-têtes de blocs contiennent à la fois la taille compressée et la taille décompressée. Depuis xz 5.1.2alpha : Version minimale de xz requise pour décompresser le fichier
Les versions futures peuvent ajouter de nouveaux types de lignes et de nouvelles colonnes peuvent être ajoutées aux types de lignes existants, mais les colonnes existantes ne seront pas modifiées.
### Informations sur les filtres
xz --robot --filters-help affiche les filtres pris en charge dans le format suivant :
filter:option=<value>,option=<value>...
filter Nom du filtre
option Nom d’une option spécifique au filtre
value Les valeurs numériques apparaissent sous la forme <min-max>. Les choix de valeurs de chaîne sont affichés entre < > et séparés par un caractère |.
Chaque filtre est affiché sur sa propre ligne.
### Informations sur la limite de mémoire
xz --robot --info-memory affiche une seule ligne avec plusieurs colonnes séparées par des tabulations :
### Quantité totale de mémoire physique (RAM) en octets.
### Limite d’utilisation de la mémoire pour la compression en octets (--memlimit-compress). Une valeur spéciale de 0 indique le paramètre par défaut, qui, pour le mode monothread, est le même que l’absence de limite.
### Limite d’utilisation de la mémoire pour la décompression en octets (--memlimit-decompress). Une valeur spéciale de 0 indique le paramètre par défaut, qui, pour le mode monothread, est le même que l’absence de limite.
### Depuis xz 5.3.4alpha : Utilisation de la mémoire pour la décompression multithread en octets (--memlimit-mt-decompress). Cette valeur n’est jamais nulle, car une valeur par défaut spécifique au système affichée dans la colonne 5 est utilisée si aucune limite n’a été spécifiée explicitement. Cette valeur n’est jamais supérieure à la valeur de la colonne 3, même si une valeur plus grande a été spécifiée avec --memlimit-mt-decompress.
Depuis xz 5.3.4alpha : une limite d’utilisation de la mémoire spécifique au système qui est utilisée pour limiter le nombre de threads lors de la compression avec un nombre de threads automatique (--threads=0) et qu’aucune limite d’utilisation de la mémoire n’a été spécifiée (--memlimit-compress). Ceci est également utilisé comme valeur par défaut pour --memlimit-mt-decompress.
Depuis xz 5.3.4alpha : nombre de threads de processeur disponibles.
Dans le futur, la sortie de xz --robot --info-memory peut avoir plus de colonnes, mais jamais plus d’une seule ligne.
Version
xz --robot --version affiche le numéro de version de xz et de liblzma dans le format suivant :
XZ_VERSION=XYYYZZZS
LIBLZMA_VERSION=XYYYZZZS
X Version principale.
YYY Version mineure. Les nombres pairs sont stables. Les nombres impairs sont des versions alpha ou bêta.
ZZZ Niveau de correctif pour les versions stables ou un simple compteur pour les versions de développement.
S Stabilité. 0 est alpha, 1 est bêta et 2 est stable. S doit toujours être 2 lorsque YYY est pair.
XYYYZZZS sont les mêmes sur les deux lignes si xz et liblzma proviennent de la même version de XZ Utils.
Exemples : 4.999.9beta est 49990091 et 5.0.0 est 50000002.
STATUT DE SORTIE
0 Tout est bon.
1 Une erreur s’est produite.
2 Quelque chose qui mérite un avertissement s’est produit, mais aucune erreur réelle ne s’est produite.
Les notifications (pas les avertissements ou les erreurs) affichées sur la sortie standard n’affectent pas le statut de sortie.
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 à partir de la ligne de commande. Notez que seules les options sont analysées à partir des variables d’environnement ; toutes les valeurs non-options sont ignorées silencieusement. L’analyse est effectuée avec getopt_long(3), qui est également utilisé pour les arguments de la ligne de commande.
Attention : en définissant ces variables d’environnement, on modifie en fait les programmes et les scripts qui exécutent xz. Dans la plupart des cas, il est sûr de définir les limites d’utilisation de la mémoire, le nombre de threads et les options de compression via les variables d’environnement. Cependant, certaines options peuvent casser des scripts. Un exemple évident est --help, qui fait que xz affiche le texte d’aide au lieu de compresser ou de décompresser un fichier. Des exemples plus subtils sont --quiet et --verbose. Dans de nombreux cas, il est utile d’activer l’indicateur de progression en utilisant --verbose, mais dans certaines situations, les messages supplémentaires créent des problèmes. Le niveau de verbosité affecte également le comportement de --list.
XZ_DEFAULTS
Options par défaut spécifiques à l’utilisateur ou à l’échelle du système. En général, cela est défini dans un script d’initialisation du shell pour activer le limiteur d’utilisation de la mémoire de xz par défaut ou définir le nombre de threads par défaut. À l’exclusion des scripts d’initialisation du shell et de cas spéciaux similaires, les scripts ne doivent jamais définir ou annuler la définition de XZ_DEFAULTS.
XZ_OPT Ceci est utilisé pour passer des options à xz lorsque ce n’est pas possible de définir les options directement sur la ligne de commande de xz. C’est le cas lorsque xz est exécuté par un script ou un outil, par exemple, GNU [tar]({filename}../../tar)(1).
XZ_OPT=-2v tar caf foo.tar.xz foo
Les scripts peuvent utiliser XZ_OPT, par exemple, pour définir des options de compression par défaut spécifiques à chaque script. Il est toujours recommandé de permettre aux utilisateurs de remplacer XZ_OPT si cela est raisonnable. Par exemple, dans les scripts sh(1), on peut utiliser quelque chose comme ceci :
XZ_OPT=${XZ_OPT-"-7e"}
export XZ_OPT
COMPATIBILITÉ AVEC LZMA UTILS
La syntaxe de la ligne de commande de xz est pratiquement un sur-ensemble de lzma, unlzma et lzcat, tels qu’ils se trouvent dans LZMA Utils 4.32.x. Dans la plupart des cas, il est possible de remplacer LZMA Utils par XZ Utils sans casser les scripts existants. Il existe cependant certaines incompatibilités qui peuvent parfois causer des problèmes.
Niveaux de préréglage de compression
La numérotation des niveaux de préréglage de compression n’est pas identique dans xz et LZMA Utils. La différence la plus importante est la façon dont les tailles de dictionnaire sont mappées à différents préréglages. La taille du dictionnaire est à peu près égale à l’utilisation de la mémoire du décompresseur.
Niveau xz LZMA Utils -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 taille de dictionnaire affectent également l’utilisation de la mémoire du compresseur, mais il existe d’autres différences entre LZMA Utils et XZ Utils qui rendent la différence encore plus importante :
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 LZMA Utils est -7, tandis que dans XZ Utils, il est -6, de sorte que les deux utilisent un dictionnaire de 8 MiB par défaut.
Fichiers .lzma en flux continu ou non
La taille du fichier non compressé peut être stockée dans l’en-tête .lzma. LZMA Utils le fait lors de la compression des fichiers ordinaires. L’alternative consiste à indiquer que la taille non compressée est inconnue et à utiliser un marqueur de fin de flux pour indiquer où le décompresseur doit s’arrêter. LZMA Utils utilise cette méthode lorsque la taille non compressée n’est pas connue, ce qui est le cas, par exemple, dans les flux.
xz prend en charge la décompression des fichiers .lzma avec ou sans marqueur de fin de flux, mais tous les fichiers .lzma créés par xz utiliseront un marqueur de fin de flux et indiqueront que la taille non compressée est inconnue dans l’en-tête .lzma. Cela peut poser problème dans certaines situations inhabituelles. Par exemple, un décompresseur .lzma dans un appareil embarqué peut fonctionner uniquement avec les fichiers dont la taille non compressée est connue. Si vous rencontrez ce problème, vous devez utiliser LZMA Utils ou LZMA SDK pour créer des fichiers .lzma dont la taille non compressée est connue.
Fichiers .lzma non pris en charge
Le format .lzma autorise des valeurs de lc allant jusqu'à 8 et des valeurs de lp allant jusqu'à 4. LZMA Utils peut décompresser des fichiers avec n'importe quelle valeur de lc et de lp, mais crée toujours des fichiers avec lc=3 et lp=0. La création de fichiers avec d'autres valeurs de lc et de lp est possible avec xz et avec le SDK LZMA.
L'implémentation du filtre LZMA1 dans liblzma exige que la somme de lc et de lp ne dépasse pas 4. Par conséquent, les fichiers .lzma qui dépassent cette limite ne peuvent pas être décompressés avec xz.
LZMA Utils ne crée que des fichiers .lzma qui ont une taille de dictionnaire de 2^n (une puissance de 2), mais accepte les fichiers avec n'importe quelle taille de dictionnaire. liblzma n'accepte que les fichiers .lzma qui ont une taille de dictionnaire de 2^n ou 2^n + 2^(n-1). Ceci permet de réduire le nombre de 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 paramètres que liblzma acceptera.
Données parasites à la fin du fichier
Lors de la décompression, LZMA Utils ignore silencieusement tout ce qui se trouve après le premier flux .lzma. Dans la plupart des cas, il s'agit d'un bug. Cela signifie également que LZMA Utils ne prend pas en charge la décompression de fichiers .lzma concaténés.
S'il reste des données après le premier flux .lzma, xz considère le fichier comme corrompu, sauf si l'option --single-stream a été utilisée. Cela peut casser des scripts obscurs qui ont supposé que les données parasites à la fin du fichier seraient ignorées.
NOTES
La sortie compressée peut varier
La sortie compressée exacte produite à partir du même fichier d'entrée non compressé peut varier entre les versions de XZ Utils, même si les options de compression sont identiques. En effet, l'encodeur peut être amélioré (plus rapide ou meilleure compression) sans affecter le format de fichier. La sortie peut même varier entre différentes versions de XZ Utils si différentes options de compilation sont utilisées.
Cela signifie qu'une fois que l'option --rsyncable aura été implémentée, les fichiers résultants ne seront pas nécessairement rsyncables, à moins que les fichiers anciens et nouveaux 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 de l'encodeur est figée pour maintenir une sortie rsyncable stable entre les versions de xz.
Décompresseurs .xz intégrés
Les implémentations de décompresseur .xz intégrées, telles que XZ Embedded, ne prennent pas nécessairement en charge les fichiers créés avec des types de vérification d'intégrité autres que none et crc32. Comme la valeur par défaut est --check=crc64, vous devez utiliser --check=none ou --check=crc32 lorsque vous créez des fichiers pour les systèmes embarqués.
En dehors des systèmes embarqués, tous les décompresseurs de format .xz prennent en charge tous les types de vérification, ou sont au moins capables de décompresser le fichier sans vérifier la vérification d'intégrité si cette dernière n'est pas prise en charge.
XZ Embedded prend en charge les filtres BCJ, mais uniquement avec le décalage de départ par défaut.
EXEMPLES
Bases
Compresser le fichier foo en foo.xz en utilisant le niveau de compression par défaut (-6), et supprimer foo si la compression est réussie :
xz foo
Décompresser bar.xz en bar et ne pas supprimer bar.xz, même si la décompression est réussie :
xz -dk bar.xz
Créez baz.tar.xz avec le préréglage -4e (-4 --extreme), qui est plus lent que le préréglage par défaut -6, mais qui nécessite moins de mémoire pour la compression et la décompression (48 Mio et 5 Mio, respectivement) :
tar cf - baz | xz -4e > baz.tar.xz
Un mélange de fichiers compressés et non compressés peut être décompressé vers la sortie standard avec une seule commande :
xz -dcf a.txt b.txt.xz c.txt d.txt.lzma > abcd.txt
Compression parallèle de nombreux fichiers
Sur GNU et BSD, find(1) et xargs(1) peuvent être utilisés pour paralléliser la compression de nombreux fichiers :
find . -type f \! -name '*.xz' -print0 \
| xargs -0r -P4 -n16 xz -T1
L’option -P de xargs(1) définit le nombre de processus xz 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 doit probablement être de 1 ; avec des dizaines de milliers de fichiers, 100 ou plus peuvent être appropriés pour réduire le nombre de processus xz que xargs(1) créera éventuellement.
L’option -T1 pour xz est là pour le forcer à utiliser le mode monothread, car xargs(1) est utilisé pour contrôler la quantité de parallélisation.
Mode robot
Calculez le nombre d’octets économisés au total après avoir compressé plusieurs fichiers :
xz --robot --list *.xz | awk '/^totals/{print $5-$4}'
Un script peut avoir besoin de savoir si la version de xz est suffisamment récente. Le script sh(1) suivant vérifie que le numéro de version de l’outil xz est d’au moins 5.0.0. Cette méthode est compatible avec les anciennes versions bêta, qui ne prenaient pas en charge l’option --robot :
if ! eval "$(xz --robot --version 2> /dev/null)" ||
[ "$XZ_VERSION" -lt 50000002 ]; then
echo "Votre xz est trop ancien."
fi
unset XZ_VERSION LIBLZMA_VERSION
Définissez une limite d’utilisation de la mémoire pour la décompression à l’aide de XZ_OPT, mais si une limite a déjà été définie, ne l’augmentez pas :
NEWLIM=$((123 << 20)) # 123 Mio
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 compression personnalisées
L’utilisation la plus simple des chaînes de filtres personnalisées consiste à personnaliser un préréglage LZMA2. Cela peut être utile, car les préréglages ne couvrent qu’un sous-ensemble des combinaisons de paramètres 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 extraites de ces deux tableaux :
Preset 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 de taille un peu plus grande (par exemple, 32 Mio) pour être bien compressé, mais que vous souhaitez le compresser plus rapidement que ne le ferait xz -8, un préréglage avec une faible valeur CompCPU (par exemple, 1) peut être modifié pour utiliser un dictionnaire plus grand :
xz --lzma2=preset=1,dict=32MiB foo.tar
Avec certains fichiers, la commande ci-dessus peut être plus rapide que xz -6 tout en offrant une compression significativement meilleure. Cependant, il faut souligner que seuls certains fichiers bénéficient d'un dictionnaire important tout en maintenant une faible valeur CompCPU. La situation la plus évidente où un grand dictionnaire peut beaucoup aider est une archive contenant des fichiers très similaires d'au moins quelques mégaoctets chacun. La taille du dictionnaire doit être significativement supérieure à la taille de tout fichier individuel pour permettre à LZMA2 de tirer pleinement parti des similitudes entre les fichiers consécutifs.
Si une utilisation très élevée de la mémoire pour le compresseur et le décompresseur est acceptable, et que le fichier à compresser est d'au moins plusieurs centaines de mégaoctets, il peut être utile d'utiliser un dictionnaire encore plus grand que les 64 Mo utilisés par xz -9 :
xz -vv --lzma2=dict=192MiB big_foo.tar
L'utilisation de -vv (--verbose --verbose) comme dans l'exemple ci-dessus peut être utile pour voir les exigences de mémoire du compresseur et du décompresseur. N'oubliez pas qu'utiliser un dictionnaire plus grand que la taille du fichier non compressé est une perte de mémoire, de sorte que la commande ci-dessus n'est pas utile pour les petits fichiers.
Parfois, le temps de compression n'a pas d'importance, mais l'utilisation de la mémoire du décompresseur doit être maintenue basse, par exemple pour permettre la décompression du fichier sur un système embarqué. La commande suivante utilise -6e (-6 --extreme) comme base et définit le dictionnaire à seulement 64 KiB. Le fichier résultant peut être décompressé avec XZ Embedded (c'est pourquoi il y a --check=crc32) en utilisant environ 100 KiB de mémoire.
xz --check=crc32 --lzma2=preset=6e,dict=64KiB foo
Si vous souhaitez extraire autant d'octets que possible, ajuster le nombre de bits de contexte littéral (lc) et le nombre de bits de position (pb) peut parfois aider. Ajuster le nombre de bits de position littérale (lp) peut également aider, mais généralement lc et pb sont plus importants. Par exemple, une archive de code source contient principalement du texte US-ASCII, de sorte que ce qui suit peut donner un fichier légèrement plus petit (environ 0,1 %) que xz -6e (essayez également sans lc=4) :
xz --lzma2=preset=6e,pb=0,lc=4 source_code.tar
L'utilisation d'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 x86 BCJ :
xz --x86 --lzma2 libfoo.so
Notez que l'ordre des options de filtre est significatif. Si --x86 est spécifié après --lzma2, xz renverra une erreur, car il ne peut y avoir aucun filtre après LZMA2, et également parce que le filtre x86 BCJ ne peut pas être utilisé comme dernier filtre de la chaîne.
Le filtre Delta avec LZMA2 peut donner de bons résultats avec les images bitmap. Il devrait généralement être meilleur que PNG, qui possède quelques filtres plus avancés que le simple delta mais utilise Deflate pour la compression réelle.
L'image doit être enregistrée au format non compressé, par exemple au format 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 bitmap RVB 24 bits a besoin de dist=3, et il est également bon de passer pb=0 à LZMA2 pour prendre en charge l'alignement sur trois octets :
xz --delta=dist=3 --lzma2=pb=0 foo.tiff
Si plusieurs images ont été regroupées dans une seule archive (par exemple, un fichier .tar), le filtre Delta fonctionnera également, à condition que toutes les images aient 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 : [https://7-zip.org/sdk.html]