Man » xz-Handbuch online - detaillierte Online-Dokumentation für die xz-Manpage

🌍 ☰

xz, unxz, xzcat, lzma, unlzma, lzcat - .xz- und .lzma-Dateien komprimieren oder dekomprimieren

SYNTAX

xz [Option...] [Datei...]

BEFEHLSALIASSE

unxz ist äquivalent zu xz --decompress. xzcat ist äquivalent zu xz --decompress --stdout. lzma ist äquivalent zu xz --format=lzma. unlzma ist äquivalent zu xz --format=lzma --decompress. lzcat ist äquivalent zu xz --format=lzma --decompress --stdout.

Beim Schreiben von Skripten, die zum Dekomprimieren von Dateien dienen, wird empfohlen, immer den Befehl xz mit den entsprechenden Argumenten (xz -d oder xz -dc) anstelle der Befehle unxz und xzcat zu verwenden.

BESCHREIBUNG

xz ist ein allgemeines Datenkomprimierungswerkzeug mit einer Befehlszeilensyntax, die gzip(1) und bzip2(1) ähnelt. Das native Dateiformat ist das .xz-Format, aber das ältere .lzma-Format, das von LZMA Utils verwendet wird, sowie rohe komprimierte Streams ohne Header für Containerformate werden ebenfalls unterstützt. Darüber hinaus wird die Dekomprimierung des .lz-Formats unterstützt, das von lzip verwendet wird.

xz komprimiert oder dekomprimiert jede Datei entsprechend dem ausgewählten Operationsmodus. Wenn keine Dateien angegeben werden oder die Datei - ist, liest xz von der Standardeingabe und schreibt die verarbeiteten Daten in die Standardausgabe. xz wird sich weigern (eine Fehlermeldung anzeigen und die Datei überspringen), komprimierte Daten in die Standardausgabe zu schreiben, wenn es sich um ein Terminal handelt. In ähnlicher Weise wird xz sich weigern, komprimierte Daten von der Standardeingabe zu lesen, wenn es sich um ein Terminal handelt.

Sofern nicht --stdout angegeben ist, werden andere Dateien als - in eine neue Datei geschrieben, deren Name von dem Namen der Quelldatei abgeleitet wird:

Beim Komprimieren wird dem Dateinamen das Suffix des Zieldateiformats (.xz oder .lzma) angehängt, um den Dateinamen für das Ziel zu erhalten.

Beim Dekomprimieren wird das .xz-, .lzma- oder .lz-Suffix aus dem Dateinamen entfernt, um den Dateinamen für das Ziel zu erhalten. xz erkennt auch die Suffixe .txz und .tlz und ersetzt sie durch das Suffix .tar.

Wenn die Zieldatei bereits vorhanden ist, wird eine Fehlermeldung angezeigt und die Datei wird übersprungen.

Sofern nicht in die Standardausgabe geschrieben wird, zeigt xz eine Warnung an und überspringt die Datei, wenn eine der folgenden Bedingungen zutrifft:

Die Datei ist keine reguläre Datei. Symbolische Links werden nicht aufgelöst und gelten daher nicht als reguläre Dateien.

Die Datei hat mehr als einen Hardlink.

Die Datei hat die Setuid-, Setgid- oder Sticky-Bit-Flags gesetzt.

Der Operationsmodus ist auf Komprimieren eingestellt und die Datei hat bereits ein Suffix des Zieldateiformats (.xz oder .txz beim Komprimieren in das .xz-Format und .lzma oder .tlz beim Komprimieren in das .lzma-Format).

Der Operationsmodus ist auf Dekomprimieren eingestellt und die Datei hat kein Suffix von einem der unterstützten Dateiformate (.xz, .txz, .lzma, .tlz oder .lz).

Nach erfolgreicher Komprimierung oder Dekomprimierung einer Datei kopiert xz den Besitzer, die Gruppe, die Berechtigungen, den Zeitpunkt des letzten Zugriffs und den Zeitpunkt der letzten Änderung von der Quelldatei in die Zieldatei. Wenn das Kopieren der Gruppe fehlschlägt, werden die Berechtigungen so geändert, dass die Zieldatei nicht für Benutzer zugänglich wird, die keine Berechtigung hatten, auf die Quelldatei zuzugreifen. xz unterstützt noch nicht das Kopieren anderer Metadaten wie Zugriffskontrolllisten oder erweiterte Attribute.

Sobald die Zieldatei erfolgreich geschlossen wurde, wird die Quelldatei gelöscht, es sei denn, --keep wurde angegeben. Die Quelldatei wird niemals gelöscht, wenn die Ausgabe in die Standardausgabe geschrieben wird oder wenn ein Fehler auftritt.

Das Senden von SIGINFO oder SIGUSR1 an den xz-Prozess bewirkt, dass dieser Fortschrittsinformationen in die Standardfehlerausgabe schreibt. Dies hat nur eine begrenzte Verwendung, da bei Verwendung von --verbose auf einem Terminal automatisch ein sich aktualisierender Fortschrittsbalken angezeigt wird.

Speichernutzung

Die Speichernutzung von xz variiert von wenigen hundert Kilobyte bis zu mehreren Gigabyte, je nach den Komprimierungseinstellungen. Die bei der Komprimierung einer Datei verwendeten Einstellungen bestimmen den Speicherbedarf des Dekomprimierungsprogramms. Typischerweise benötigt das Dekomprimierungsprogramm 5 % bis 20 % der Speichermenge, die das Komprimierungsprogramm bei der Erstellung der Datei benötigt hat. Beispielsweise benötigt das Dekomprimieren einer mit xz -9 erstellten Datei derzeit 65 MiB Speicher. Es ist jedoch möglich, .xz-Dateien zu haben, für deren Dekomprimierung mehrere Gigabyte Speicher erforderlich sind.

Insbesondere Benutzer älterer Systeme empfinden die Möglichkeit einer sehr hohen Speichernutzung möglicherweise als unangenehm. Um unangenehme Überraschungen zu vermeiden, verfügt xz über einen integrierten Speicherbegrenzer, der standardmäßig deaktiviert ist. Obwohl einige Betriebssysteme Möglichkeiten bieten, die Speichernutzung von Prozessen zu begrenzen, wurde die Verwendung dieser Methode als nicht flexibel genug angesehen (z. B. führt die Verwendung von ulimit(1) zur Begrenzung des virtuellen Speichers dazu, dass mmap(2) nicht mehr funktioniert).

Der Speicherbegrenzer kann mit der Befehlszeilenoption --memlimit=limit aktiviert werden. Oft ist es bequemer, den Begrenzer standardmäßig zu aktivieren, indem die Umgebungsvariable XZ_DEFAULTS festgelegt wird, z. B. XZ_DEFAULTS=--memlimit=150MiB. Es ist möglich, die Grenzwerte für die Komprimierung und Dekomprimierung getrennt festzulegen, indem die Optionen --memlimit-compress=limit und --memlimit-decompress=limit verwendet werden. Die Verwendung dieser beiden Optionen außerhalb von XZ_DEFAULTS ist selten nützlich, da ein einzelner xz-Lauf weder Komprimierung noch Dekomprimierung durchführen kann und --memlimit=limit (oder -M limit) kürzer auf der Befehlszeile einzugeben ist.

Wenn der angegebene Speicherbegrenzer während der Dekomprimierung überschritten wird, zeigt xz eine Fehlermeldung an und die Dekomprimierung der Datei schlägt fehl. Wenn der Grenzwert während der Komprimierung überschritten wird, versucht xz, die Einstellungen so anzupassen, dass der Grenzwert nicht mehr überschritten wird (außer bei Verwendung von --format=raw oder --no-adjust). Auf diese Weise schlägt die Operation nicht fehl, es sei denn, der Grenzwert ist sehr klein. Die Anpassung der Einstellungen erfolgt in Schritten, die nicht mit den Komprimierungsstufen übereinstimmen. Wenn der Grenzwert beispielsweise nur geringfügig unter der für xz -9 erforderlichen Menge liegt, werden die Einstellungen nur geringfügig reduziert, nicht bis zu xz -8.

Verkettung und Auffüllen mit .xz-Dateien

Es ist möglich, .xz-Dateien unverändert zu verketten. xz wird diese Dateien so dekomprimieren, als wären sie eine einzige .xz-Datei.

Es ist möglich, zwischen den verketteten Teilen oder nach dem letzten Teil Auffüllung einzufügen. Die Auffüllung muss aus Null-Bytes bestehen, und die Größe der Auffüllung muss ein Vielfaches von vier Bytes sein. Dies kann beispielsweise dann nützlich sein, wenn die .xz-Datei auf einem Medium gespeichert wird, das die Dateigrößen in 512-Byte-Blöcken misst.

Verkettung und Auffüllung sind bei .lzma-Dateien oder rohen Datenströmen nicht zulässig.

OPTIONEN

Ganzzahlige Suffixe und spezielle Werte

An den meisten Stellen, an denen ein ganzzahliges Argument erwartet wird, wird ein optionales Suffix unterstützt, um große Ganzzahlen einfach anzugeben. Zwischen der Ganzzahl und dem Suffix darf kein Leerzeichen vorhanden sein.

KiB Multipliziert die Ganzzahl mit 1.024 (2^10). Ki, k, kB, K und KB werden als Synonyme für KiB akzeptiert.

MiB Multipliziert die Ganzzahl mit 1.048.576 (2^20). Mi, m, M und MB werden als Synonyme für MiB akzeptiert.

GiB Multipliziert die Ganzzahl mit 1.073.741.824 (2^30). Gi, g, G und GB werden als Synonyme für GiB akzeptiert.

Der spezielle Wert „max“ kann verwendet werden, um den maximalen Ganzzahlwert anzugeben, der von der Option unterstützt wird.

Betriebsmodus

Wenn mehrere Optionen für den Betriebsmodus angegeben werden, gilt die letzte.

-z, --compress
Komprimieren. Dies ist der Standard-Betriebsmodus, wenn keine Option für den Betriebsmodus angegeben wird und kein anderer Betriebsmodus aus dem Befehlsnamen abgeleitet wird (z. B. impliziert unxz --decompress).

Nach erfolgreicher Komprimierung wird die Quelldatei gelöscht, es sei denn, es wird in die Standardausgabe geschrieben oder --keep angegeben.

-d, --decompress, --uncompress
Dekompprimieren. Nach erfolgreicher Dekomprimierung wird die Quelldatei gelöscht, es sei denn, es wird in die Standardausgabe geschrieben oder --keep angegeben.

-t, --test
Testet die Integrität komprimierter Dateien. Diese Option ist äquivalent zu --decompress --stdout, außer dass die dekomprimierten Daten verworfen werden, anstatt in die Standardausgabe geschrieben zu werden. Es werden keine Dateien erstellt oder gelöscht.

-l, --list
Gibt Informationen über komprimierte Dateien aus. Es wird keine dekomprimierte Ausgabe erzeugt, und es werden keine Dateien erstellt oder gelöscht. Im Auflistungsmodus kann das Programm die komprimierten Daten nicht aus der Standardeingabe oder aus anderen nicht-seekfähigen Quellen lesen.

Die Standardauflistung zeigt grundlegende Informationen über Dateien, eine Datei pro Zeile. Um detailliertere Informationen zu erhalten, verwenden Sie auch die Option --verbose. Für noch mehr Informationen verwenden Sie --verbose zweimal, aber beachten Sie, dass dies langsam sein kann, da das Abrufen aller zusätzlichen Informationen viele Suchvorgänge erfordert. Die Breite der ausführlichen Ausgabe überschreitet 80 Zeichen, so dass es bequem sein kann, die Ausgabe beispielsweise an less -S weiterzuleiten, wenn das Terminal nicht breit genug ist.

Die genaue Ausgabe kann je nach xz-Version und verschiedenen Gebietsschemas variieren. Für maschinenlesbare Ausgabe sollte --robot --list verwendet werden.

Operationsmodifikatoren

-k, --keep

Die Eingabedateien nicht löschen.

Seit xz 5.2.6 bewirkt diese Option auch, dass xz komprimiert oder dekomprimiert, selbst wenn die Eingabe ein symbolischer Link zu einer regulären Datei ist, mehr als einen Hardlink hat oder das Setuid-, Setgid- oder Sticky-Bit gesetzt hat. Die Setuid-, Setgid- und Sticky-Bits werden nicht in die Zieldatei kopiert. In früheren Versionen wurde dies nur mit --force durchgeführt.

-f, --force

Diese Option hat mehrere Auswirkungen:

Wenn die Zieldatei bereits vorhanden ist, wird sie vor dem Komprimieren oder Dekomprimieren gelöscht.

Komprimiert oder dekomprimiert, selbst wenn die Eingabe ein symbolischer Link zu einer regulären Datei ist, mehr als einen Hardlink hat oder das Setuid-, Setgid- oder Sticky-Bit gesetzt hat. Die Setuid-, Setgid- und Sticky-Bits werden nicht in die Zieldatei kopiert.

Wenn sie mit --decompress --stdout verwendet wird und xz den Typ der Quelldatei nicht erkennen kann, wird die Quelldatei unverändert in die Standardausgabe kopiert. Dadurch kann xzcat --force wie cat(1) für Dateien verwendet werden, die nicht mit xz komprimiert wurden. Beachten Sie, dass xz in Zukunft möglicherweise neue komprimierte Dateiformate unterstützt, wodurch xz mehr Dateitypen dekomprimieren kann, anstatt sie unverändert in die Standardausgabe zu kopieren. --format=format kann verwendet werden, um xz auf das Dekomprimieren nur eines einzelnen Dateiformats zu beschränken.

-c, --stdout, --to-stdout

Die komprimierten oder dekomprimierten Daten anstelle einer Datei in die Standardausgabe schreiben. Dies impliziert --keep.

--single-stream

Nur den ersten .xz-Stream dekomprimieren und alle nachfolgenden Eingabedaten im Stream geräuschlos ignorieren. Normalerweise würde xz eine Fehlermeldung anzeigen, wenn solche nachfolgenden Daten vorhanden wären.

xz dekomprimiert niemals mehr als einen Stream aus .lzma-Dateien oder Raw-Streams, aber diese Option bewirkt dennoch, dass xz die möglichen nachfolgenden Daten nach der .lzma-Datei oder dem Raw-Stream ignoriert.

Diese Option hat keine Auswirkung, wenn der Operationsmodus nicht --decompress oder --test ist.

Seit xz 5.7.1alpha impliziert --single-stream --keep.

--no-sparse

Die Erstellung von Sparse-Dateien deaktivieren. Standardmäßig versucht xz, beim Dekomprimieren in eine reguläre Datei die Datei Sparse zu machen, wenn die dekomprimierten Daten lange Sequenzen von Binärnullen enthalten. Es funktioniert auch beim Schreiben in die Standardausgabe, solange die Standardausgabe mit einer regulären Datei verbunden ist und bestimmte zusätzliche Bedingungen erfüllt sind, um dies sicherzustellen. Das Erstellen von Sparse-Dateien kann Speicherplatz sparen und die Dekomprimierung beschleunigen, indem die Menge der Festplatten-E/A reduziert wird.

-S .suf, --suffix=.suf

Beim Komprimieren .suf als Suffix für die Zieldatei anstelle von .xz oder .lzma verwenden. Wenn nicht in die Standardausgabe geschrieben wird und die Quelldatei bereits das Suffix .suf hat, wird eine Warnung angezeigt und die Datei übersprungen.

Beim Dekomprimieren werden Dateien mit dem Suffix .suf zusätzlich zu Dateien mit den Suffixen .xz, .txz, .lzma, .tlz oder .lz erkannt. Wenn die Quelldatei das Suffix .suf hat, wird das Suffix entfernt, um den Zieldateinamen zu erhalten.

Beim Komprimieren oder Dekomprimieren von Raw-Streams (--format=raw) muss immer ein Suffix angegeben werden, es sei denn, es wird in die Standardausgabe geschrieben, da für Raw-Streams kein Standardsuffix vorhanden ist.

--files[=Datei]

Liest die zu verarbeitenden Dateinamen aus einer Datei; wenn die Datei weggelassen wird, werden die Dateinamen aus der Standardeingabe gelesen. Dateinamen müssen mit dem Zeilenumbruchzeichen enden. Ein Bindestrich (-) wird als normaler Dateiname behandelt; er bedeutet nicht Standardeingabe. Wenn Dateinamen auch als Befehlszeilenargumente angegeben werden, werden diese verarbeitet, bevor die aus der Datei gelesenen Dateinamen verarbeitet werden.

--files0[=Datei]

Dies ist identisch mit --files[=Datei], mit dem Unterschied, dass jede Datei mit dem Nullzeichen enden muss.

Grundlegende Dateiformat- und Komprimierungsoptionen

-F Format, --format=Format

Gibt das zu komprimierende oder dekomprimierende Dateiformat an:

auto Dies ist die Standardeinstellung. Beim Komprimieren ist auto äquivalent zu xz. Beim Dekomprimieren wird das Format der Eingabedatei automatisch erkannt. Beachten Sie, dass Raw-Streams (erstellt mit --format=raw) nicht automatisch erkannt werden können.

xz Komprimiert in das .xz-Dateiformat oder akzeptiert nur .xz-Dateien beim Dekomprimieren.

lzma, allein

Komprimiert in das Legacy-.lzma-Dateiformat oder akzeptiert nur .lzma-Dateien beim Dekomprimieren. Der alternative Name allein wird zur Abwärtskompatibilität mit LZMA Utils bereitgestellt.

lzip Akzeptiert nur .lz-Dateien beim Dekomprimieren. Die Komprimierung wird nicht unterstützt.

Die .lz-Formatversionen 0 und 1 werden unterstützt. Version-0-Dateien wurden von lzip 1.3 und älter erstellt. Solche Dateien sind nicht häufig, können aber in Dateiverzeichnissen gefunden werden, da einige Quellpakete in diesem Format veröffentlicht wurden. Möglicherweise haben Personen auch alte persönliche Dateien in diesem Format. Die Unterstützung für die Dekomprimierung des Formats Version 0 wurde in lzip 1.18 entfernt. lzip 1.4 und neuer erstellen Dateien im Format Version 1.

raw Komprimiert oder dekomprimiert einen Raw-Stream (keine Header). Dies ist nur für fortgeschrittene Benutzer gedacht. Um Raw-Streams zu dekodieren, müssen Sie --format=raw verwenden und die Filterkette explizit angeben, die normalerweise in den Container-Headern gespeichert wäre.

-C Prüfung, --check=Prüfung

Gibt den Typ der Integritätsprüfung an. Die Prüfung wird aus den unkomprimierten Daten berechnet und in der .xz-Datei gespeichert. Diese Option hat nur beim Komprimieren in das .xz-Format eine Wirkung; das .lzma-Format unterstützt keine Integritätsprüfungen. Die Integritätsprüfung (falls vorhanden) wird überprüft, wenn die .xz-Datei dekomprimiert wird.

Unterstützte Prüftypen:

none Berechnet keine Integritätsprüfung. Dies ist normalerweise keine gute Idee. Dies kann nützlich sein, wenn die Integrität der Daten bereits auf andere Weise überprüft wird.

crc32 Berechnet CRC32 unter Verwendung des Polynoms aus IEEE-802.3 (Ethernet).

crc64 Berechnet CRC64 unter Verwendung des Polynoms aus ECMA-182. Dies ist die Standardeinstellung, da sie etwas besser darin ist, beschädigte Dateien zu erkennen, und der Geschwindigkeitsunterschied vernachlässigbar ist.

sha256 Berechne SHA-256. Dies ist etwas langsamer als CRC32 und CRC64.

Die Integrität der .xz-Header wird immer mit CRC32 überprüft. Es ist nicht möglich, dies zu ändern oder zu deaktivieren.

--ignore-check

Überprüfe beim Dekomprimieren nicht die Integrität der komprimierten Daten. Die CRC32-Werte in den .xz-Headern werden weiterhin normal überprüft.

Verwende diese Option nicht, es sei denn, du weißt, was du tust. Mögliche Gründe für die Verwendung dieser Option:

Versuchen, Daten aus einer beschädigten .xz-Datei wiederherzustellen.

Beschleunigung der Dekomprimierung. Dies ist hauptsächlich bei SHA-256 oder bei Dateien, die sich extrem gut komprimieren lassen, wichtig. Es wird empfohlen, diese Option nicht für diesen Zweck zu verwenden, es sei denn, die Dateintegrität wird auf andere Weise extern überprüft.

-0 ... -9

Wähle eine Kompressionsvoreinstellungsebene aus. Standardmäßig ist -6 eingestellt. Wenn mehrere Voreinstellungsebenen angegeben werden, gilt die letzte. Wenn bereits eine benutzerdefinierte Filterkette angegeben wurde, wird diese durch die Festlegung einer Kompressionsvoreinstellungsebene gelöscht.

Die Unterschiede zwischen den Voreinstellungen sind größer als bei gzip(1) und bzip2(1). Die ausgewählten Komprimierungseinstellungen bestimmen die Speicheranforderungen des Dekompressors, sodass die Verwendung einer zu hohen Voreinstellungsebene dazu führen kann, dass die Dekomprimierung der Datei auf einem alten System mit wenig RAM mühsam wird. Insbesondere ist es keine gute Idee, wie oft bei gzip(1) und bzip2(1), blind -9 für alles zu verwenden.

-0 ... -3

Dies sind relativ schnelle Voreinstellungen. -0 ist manchmal schneller als gzip -9 und komprimiert gleichzeitig besser. Die höheren Stufen haben oft eine Geschwindigkeit, die mit bzip2(1) vergleichbar ist, mit einem vergleichbaren oder besseren Komprimierungsverhältnis, obwohl die Ergebnisse stark vom Typ der komprimierten Daten abhängen.

-4 ... -6

Gute bis sehr gute Komprimierung bei gleichzeitiger Reduzierung des Speicherbedarfs des Dekompressors, selbst für alte Systeme. -6 ist die Standardeinstellung, die normalerweise eine gute Wahl ist, um Dateien zu verteilen, die auch auf Systemen mit nur 16 MiB RAM dekomprimiert werden können. (-5e oder -6e sind möglicherweise auch einen Versuch wert. Siehe --extreme.)

-7 ... -9

Diese ähneln -6, haben aber höhere Anforderungen an den Kompressor- und Dekompressorspeicher. Diese sind nur dann nützlich, wenn Dateien größer als 8 MiB, 16 MiB bzw. 32 MiB komprimiert werden.

Auf derselben Hardware beträgt die Dekomprimierungsgeschwindigkeit ungefähr eine konstante Anzahl von Bytes komprimierter Daten pro Sekunde. Mit anderen Worten: Je besser die Komprimierung, desto schneller ist in der Regel die Dekomprimierung. Dies bedeutet auch, dass die Menge der erzeugten nicht komprimierten Ausgabe pro Sekunde stark variieren kann.

Die folgende Tabelle fasst die Merkmale der Voreinstellungen zusammen:

Voreinstellung 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

Beschreibungen der Spalten:

DictSize ist die LZMA2-Wörterbuchgröße. Es ist eine Verschwendung von Speicher, ein Wörterbuch zu verwenden, das größer ist als die Größe der unkomprimierten Datei. Aus diesem Grund ist es ratsam, die Voreinstellungen -7 ... -9 zu vermeiden, wenn sie nicht wirklich benötigt werden. Bei -6 und niedriger ist die verschwendete Speichermenge in der Regel gering genug, um keine Rolle zu spielen.

CompCPU ist eine vereinfachte Darstellung der LZMA2-Einstellungen, die die Kompressionsgeschwindigkeit beeinflussen. Die Wörterbuchgröße beeinflusst ebenfalls die Geschwindigkeit, sodass CompCPU für die Stufen -6 ... -9 gleich ist, aber höhere Stufen dennoch etwas langsamer sind. Um es noch langsamer zu machen und möglicherweise eine bessere Komprimierung zu erzielen, siehe --extreme.

CompMem enthält die Speicheranforderungen des Kompressors im Single-Thread-Modus. Sie können sich zwischen verschiedenen xz-Versionen geringfügig unterscheiden.

DecMem enthält die Speicheranforderungen des Dekompressors. Das heißt, die Komprimierungseinstellungen bestimmen die Speicheranforderungen des Dekompressors. Die genaue Speichernutzung des Dekompressors ist etwas größer als die LZMA2-Wörterbuchgröße, aber die Werte in der Tabelle wurden auf das nächste volle MiB aufgerundet.

Die Speicheranforderungen des Multi-Thread-Modus sind deutlich höher als im Single-Thread-Modus. Mit dem Standardwert von --block-size benötigt jeder Thread 3*3*DictSize plus CompMem oder DecMem. Zum Beispiel benötigen vier Threads mit der Voreinstellung -6 660–670 MiB Speicher.

-e, --extreme

Verwenden Sie eine langsamere Variante der ausgewählten Komprimierungsvoreinstellung (-0 ... -9), um hoffentlich ein etwas besseres Komprimierungsverhältnis zu erzielen, aber mit etwas Pech kann dies auch zu einem schlechteren Ergebnis führen. Die Speichernutzung des Dekompressors wird nicht beeinflusst, aber die Speichernutzung des Kompressors erhöht sich bei den Voreinstellungen -0 ... -3 etwas.

Da es zwei Voreinstellungen mit Wörterbuchgrößen von 4 MiB und 8 MiB gibt, verwenden die Voreinstellungen -3e und -5e etwas schnellere Einstellungen (niedrigerer CompCPU-Wert) als -4e bzw. -6e. Auf diese Weise sind keine zwei Voreinstellungen identisch.

Voreinstellung 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

Zum Beispiel gibt es insgesamt vier Voreinstellungen, die eine Wörterbuchgröße von 8 MiB verwenden, deren Reihenfolge von der schnellsten bis zur langsamsten -5, -6, -5e und -6e ist.

--fast
--best Dies sind etwas irreführende Aliase für -0 bzw. -9. Diese werden nur zur Abwärtskompatibilität mit LZMA Utils bereitgestellt. Vermeiden Sie die Verwendung dieser Optionen.

--block-size=größe

Beim Komprimieren in das .xz-Format wird die Eingabedatei in Blöcke der Größe Bytes aufgeteilt. Die Blöcke werden unabhängig voneinander komprimiert, was die Multi-Threading-Verarbeitung erleichtert und eine eingeschränkte, zufällige Dekomprimierung ermöglicht. Diese Option wird normalerweise verwendet, um die Standardblockgröße im Multi-Thread-Modus zu überschreiben, aber diese Option kann auch im Single-Thread-Modus verwendet werden.

Im Mehrfaden-Modus werden etwa das Dreifache der Bytes für jeden Thread zur Pufferung von Eingabe und Ausgabe reserviert. Die Standardgröße beträgt das Dreifache der LZMA2-Wörterbuchgröße oder 1 MiB, je nachdem, welcher Wert größer ist. Ein guter Wert liegt typischerweise zwischen dem Zwei- bis Vierfachen der Größe des LZMA2-Wörterbuchs oder mindestens 1 MiB. Die Verwendung einer Größe, die kleiner als die LZMA2-Wörterbuchgröße ist, ist eine Verschwendung von RAM, da der LZMA2-Wörterbuchpuffer dann nie vollständig genutzt wird. Im Mehrfaden-Modus werden die Größen der Blöcke in den Block-Headern gespeichert. Diese Größeninformation ist für die Mehrfaden-Dekompression erforderlich.

Im Einfaden-Modus erfolgt standardmäßig keine Blockaufteilung. Das Setzen dieser Option hat keinen Einfluss auf den Speicherverbrauch. Es werden keine Größeninformationen in den Block-Headern gespeichert, daher sind die in einem Einfaden-Modus erstellten Dateien nicht identisch mit den in einem Mehrfaden-Modus erstellten Dateien. Das Fehlen von Größeninformationen bedeutet auch, dass xz die Dateien nicht im Mehrfaden-Modus dekomprimieren kann.

--block-list=items

Beim Komprimieren in das .xz-Format wird nach den angegebenen Intervallen von unkomprimierten Daten ein neuer Block mit einer optionalen benutzerdefinierten Filterkette gestartet.

Die Elemente sind eine durch Kommas getrennte Liste. Jedes Element besteht aus einer optionalen Filterkettennummer zwischen 0 und 9, gefolgt von einem Doppelpunkt (:) und einer erforderlichen Größe der unkomprimierten Daten. Das Weglassen eines Elements (zwei oder mehr aufeinanderfolgende Kommas) ist eine Kurzschreibweise, um die Größe und die Filter des vorherigen Elements zu verwenden.

Wenn die Eingabedatei größer ist als die Summe der Größen in den Elementen, wird das letzte Element wiederholt, bis das Ende der Datei erreicht ist. Ein spezieller Wert von 0 kann als letzter Größenwert verwendet werden, um anzugeben, dass der Rest der Datei als einzelner Block kodiert werden soll.

Eine alternative Filterkette für jeden Block kann in Kombination mit den Optionen --filters1=filters ... --filters9=filters angegeben werden. Diese Optionen definieren Filterketten mit einer Kennung zwischen 1 und 9. Die Filterkette 0 kann verwendet werden, um sich auf die Standardfilterkette zu beziehen, die der Fall ist, wenn keine Filterkette angegeben wird. Die Filterkettenkennung kann vor der Größe der unkomprimierten Daten verwendet werden, gefolgt von einem Doppelpunkt (:). Zum Beispiel, wenn man --block-list=1:2MiB,3:2MiB,2:4MiB,,2MiB,0:4MiB angibt, werden Blöcke mit Folgendem erstellt:

Die durch --filters1 angegebene Filterkette und 2 MiB Eingabe

Die durch --filters3 angegebene Filterkette und 2 MiB Eingabe

Die durch --filters2 angegebene Filterkette und 4 MiB Eingabe

Die Standardfilterkette und 2 MiB Eingabe

Die Standardfilterkette und 4 MiB Eingabe für jeden Block bis zum Ende der Eingabe.

Wenn man eine Größe angibt, die die Blockgröße des Encoders überschreitet (entweder der Standardwert im Mehrfaden-Modus oder der mit --block-size=size angegebene Wert), erstellt der Encoder zusätzliche Blöcke und behält dabei die in den Elementen angegebenen Grenzen bei. Zum Beispiel, wenn man --block-size=10MiB --block-list=5MiB,10MiB,8MiB,12MiB,24MiB angibt und die Eingabedatei 80 MiB groß ist, erhält man 11 Blöcke: 5, 10, 8, 10, 2, 10, 10, 4, 10, 10 und 1 MiB.

Im Mehrfaden-Modus werden die Größen der Blöcke in den Block-Headern gespeichert. Dies wird im Einzel-Faden-Modus nicht durchgeführt, sodass die kodierte Ausgabe nicht identisch mit der des Mehrfaden-Modus ist.

--flush-timeout=timeout

Beim Komprimieren wird, wenn seit dem vorherigen Flush mehr als Timeout Millisekunden (eine positive ganze Zahl) vergangen sind und das Lesen weiterer Eingabedaten blockieren würde, alle ausstehenden Eingabedaten aus dem Encoder geleert und im Ausgabestrom verfügbar gemacht. Dies kann nützlich sein, wenn xz zum Komprimieren von Daten verwendet wird, die über ein Netzwerk gestreamt werden. Kleine Timeout-Werte stellen die Daten am Empfängerende mit einer geringen Verzögerung bereit, während größere Timeout-Werte ein besseres Komprimierungsverhältnis ermöglichen.

Diese Funktion ist standardmäßig deaktiviert. Wenn diese Option mehr als einmal angegeben wird, hat die letzte Angabe Vorrang. Der spezielle Timeout-Wert 0 kann verwendet werden, um diese Funktion explizit zu deaktivieren.

Diese Funktion ist auf nicht-POSIX-Systemen nicht verfügbar.

Diese Funktion ist noch experimentell. Derzeit ist xz nicht für die Dekomprimierung des Streams in Echtzeit geeignet, da xz die Pufferung durchführt.

--no-sync

Synchronisieren Sie die Zieldatei und ihr Verzeichnis nicht mit dem Speichergerät, bevor Sie die Quelldatei entfernen. Dies kann die Leistung verbessern, wenn viele kleine Dateien komprimiert oder dekomprimiert werden. Wenn das System jedoch kurz nach dem Löschen abstürzt, ist es möglich, dass die Zieldatei nicht auf das Speichergerät geschrieben wurde, aber die Löschoperation durchgeführt wurde. In diesem Fall sind weder die ursprüngliche Quelldatei noch die Zieldatei verfügbar.

Diese Option hat nur dann eine Wirkung, wenn xz die Quelldatei löschen wird. In anderen Fällen wird keine Synchronisierung durchgeführt.

Die Synchronisierung und --no-sync wurden in xz 5.7.1alpha hinzugefügt.

--memlimit-compress=limit

Legen Sie eine Speicherbegrenzung für die Komprimierung fest. Wenn diese Option mehr als einmal angegeben wird, hat die letzte Angabe Vorrang.

Wenn die Komprimierungseinstellungen die Grenze überschreiten, versucht xz, die Einstellungen nach unten anzupassen, so dass die Grenze nicht mehr überschritten wird, und zeigt eine Meldung an, dass eine automatische Anpassung vorgenommen wurde. Die Anpassungen werden in dieser Reihenfolge vorgenommen: Reduzierung der Anzahl der Threads, Umschaltung in den Einzel-Faden-Modus, wenn selbst ein einziger Thread im Mehrfaden-Modus die Grenze überschreitet, und schließlich Reduzierung der LZMA2-Wörterbuchgröße.

Beim Komprimieren mit --format=raw oder wenn --no-adjust angegeben wurde, kann nur die Anzahl der Threads reduziert werden, da dies ohne Beeinträchtigung der komprimierten Ausgabe erfolgen kann.

Wenn die Grenze selbst nach den oben beschriebenen Anpassungen nicht eingehalten werden kann, wird eine Fehlermeldung angezeigt und xz wird mit dem Exit-Status 1 beendet.

Die Grenze kann auf verschiedene Arten angegeben werden:

Die Grenze kann ein absoluter Wert in Bytes sein. Die Verwendung eines ganzzahligen Suffixes wie MiB kann nützlich sein. Beispiel: --memlimit-compress=80MiB

Die Grenze kann als Prozentsatz des gesamten physischen Speichers (RAM) angegeben werden. Dies kann besonders nützlich sein, wenn die Umgebungsvariable XZ_DEFAULTS in einem Shell-Initialisierungsskript festgelegt wird, das zwischen verschiedenen Computern gemeinsam genutzt wird. Auf diese Weise ist die Grenze auf Systemen mit mehr Speicher automatisch größer. Beispiel: --memlimit-compress=70%

Die Grenze kann auf ihren Standardwert zurückgesetzt werden, indem sie auf 0 gesetzt wird. Dies entspricht derzeit dem Einstellen der Grenze auf maximal (keine Speicherbegrenzung).

Für 32-Bit-xz gibt es einen Sonderfall: Wenn die Grenze 4020 MiB überschreiten würde, wird die Grenze auf 4020 MiB gesetzt. Auf MIPS32 werden stattdessen 2000 MiB verwendet. (Die Werte 0 und max sind davon nicht betroffen. Eine ähnliche Funktion gibt es nicht für die Dekomprimierung.) Dies kann hilfreich sein, wenn eine 32-Bit-Anwendung Zugriff auf einen 4-GiB-Adressraum (2 GiB auf MIPS32) hat, während sie hoffentlich in anderen Situationen keinen Schaden anrichtet.

Siehe auch den Abschnitt Speicherverbrauch.

--memlimit-decompress=grenze

Setzt eine Speicherbegrenzung für die Dekomprimierung fest. Dies betrifft auch den Modus --list. Wenn die Operation nicht möglich ist, ohne die Grenze zu überschreiten, zeigt xz eine Fehlermeldung an und die Dekomprimierung der Datei schlägt fehl. Siehe --memlimit-compress=grenze für mögliche Möglichkeiten zur Angabe der Grenze.

--memlimit-mt-decompress=grenze

Setzt eine Speicherbegrenzung für die Multithread-Dekomprimierung fest. Dies kann sich nur auf die Anzahl der Threads auswirken; dies führt niemals dazu, dass xz die Dekomprimierung einer Datei verweigert. Wenn die Grenze zu niedrig ist, um Multithreading zu ermöglichen, wird die Grenze ignoriert und xz setzt die Dekomprimierung im Single-Thread-Modus fort. Beachten Sie, dass, wenn auch --memlimit-decompress verwendet wird, dies immer sowohl für den Single-Thread- als auch für den Multithread-Modus gilt, und die effektive Grenze für Multithreading daher niemals höher ist als die mit --memlimit-decompress festgelegte Grenze.

Im Gegensatz zu den anderen Speicherbegrenzungsoptionen hat --memlimit-mt-decompress=grenze eine systemspezifische Standardgrenze. xz --info-memory kann verwendet werden, um den aktuellen Wert anzuzeigen.

Diese Option und ihr Standardwert existieren, weil der Multithread-Dekomprimierer ohne Begrenzung bei einigen Eingabedateien eine enorme Menge an Speicher zuordnen könnte. Wenn die Standardgrenze auf Ihrem System zu niedrig ist, können Sie die Grenze gerne erhöhen, aber setzen Sie sie niemals auf einen Wert, der größer ist als die Menge des nutzbaren RAM, da xz mit geeigneten Eingabedateien versuchen wird, diese Menge an Speicher zu verwenden, selbst bei einer geringen Anzahl von Threads. Wenn der Speicher knapp wird oder es zu viel Auslagerung kommt, verbessert sich die Dekomprimierungsleistung nicht.

Siehe --memlimit-compress=grenze für mögliche Möglichkeiten zur Angabe der Grenze. Das Setzen von Grenze auf 0 setzt die Grenze auf den systemspezifischen Standardwert zurück.

-M grenze, --memlimit=grenze, --memory=grenze

Dies entspricht der Angabe von --memlimit-compress=grenze --memlimit-decompress=grenze --memlimit-mt-decompress=grenze.

--no-adjust

Zeigt eine Fehlermeldung an und beendet das Programm, wenn die Speicherverbrauchsgrenze nicht eingehalten werden kann, ohne Einstellungen zu ändern, die die komprimierte Ausgabe beeinflussen. Das bedeutet, dass verhindert wird, dass xz den Encoder von einem Multithread-Modus in einen Singlethread-Modus umschaltet und die LZMA2-Wörterbuchgröße reduziert. Auch wenn diese Option verwendet wird, kann die Anzahl der Threads reduziert werden, um die Speicherverbrauchsgrenze einzuhalten, da dies die komprimierte Ausgabe nicht beeinträchtigt.

Die automatische Anpassung ist immer deaktiviert, wenn rohe Streams erstellt werden (--format=raw).

-T threads, --threads=threads

Gibt die Anzahl der zu verwendenden Worker-Threads an. Wenn Threads auf einen speziellen Wert 0 gesetzt wird, verwendet xz bis zu so viele Threads, wie die Prozessoren des Systems unterstützen. Die tatsächliche Anzahl der Threads kann geringer sein als Threads, wenn die Eingabedatei nicht groß genug ist, um das Threading mit den angegebenen Einstellungen zu ermöglichen, oder wenn die Verwendung von mehr Threads die Speicherverbrauchsgrenze überschreiten würde.

Der Singlethread- und der Multithread-Kompressor erzeugen unterschiedliche Ausgaben. Der Singlethread-Kompressor liefert die kleinste Dateigröße, aber nur die Ausgabe des Multithread-Kompressors kann mit mehreren Threads dekomprimiert werden. Wenn Threads auf 1 gesetzt wird, wird der Singlethread-Modus verwendet. Wenn Threads auf einen anderen Wert gesetzt wird, einschließlich 0, wird der Multithread-Kompressor verwendet, auch wenn das System nur einen Hardware-Thread unterstützt. (xz 2.x verwendete in dieser Situation den Singlethread-Modus.)

Um den Multithread-Modus mit nur einem Thread zu verwenden, setzen Sie Threads auf +1. Das + Präfix hat keine Auswirkung bei anderen Werten als 1. Eine Speicherverbrauchsgrenze kann dazu führen, dass xz in den Singlethread-Modus wechselt, es sei denn, --no-adjust wird verwendet. Die Unterstützung für das + Präfix wurde in xz 5.4.0 hinzugefügt.

Wenn eine automatische Anzahl von Threads angefordert wurde und keine Speicherverbrauchsgrenze angegeben wurde, wird dann eine systemeigene Standard-Soft-Grenze verwendet, um möglicherweise die Anzahl der Threads zu begrenzen. Es ist eine Soft-Grenze in dem Sinne, dass sie ignoriert wird, wenn die Anzahl der Threads eins wird, sodass eine Soft-Grenze xz niemals daran hindert, zu komprimieren oder zu dekomprimieren. Diese Standard-Soft-Grenze führt nicht dazu, dass xz vom Multithread-Modus in den Singlethread-Modus wechselt. Die aktiven Grenzwerte können mit xz --info-memory angezeigt werden.

Derzeit ist die einzige Threading-Methode das Aufteilen der Eingabe in Blöcke und das unabhängige Komprimieren dieser Blöcke. Die Standardblockgröße hängt von der Komprimierungsstufe ab und kann mit der Option --block-size=size überschrieben werden.

Threaded Dekompression funktioniert nur bei Dateien, die mehrere Blöcke mit Größeninformationen in den Block-Headern enthalten. Alle ausreichend großen Dateien, die im Multithread-Modus komprimiert wurden, erfüllen diese Bedingung, aber Dateien, die im Singlethread-Modus komprimiert wurden, tun dies nicht, selbst wenn --block-size=size verwendet wurde.

Der Standardwert für Threads ist 0. In xz 5.4.x und älter ist der Standardwert 1.

Benutzerdefinierte Kompressor-Filterketten

Eine benutzerdefinierte Filterkette ermöglicht es, die Komprimierungseinstellungen detailliert anzugeben, anstatt sich auf die mit den Voreinstellungen verknüpften Einstellungen zu verlassen. Wenn eine benutzerdefinierte Filterkette angegeben wird, werden die Voreinstellungsoptionen (-0 ... -9 und --extreme), die früher in der Befehlszeile verwendet wurden, ignoriert. Wenn eine Voreinstellungsoption nach einer oder mehreren benutzerdefinierten Filterkettenoptionen angegeben wird, wird die neue Voreinstellung wirksam, und die zuvor angegebenen benutzerdefinierten Filterkettenoptionen werden ignoriert.

Eine Filterkette ist vergleichbar mit der Pipe-Funktion auf der Kommandozeile. Beim Komprimieren wird die unkomprimierte Eingabe an den ersten Filter weitergeleitet, dessen Ausgabe an den nächsten Filter (falls vorhanden) weitergeleitet wird. Die Ausgabe des letzten Filters wird in die komprimierte Datei geschrieben. Die maximale Anzahl von Filtern in der Kette beträgt vier, aber typischerweise hat eine Filterkette nur ein oder zwei Filter.

Viele Filter haben Einschränkungen, wo sie sich in der Filterkette befinden dürfen: Einige Filter können nur als letzter Filter in der Kette funktionieren, einige nur als Nicht-letzter Filter und einige funktionieren an jeder beliebigen Position in der Kette. Abhängig vom Filter ist diese Einschränkung entweder inhärent im Filterdesign vorhanden oder dient dazu, Sicherheitsrisiken zu vermeiden.

Eine benutzerdefinierte Filterkette kann auf zwei verschiedene Arten angegeben werden. Die Optionen `--filters=filters` und `--filters1=filters ... --filters9=filters` ermöglichen die Angabe einer vollständigen Filterkette in einer einzigen Option unter Verwendung der liblzma-Filter-String-Syntax. Alternativ kann eine Filterkette durch die Verwendung einzelner Filteroptionen in der gewünschten Reihenfolge angegeben werden. Das bedeutet, dass die Reihenfolge der einzelnen Filteroptionen von Bedeutung ist! Beim Dekodieren von Raw-Streams (`--format=raw`) muss die Filterkette in der gleichen Reihenfolge angegeben werden, in der sie beim Komprimieren angegeben wurde. Alle einzelnen Filter- oder Preset-Optionen, die vor der vollständigen Kettenoption (`--filters=filters`) angegeben werden, werden verworfen. Einzelne Filter, die nach der vollständigen Kettenoption angegeben werden, setzen die Filterkette zurück.

Sowohl die vollständigen als auch die einzelnen Filteroptionen akzeptieren filterspezifische Optionen als durch Kommas getrennte Liste. Zusätzliche Kommas in den Optionen werden ignoriert. Jede Option hat einen Standardwert, also geben Sie nur diejenigen an, die Sie ändern möchten.

Um die gesamte Filterkette und die Optionen anzuzeigen, verwenden Sie xz -vv (d. h. verwenden Sie --verbose zweimal). Dies funktioniert auch zum Anzeigen der Filterkettenoptionen, die von Presets verwendet werden.

`--filters=filters`
Geben Sie die vollständige Filterkette oder ein Preset in einer einzigen Option an. Jeder Filter kann durch Leerzeichen oder zwei Bindestriche (`--`) getrennt werden. `filters` muss möglicherweise in der Shell-Befehlszeile in Anführungszeichen gesetzt werden, damit es als eine einzige Option geparst wird. Um Optionen anzugeben, verwenden Sie `:` oder `=`. Ein Preset kann mit einem `-` versehen und mit null oder mehr Flags versehen werden. Das einzige unterstützte Flag ist `e`, um die gleichen Optionen wie `--extreme` anzuwenden.

`--filters1=filters ... --filters9=filters`
Geben Sie bis zu neun zusätzliche Filterketten an, die mit `--block-list` verwendet werden können.

Zum Beispiel kann beim Komprimieren eines Archivs mit ausführbaren Dateien, gefolgt von Textdateien, der Teil mit den ausführbaren Dateien eine Filterkette mit einem BCJ-Filter verwenden, während der Textteil nur den LZMA2-Filter verwendet.

--filters-help
Zeigt eine Hilfemeldung an, die beschreibt, wie man Presets und benutzerdefinierte Filterketten in den Optionen `--filters` und `--filters1=filters ... --filters9=filters` angibt, und beendet das Programm erfolgreich.

--lzma1[=optionen]
--lzma2[=optionen]
Fügt den Filter LZMA1 oder LZMA2 zur Filterkette hinzu. Diese Filter können nur als letzter Filter in der Kette verwendet werden.

LZMA1 ist ein älterer Filter, der hauptsächlich aus Gründen der Abwärtskompatibilität unterstützt wird, da das ältere .lzma-Dateiformat nur LZMA1 unterstützt. LZMA2 ist eine aktualisierte Version von LZMA1, um einige praktische Probleme von LZMA1 zu beheben. Das .xz-Format verwendet LZMA2 und unterstützt LZMA1 überhaupt nicht. Die Kompressionsgeschwindigkeit und das Verhältnis von LZMA1 und LZMA2 sind praktisch gleich.

LZMA1 und LZMA2 haben den gleichen Satz von Optionen:

preset=preset
Setzt alle LZMA1- oder LZMA2-Optionen auf den angegebenen Wert zurück. Ein Preset besteht aus einer ganzen Zahl, der optional ein einzelner Präfixbuchstaben folgen kann. Die ganze Zahl kann zwischen 0 und 9 liegen, entsprechend den Befehlszeilenoptionen -0 ... -9. Der einzige unterstützte Präfix ist derzeit "e", was --extreme entspricht. Wenn kein Preset angegeben ist, werden die Standardwerte der LZMA1- oder LZMA2-Optionen aus dem Preset 6 übernommen.

dict=größe
Die Wörterbuchgröße (auch als History-Buffer bezeichnet) gibt an, wie viele Bytes der zuvor verarbeiteten, unkomprimierten Daten im Speicher gespeichert werden. Der Algorithmus versucht, sich wiederholende Byte-Sequenzen (Übereinstimmungen) in den unkomprimierten Daten zu finden und diese durch Referenzen auf die Daten im Wörterbuch zu ersetzen. Je größer das Wörterbuch, desto höher ist die Wahrscheinlichkeit, eine Übereinstimmung zu finden. Daher verbessert die Erhöhung der Wörterbuchgröße in der Regel das Kompressionsverhältnis, aber ein Wörterbuch, das größer ist als die unkomprimierte Datei, ist eine Verschwendung von Speicher.

Eine typische Wörterbuchgröße liegt zwischen 64 KB und 64 MB. Das Minimum ist 4 KB. Das Maximum für die Kompression beträgt derzeit 1,5 GB (1536 MB). Der Dekompressor unterstützt bereits Wörterbücher, die um ein Byte kleiner sind als 4 GB, was das Maximum für die LZMA1- und LZMA2-Streamformate ist.

Die Wörterbuchgröße und der Match-Finder (mf) bestimmen zusammen den Speicherbedarf des LZMA1- oder LZMA2-Encoders. Die gleiche (oder größere) Wörterbuchgröße ist für die Dekompression erforderlich, die bei der Kompression verwendet wurde, daher wird der Speicherbedarf des Dekoders durch die bei der Kompression verwendete Wörterbuchgröße bestimmt. Die .xz-Header speichern die Wörterbuchgröße entweder als 2^n oder 2^n + 2^(n-1), daher sind diese Größen für die Kompression etwas bevorzugt. Andere Größen werden auf die nächste höhere Zahl aufgerundet, wenn sie in den .xz-Headern gespeichert werden.

lc=lc
Gibt die Anzahl der Literal-Kontext-Bits an. Das Minimum ist 0 und das Maximum ist 4; der Standardwert ist 3. Darüber hinaus darf die Summe von lc und lp 4 nicht überschreiten.

Alle Bytes, die nicht als Übereinstimmungen codiert werden können, werden als Literale codiert. Das heißt, Literale sind einfach 8-Bit-Bytes, die einzeln codiert werden.

Die Literalc Codierung geht davon aus, dass die lc höchstwertigen Bits des vorherigen unkomprimierten Bytes mit dem nächsten Byte korrelieren. Beispielsweise sind in typischem Englischtext ein Großbuchstabe oft von einem Kleinbuchstaben gefolgt, und ein Kleinbuchstabe ist normalerweise von einem anderen Kleinbuchstaben gefolgt. Im US-ASCII-Zeichensatz sind die drei höchstwertigen Bits 010 für Großbuchstaben und 011 für Kleinbuchstaben. Wenn lc mindestens 3 ist, kann die Literalc Codierung diese Eigenschaft in den unkomprimierten Daten nutzen.

Der Standardwert (3) ist in der Regel gut. Wenn Sie eine maximale Komprimierung wünschen, testen Sie lc=4. Manchmal hilft das ein wenig, und manchmal verschlechtert es die Komprimierung. Wenn es die Komprimierung verschlechtert, testen Sie auch lc=2.

^ p=lp Geben Sie die Anzahl der Literalposition-Bits an. Das Minimum ist 0 und das Maximum ist 4, der Standardwert ist 0.

^ p beeinflusst, welche Art von Ausrichtung in den unkomprimierten Daten bei der Kodierung von Literalen angenommen wird. Weitere Informationen zur Ausrichtung finden Sie unter pb.

^ b=pb Geben Sie die Anzahl der Positionsbits an. Das Minimum ist 0 und das Maximum ist 4; der Standardwert ist 2.

^ b beeinflusst, welche Art von Ausrichtung in den unkomprimierten Daten im Allgemeinen angenommen wird. Der Standardwert bedeutet eine 4-Byte-Ausrichtung (2^pb=2^2=4), was oft eine gute Wahl ist, wenn es keine bessere Vermutung gibt.

Wenn die Ausrichtung bekannt ist, kann das Einstellen von pb entsprechend die Dateigröße geringfügig reduzieren. Zum Beispiel kann das Einstellen von pb=0 bei Textdateien mit einer 1-Byte-Ausrichtung (US-ASCII, ISO-8859-*, UTF-8) die Komprimierung geringfügig verbessern. Für UTF-16-Text ist pb=1 eine gute Wahl. Wenn die Ausrichtung eine ungerade Zahl wie 3 Byte beträgt, ist pb=0 möglicherweise die beste Wahl.

Auch wenn die angenommene Ausrichtung mit pb und lp angepasst werden kann, bevorzugen LZMA1 und LZMA2 immer noch leicht eine 16-Byte-Ausrichtung. Es kann sich lohnen, dies bei der Entwicklung von Dateiformaten zu berücksichtigen, die wahrscheinlich häufig mit LZMA1 oder LZMA2 komprimiert werden.

^ f=mf Der Match-Finder hat einen großen Einfluss auf die Enkodiergeschwindigkeit, den Speicherverbrauch und das Komprimierungsverhältnis. In der Regel sind Hash-Chain-Match-Finder schneller als Binärbaum-Match-Finder. Der Standardwert hängt von der Voreinstellung ab: 0 verwendet hc3, 1–3 verwenden hc4 und die übrigen verwenden bt4.

Die folgenden Match-Finder werden unterstützt. Die Formeln für den Speicherverbrauch sind unten aufgeführt und sind grobe Annäherungen, die der Realität am nächsten kommen, wenn dict eine Zweierpotenz ist.

^ c3 Hash-Chain mit 2- und 3-Byte-Hashing Minimalwert für nice: 3 Speicherverbrauch: dict * 7.5 (wenn dict <= 16 MiB); dict * 5.5 + 64 MiB (wenn dict > 16 MiB)

^ c4 Hash-Chain mit 2-, 3- und 4-Byte-Hashing Minimalwert für nice: 4 Speicherverbrauch: dict * 7.5 (wenn dict <= 32 MiB); dict * 6.5 (wenn dict > 32 MiB)

^ t2 Binärbaum mit 2-Byte-Hashing Minimalwert für nice: 2 Speicherverbrauch: dict * 9.5

^ t3 Binärbaum mit 2- und 3-Byte-Hashing Minimalwert für nice: 3 Speicherverbrauch: dict * 11.5 (wenn dict <= 16 MiB); dict * 9.5 + 64 MiB (wenn dict > 16 MiB)

^ t4 Binärbaum mit 2-, 3- und 4-Byte-Hashing Minimalwert für nice: 4 Speicherverbrauch: dict * 11.5 (wenn dict <= 32 MiB); dict * 10.5 (wenn dict > 32 MiB)

    mode=mode

Komprimierungsmodus gibt die Methode an, mit der die vom Match-Finder erzeugten Daten analysiert werden. Unterstützte Modi sind „fast“ und „normal“. Standardmäßig ist für Voreinstellungen 0–3 „fast“ und für Voreinstellungen 4–9 „normal“.

In der Regel wird „fast“ mit Hash-Chain-Match-Findern und „normal“ mit Binärbaum- Match-Findern verwendet. Dies ist auch das, was die Voreinstellungen bewirken.

    nice=nice

Gibt an, welche Länge als „angemessen“ für einen Match gilt. Sobald ein Match mit mindestens „nice“ Bytes gefunden wurde, stoppt der Algorithmus die Suche nach möglicherweise besseren Matches.

„Nice“ kann 2–273 Bytes betragen. Höhere Werte führen in der Regel zu einem besseren Komprimierungsgrad, jedoch auf Kosten der Geschwindigkeit. Der Standardwert hängt von der Voreinstellung ab.

    depth=depth

Gibt die maximale Suchtiefe im Match-Finder an. Der Standardwert ist der spezielle Wert 0, der bewirkt, dass der Komprimierer eine geeignete Tiefe aus „mf“ und „nice“ bestimmt.

Eine angemessene Tiefe für Hash-Chains liegt zwischen 4 und 100, für Binärbäume zwischen 16 und 1000. Die Verwendung sehr hoher Werte für „depth“ kann den Encoder bei einigen Dateien extrem langsam machen. Vermeiden Sie es, die Tiefe auf über 1000 zu setzen, es sei denn, Sie sind bereit, die Komprimierung zu unterbrechen, falls sie zu lange dauert.

Beim Dekodieren von Rohdatenströmen (--format=raw) benötigt LZMA2 nur die Wörterbuchgröße. LZMA1 benötigt außerdem lc, lp und pb.

    --x86[=optionen]
    --arm[=optionen]
    --armthumb[=optionen]
    --arm64[=optionen]
    --powerpc[=optionen]
    --ia64[=optionen]
    --sparc[=optionen]
    --riscv[=optionen]

Fügt einen Branch/Call/Jump (BCJ)-Filter zur Filterkette hinzu. Diese Filter können nur als nicht-letzter Filter in der Filterkette verwendet werden.

Ein BCJ-Filter konvertiert relative Adressen im Maschinencode in ihre absoluten Gegenstücke. Dies ändert nicht die Größe der Daten, erhöht aber die Redundanz, was LZMA2 helfen kann, eine um 0–15 % kleinere .xz-Datei zu erstellen. BCJ-Filter sind immer reversibel, so dass die Verwendung eines BCJ-Filters für den falschen Datentyp keinen Datenverlust verursacht, obwohl dies die Komprimierungsrate geringfügig verschlechtern kann. BCJ-Filter sind sehr schnell und benötigen nur eine unbedeutende Menge an Speicher.

Diese BCJ-Filter haben bekannte Probleme im Zusammenhang mit der Komprimierungsrate:

Einige Dateitypen, die ausführbaren Code enthalten (z. B. Objektdateien, statische Bibliotheken und Linux-Kernelmodule), haben die Adressen in den Anweisungen mit Füllwerten gefüllt. Diese BCJ-Filter führen dennoch die Adresskonvertierung durch, was die Komprimierung bei diesen Dateien verschlechtert.

Wenn ein BCJ-Filter auf ein Archiv angewendet wird, kann dies die Komprimierungsrate verschlechtern, als wenn kein BCJ-Filter verwendet würde. Wenn es beispielsweise ähnliche oder sogar identische ausführbare Dateien gibt, führt das Filtern wahrscheinlich dazu, dass die Dateien weniger ähnlich sind, wodurch die Komprimierung schlechter wird. Der Inhalt nicht-ausführbarer Dateien im selben Archiv kann ebenfalls eine Rolle spielen. In der Praxis muss man es mit und ohne einen BCJ-Filter ausprobieren, um zu sehen, was in jeder Situation besser ist.

Verschiedene Befehlssätze haben unterschiedliche Ausrichtungen: Die ausführbare Datei muss im Eingabedatenstrom an ein Vielfaches dieses Wertes ausgerichtet sein, damit der Filter funktioniert.

Filter  Ausrichtung Hinweise
x86 1   32-Bit oder 64-Bit x86
ARM 4
ARM-Thumb   2
ARM64   4   Eine 4096-Byte-Ausrichtung ist optimal
PowerPC 4   Nur Big-Endian
IA-64   16  Itanium
SPARC   4
RISC-V  2

Da die BCJ-gefilterten Daten normalerweise mit LZMA2 komprimiert werden, kann das Komprimierungsverhältnis leicht verbessert werden, wenn die LZMA2-Optionen an die Ausrichtung des ausgewählten BCJ-Filters angepasst werden. Beispiele:

Der IA-64-Filter hat eine 16-Byte-Ausrichtung, daher ist pb=4, lp=4, lc=0 mit LZMA2 (2^4=16) gut.

RISC-V-Code hat eine 2-Byte- oder 4-Byte-Ausrichtung, je nachdem, ob die Datei 16-Bit-komprimierte Anweisungen (die C-Erweiterung) enthält. Wenn 16-Bit-Anweisungen verwendet werden, ist pb=2, lp=1, lc=3 oder pb=1, lp=1, lc=3 gut. Wenn keine 16-Bit-Anweisungen vorhanden sind, ist pb=2, lp=2, lc=2 die beste Option. `readelf -h` kann verwendet werden, um zu überprüfen, ob „RVC“ in der Zeile „Flags“ angezeigt wird.

ARM64 ist immer 4-Byte-ausgerichtet, daher ist pb=2, lp=2, lc=2 die beste Option.

Der x86-Filter ist eine Ausnahme. Es ist normalerweise ratsam, bei der Komprimierung von x86-Ausführbaren Dateien bei den Standardeinstellungen von LZMA2 zu bleiben (pb=2, lp=0, lc=3).

Alle BCJ-Filter unterstützen die gleichen Optionen:

start=offset

Gibt den Start-Offset an, der bei der Umrechnung zwischen relativen und absoluten Adressen verwendet wird. Der Offset muss ein Vielfaches der Ausrichtung des Filters sein (siehe die obige Tabelle). Der Standardwert ist Null. In der Praxis ist der Standardwert gut; das Angeben eines benutzerdefinierten Offsets ist fast nie nützlich.

--delta[=optionen]

Fügt den Delta-Filter der Filterkette hinzu. Der Delta-Filter kann nur als nicht-letzter Filter in der Filterkette verwendet werden.

Derzeit wird nur die einfache Byte-weise Delta-Berechnung unterstützt. Dies kann bei der Komprimierung beispielsweise unkomprimierter Bitmap-Bilder oder unkomprimierter PCM-Audiodateien nützlich sein. Spezielle Algorithmen können jedoch deutlich bessere Ergebnisse liefern als Delta + LZMA2. Dies gilt insbesondere für Audio, das beispielsweise mit flac(1) schneller und besser komprimiert wird.

Unterstützte Optionen:

dist=distanz

Gibt die Distanz der Delta-Berechnung in Bytes an. Die Distanz muss zwischen 1 und 256 liegen. Der Standardwert ist 1.

Für Beispiel, mit dist=2 und einer acht Byte langen Eingabe A1 B1 A2 B3 A3 B5 A4 B7, wäre die Ausgabe A1 B1 01 02 01 02 01 02.

Andere Optionen

-q, --quiet

Unterdrückt Warnungen und Hinweise. Geben Sie dies zweimal an, um auch Fehler zu unterdrücken. Diese Option hat keine Auswirkung auf den Exit-Status. Das heißt, selbst wenn eine Warnung unterdrückt wurde, wird der Exit-Status, der eine Warnung anzeigt, weiterhin verwendet.

-v, --verbose

Ausführlicher Modus. Wenn die Standardausgabe an ein Terminal angeschlossen ist, zeigt xz eine Fortschrittsanzeige an. Das zweimalige Angeben von --verbose liefert noch ausführlichere Ausgaben.

Die Fortschrittsanzeige zeigt die folgenden Informationen:

Der Abschluss in Prozent wird angezeigt, wenn die Größe der Eingabedatei bekannt ist. Das heißt, der Prozentsatz kann nicht in Pipelines angezeigt werden.

Menge der erzeugten (beim Komprimieren) oder verbrauchten (beim Dekomprimieren) komprimierten Daten.

Menge der verbrauchten (beim Komprimieren) oder erzeugten (beim Dekomprimieren) unkomprimierten Daten.

Kompressionsverhältnis, das berechnet wird, indem die Menge der bisher verarbeiteten komprimierten Daten durch die Menge der bisher verarbeiteten unkomprimierten Daten geteilt wird.

Komprimierungs- oder Dekomprimierungsgeschwindigkeit. Dies wird als Menge der verbrauchten (Komprimierung) oder erzeugten (Dekomprimierung) unkomprimierten Daten pro Sekunde gemessen. Es wird angezeigt, nachdem einige Sekunden vergangen sind, seit xz mit der Verarbeitung der Datei begonnen hat.

Verstrichene Zeit im Format M:SS oder H:MM:SS.

Die geschätzte Restzeit wird nur angezeigt, wenn die Größe der Eingabedatei bekannt ist und seit dem Start der Verarbeitung durch xz einige Sekunden vergangen sind. Die Zeit wird in einem weniger präzisen Format angezeigt, das niemals Doppelpunkte enthält, z. B. 2 Min. 30 Sek.

Wenn die Standardfehlerausgabe kein Terminal ist, gibt --verbose xz den Dateinamen, die komprimierte Größe, die unkomprimierte Größe, das Kompressionsverhältnis und möglicherweise auch die Geschwindigkeit und die verstrichene Zeit in einer einzigen Zeile in die Standardfehlerausgabe aus, nachdem die Datei komprimiert oder dekomprimiert wurde. Die Geschwindigkeit und die verstrichene Zeit werden nur dann angezeigt, wenn der Vorgang mindestens einige Sekunden gedauert hat. Wenn der Vorgang nicht abgeschlossen wurde, z. B. aufgrund einer Unterbrechung durch den Benutzer, wird auch der Abschlussgrad ausgegeben, wenn die Größe der Eingabedatei bekannt ist.

-Q, --no-warn
Setzt den Exit-Status nicht auf 2, selbst wenn eine Warnung festgestellt wurde. Diese Option hat keinen Einfluss auf die Ausführlichkeitsstufe, sodass sowohl --quiet als auch --no-warn verwendet werden müssen, um keine Warnungen anzuzeigen und den Exit-Status nicht zu ändern.

--robot
Gibt Nachrichten in einem maschinenlesbaren Format aus. Dies soll die Erstellung von Frontends erleichtern, die xz anstelle von liblzma verwenden möchten, was bei verschiedenen Skripten der Fall sein kann. Die Ausgabe mit dieser Option ist für zukünftige xz-Versionen gedacht. Siehe Abschnitt ROBOT-MODUS für Details.

--info-memory
Zeigt in einem für Menschen lesbaren Format an, wie viel physischen Speicher (RAM) und wie viele Prozessorthreads xz für das System annimmt, und zeigt die Speicherbegrenzungen für die Komprimierung und Dekomprimierung an und beendet sich dann erfolgreich.

-h, --help
Zeigt eine Hilfemeldung an, die die am häufigsten verwendeten Optionen beschreibt, und beendet sich dann erfolgreich.

-H, --long-help
Zeigt eine Hilfemeldung an, die alle Funktionen von xz beschreibt, und beendet sich dann erfolgreich

-V, --version
Zeigt die Versionsnummer von xz und liblzma in einem für Menschen lesbaren Format an. Um eine maschinenlesbare Ausgabe zu erhalten, geben Sie --robot vor --version an.

ROBOT-MODUS

Der Robot-Modus wird mit der Option --robot aktiviert. Dadurch wird die Ausgabe von xz für andere Programme leichter lesbar. Derzeit wird --robot nur zusammen mit --list, --filters-help, --info-memory und --version unterstützt. In Zukunft wird er für die Komprimierung und Dekomprimierung unterstützt.

Listenmodus

xz --robot --list verwendet tabulatorgetrennte Ausgaben. Die erste Spalte jeder Zeile enthält eine Zeichenkette, die den Typ der auf dieser Zeile gefundenen Informationen angibt:

name   Dies ist immer die erste Zeile beim Auflisten einer Datei. Die zweite Spalte in der Zeile
ist der Dateiname.

file   Diese Zeile enthält allgemeine Informationen über die .xz-Datei. Diese Zeile wird immer nach der Name-Zeile ausgegeben.

stream Dieser Zeilentyp wird nur verwendet, wenn --verbose angegeben wurde. Es gibt so viele Stream-Zeilen, wie es Streams in der .xz-Datei gibt.

block Dieser Zeilentyp wird nur verwendet, wenn --verbose zweimal angegeben wurde. Es gibt so viele Block-Zeilen, wie es Blöcke in der .xz-Datei gibt. Die Block-Zeilen werden nach allen Stream-Zeilen angezeigt; verschiedene Zeilentypen werden nicht gemischt.

summary

Dieser Zeilentyp wird nur verwendet, wenn --verbose zweimal angegeben wurde. Diese Zeile wird nach allen Block-Zeilen ausgegeben. Wie die Datei-Zeile enthält die Zusammenfassungszeile allgemeine Informationen über die .xz-Datei.

totals Diese Zeile ist immer die allerletzte Zeile der Listenausgabe. Sie zeigt die Gesamtanzahl und -größen.

Die Spalten der Datei-Zeilen: ### Anzahl der Streams in der Datei ### Gesamtzahl der Blöcke in den Streams ### Komprimierte Größe der Datei ### Unkomprimierte Größe der Datei ### Kompressionsverhältnis, zum Beispiel 0,123. Wenn das Verhältnis über 9,999 liegt, werden drei Bindestriche (---) anstelle des Verhältnisses angezeigt. ### Kommagetrennte Liste der Integritätsprüfungsnamen. Für die bekannten Prüftypen werden die folgenden Zeichenfolgen verwendet: None, CRC32, CRC64 und SHA-256. Für unbekannte Prüftypen wird Unknown-N verwendet, wobei N die Prüfungs-ID als Dezimalzahl ist (ein- oder zweistellig). ### Gesamtgröße des Stream-Füllmaterials in der Datei

Die Spalten der Stream-Zeilen: ### Streamnummer (der erste Stream ist 1) ### Anzahl der Blöcke im Stream ### Komprimierter Startoffset ### Unkomprimierter Startoffset ### Komprimierte Größe (ohne Stream-Füllmaterial) ### Unkomprimierte Größe ### Kompressionsverhältnis ### Name der Integritätsprüfung Größe des Stream-Füllmaterials

Die Spalten der Block-Zeilen: ### Nummer des Streams, der diesen Block enthält ### Blocknummer relativ zum Anfang des Streams (der erste Block ist 1) ### Blocknummer relativ zum Anfang der Datei ### Komprimierter Startoffset relativ zum Anfang der Datei ### Unkomprimierter Startoffset relativ zum Anfang der Datei ### Gesamt komprimierte Größe des Blocks (einschließlich Header) ### Unkomprimierte Größe ### Kompressionsverhältnis Name der Integritätsprüfung

Wenn --verbose zweimal angegeben wurde, werden zusätzliche Spalten in den Block-Zeilen angezeigt. Diese werden nicht mit einem einzelnen --verbose angezeigt, da das Abrufen dieser Informationen viele Dateioperationen erfordert und daher langsam sein kann: Wert der Integritätsprüfung in hexadezimaler Form Block-Header-Größe Block-Flags: c zeigt an, dass die komprimierte Größe vorhanden ist, und u zeigt an, dass die unkomprimierte Größe vorhanden ist. Wenn das Flag nicht gesetzt ist, wird ein Bindestrich (-) angezeigt, um die Stringlänge konstant zu halten. In Zukunft können am Ende der Zeichenfolge neue Flags hinzugefügt werden. Größe der tatsächlichen komprimierten Daten im Block (dies schließt den Block-Header, das Block-Füllmaterial und die Prüffelder aus) Anzahl der Bytes, die zum Dekomprimieren dieses Blocks mit dieser xz-Version benötigt werden Filterkette. Beachten Sie, dass die meisten Optionen, die zur Komprimierungszeit verwendet werden, nicht bekannt sind, da nur die Optionen, die für die Dekomprimierung benötigt werden, in den .xz-Headern gespeichert sind.

Die Spalten der Zusammenfassung: ### Speichermenge (in Byte), die zum Dekomprimieren dieser Datei mit dieser xz-Version benötigt wird Ja oder Nein, je nachdem, ob alle Block-Header sowohl die komprimierte Größe als auch die unkomprimierte Größe enthalten. Seit xz 5.1.2alpha: ### Minimale xz-Version, die zum Dekomprimieren der Datei erforderlich ist

Die Spalten der Gesamtzahl-Zeile: ### Anzahl der Streams ### Anzahl der Blöcke ### Komprimierte Größe ### Unkomprimierte Größe ### Durchschnittliches Komprimierungsverhältnis ### Kommagetrennte Liste der Integritätsprüfungsnamen, die in den Dateien vorhanden waren ### Stream-Padding-Größe ### Anzahl der Dateien. Dies dient dazu, die Reihenfolge der vorherigen Spalten mit der der Dateizeilen abzugleichen.

Wenn --verbose zweimal angegeben wurde, werden zusätzliche Spalten in der Gesamtzahl-Zeile angezeigt: Maximale Speichermenge (in Byte), die zum Dekomprimieren der Dateien mit dieser xz-Version benötigt wird Ja oder Nein, je nachdem, ob alle Block-Header sowohl die komprimierte Größe als auch die unkomprimierte Größe enthalten. Seit xz 5.1.2alpha: Minimale xz-Version, die zum Dekomprimieren der Datei erforderlich ist

Zukünftige Versionen können neue Zeilentypen hinzufügen, und den vorhandenen Zeilentypen können neue Spalten hinzugefügt werden, aber die vorhandenen Spalten werden nicht geändert.

Filter-Hilfe

xz --robot --filters-help gibt die unterstützten Filter im folgenden Format aus:

filter:option=<value>,option=<value>...

filter Name des Filters

option Name einer filterspezifischen Option

value Numerische Wertebereiche werden als <min-max> dargestellt. Zeichenkettenwerte werden in < > dargestellt und durch | getrennt.

Jeder Filter wird in einer eigenen Zeile ausgegeben.

###    Informationen zum Speicherlimit
xz --robot --info-memory gibt eine einzelne Zeile mit mehreren durch Tab getrennten Spalten aus:

###          Gesamte Speichermenge (RAM) in Byte.

###          Speichernutzungslimit für die Komprimierung in Byte (--memlimit-compress). Ein spezieller Wert von 0 gibt die Standardeinstellung an, die im Single-Thread-Modus der gleichen wie keine Begrenzung entspricht.

###          Speichernutzungslimit für die Dekomprimierung in Byte (--memlimit-decompress). Ein spezieller Wert von 0 gibt die Standardeinstellung an, die im Single-Thread-Modus der gleichen wie keine Begrenzung entspricht.

###          Seit xz 5.3.4alpha: Speichernutzung für die Multithread-Dekomprimierung in Byte (--memlimit-mt-decompress). Dies ist niemals Null, da ein systemspezifischer Standardwert verwendet wird, der in Spalte 5 angezeigt wird, wenn kein Limit explizit angegeben wurde. Dies ist auch niemals größer als der Wert in Spalte 3, selbst wenn ein größerer Wert mit --memlimit-mt-decompress angegeben wurde.

### Seit xz 5.3.4alpha: Ein systemspezifisches Standardlimit für die Speichernutzung, das verwendet wird, um die Anzahl der Threads bei der Komprimierung mit einer automatischen Anzahl von Threads (--threads=0) und ohne angegebenes Speicherverwendungslimit (--memlimit-compress) zu begrenzen. Dies wird auch als Standardwert für --memlimit-mt-decompress verwendet.

### Seit xz 5.3.4alpha: Anzahl der verfügbaren Prozessoren-Threads.

In Zukunft kann die Ausgabe von xz --robot --info-memory mehr Spalten haben, aber niemals mehr als eine einzelne Zeile.

Version

xz --robot --version gibt die Versionsnummer von xz und liblzma in folgendem Format aus:

XZ_VERSION=XYYYZZZS
LIBLZMA_VERSION=XYYYZZZS

X Major-Version.

YYY Nebenversion. Gerade Zahlen sind stabil. Ungerade Zahlen sind Alpha- oder Beta-Versionen.

ZZZ Patch-Level für stabile Versionen oder nur ein Zähler für Entwicklungsversionen.

S Stabilität. 0 ist Alpha, 1 ist Beta und 2 ist stabil. S sollte immer 2 sein, wenn YYY gerade ist.

XYYYZZZS sind in beiden Zeilen gleich, wenn xz und liblzma aus derselben XZ Utils-Version stammen.

Beispiele: 4.999.9beta ist 49990091 und 5.0.0 ist 50000002.

EXIT-STATUS

0 Alles ist in Ordnung.

1 Ein Fehler ist aufgetreten.

2 Etwas, das eine Warnung wert ist, ist aufgetreten, aber es sind keine tatsächlichen Fehler aufgetreten.

Auf der Standardfehlerausgabe ausgegebene Hinweise (keine Warnungen oder Fehler) haben keinen Einfluss auf den Exit-Status.

UMGEBUNG

xz analysiert durch Leerzeichen getrennte Optionslisten aus den Umgebungsvariablen XZ_DEFAULTS und XZ_OPT in dieser Reihenfolge, bevor die Optionen aus der Befehlszeile analysiert werden. Beachten Sie, dass nur Optionen aus den Umgebungsvariablen analysiert werden; alle Nicht-Optionen werden stillschweigend ignoriert. Die Analyse erfolgt mit getopt_long(3), das auch für die Befehlszeilenargumente verwendet wird.

Warnung: Durch das Setzen dieser Umgebungsvariablen werden effektiv Programme und Skripte geändert, die xz ausführen. In den meisten Fällen ist es sicher, Speicherverwendungslimits, die Anzahl der Threads und Komprimierungsoptionen über die Umgebungsvariablen festzulegen. Einige Optionen können jedoch Skripte beeinträchtigen. Ein offensichtliches Beispiel ist --help, wodurch xz den Hilfetext anzeigt, anstatt eine Datei zu komprimieren oder zu dekomprimieren. Subtilere Beispiele sind --quiet und --verbose. In vielen Fällen funktioniert es gut, die Fortschrittsanzeige mit --verbose zu aktivieren, aber in einigen Situationen verursachen die zusätzlichen Nachrichten Probleme. Das Ausführlichkeitslevel beeinflusst auch das Verhalten von --list.

XZ_DEFAULTS

Benutzerspezifische oder systemweite Standardoptionen. Dies wird normalerweise in einem Shell-Initialisierungsskript festgelegt, um den Speicherverwendungslimiter von xz standardmäßig zu aktivieren oder die Standardanzahl der Threads festzulegen. Mit Ausnahme von Shell-Initialisierungsskripten und ähnlichen Sonderfällen sollten Skripte XZ_DEFAULTS niemals setzen oder aufheben.

XZ_OPT Dies dient dazu, Optionen an xz zu übergeben, wenn es nicht möglich ist, die Optionen direkt über die xz-Befehlszeile festzulegen. Dies ist der Fall, wenn xz von einem Skript oder Tool ausgeführt wird, z. B. GNU [tar]({filename}../../tar)(1).

XZ_OPT=-2v tar caf foo.tar.xz foo

Skripte können XZ_OPT verwenden, um beispielsweise skriptspezifische Standardkomprimierungsoptionen festzulegen. Es wird dennoch empfohlen, den Benutzern zu ermöglichen, XZ_OPT zu überschreiben, falls dies sinnvoll ist. In sh(1)-Skripten kann beispielsweise Folgendes verwendet werden:

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

LZMA-KOMPATIBILITÄT

Die Befehlszeilensyntax von xz ist praktisch ein Supersatz von lzma, unlzma und lzcat, wie sie in LZMA Utils 4.32.x zu finden sind. In den meisten Fällen ist es möglich, LZMA Utils durch XZ Utils zu ersetzen, ohne bestehende Skripte zu beeinträchtigen. Es gibt jedoch einige Inkompatibilitäten, die gelegentlich Probleme verursachen können.

Komprimierungs-Preset-Stufen

Die Nummerierung der Komprimierungs-Preset-Stufen ist bei xz und LZMA Utils nicht identisch. Der wichtigste Unterschied ist die Art und Weise, wie Wörterbuchgrößen verschiedenen Presets zugeordnet werden. Die Wörterbuchgröße entspricht ungefähr dem Speicherbedarf des Dekompressors.

Stufe 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

Die Unterschiede in der Wörterbuchgröße beeinflussen auch den Speicherbedarf des Kompressors, aber es gibt noch andere Unterschiede zwischen LZMA Utils und XZ Utils, die den Unterschied noch größer machen:

Stufe 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

Die Standard-Preset-Stufe in LZMA Utils ist -7, während sie in XZ Utils -6 ist, sodass beide standardmäßig ein 8-MiB-Wörterbuch verwenden.

Gestreamte vs. nicht gestreamte .lzma-Dateien

Die Größe der dekomprimierten Datei kann im .lzma-Header gespeichert werden. LZMA Utils macht dies bei der Komprimierung normaler Dateien. Die Alternative besteht darin, anzugeben, dass die Größe der dekomprimierten Datei unbekannt ist, und einen End-of-Payload-Marker zu verwenden, um anzugeben, wo der Dekompressor anhalten soll. LZMA Utils verwendet diese Methode, wenn die Größe der dekomprimierten Datei nicht bekannt ist, was beispielsweise bei Pipes der Fall ist.

xz unterstützt das Dekomprimieren von .lzma-Dateien mit oder ohne End-of-Payload-Marker, aber alle .lzma-Dateien, die mit xz erstellt werden, verwenden den End-of-Payload-Marker und haben im .lzma-Header angegeben, dass die Größe der dekomprimierten Datei unbekannt ist. Dies kann in einigen ungewöhnlichen Situationen ein Problem darstellen. Beispielsweise funktioniert ein .lzma-Dekompressor in einem eingebetteten Gerät möglicherweise nur mit Dateien, die eine bekannte Größe der dekomprimierten Datei haben. Wenn dieses Problem auftritt, müssen Sie LZMA Utils oder LZMA SDK verwenden, um .lzma-Dateien mit einer bekannten Größe der dekomprimierten Datei zu erstellen.

Nicht unterstützte .lzma-Dateien

Das .lzma-Format erlaubt lc-Werte bis zu 8 und lp-Werte bis zu 4. LZMA Utils kann Dateien mit beliebigen lc- und lp-Werten dekomprimieren, erstellt aber immer Dateien mit lc=3 und lp=0. Das Erstellen von Dateien mit anderen lc- und lp-Werten ist mit xz und mit dem LZMA SDK möglich.

Die Implementierung des LZMA1-Filters in liblzma erfordert, dass die Summe von lc und lp 4 nicht überschreiten darf. Daher können .lzma-Dateien, die diese Einschränkung überschreiten, nicht mit xz dekomprimiert werden.

LZMA Utils erstellt nur .lzma-Dateien, die eine Wörterbuchgröße von 2^n (eine Zweierpotenz) haben, akzeptiert aber Dateien mit beliebiger Wörterbuchgröße. liblzma akzeptiert nur .lzma-Dateien, die eine Wörterbuchgröße von 2^n oder 2^n + 2^(n-1) haben. Dies dient dazu, Fehlalarme beim Erkennen von .lzma-Dateien zu reduzieren.

Diese Einschränkungen sollten in der Praxis kein Problem darstellen, da praktisch alle .lzma-Dateien mit Einstellungen komprimiert wurden, die liblzma akzeptiert.

Nachgestellter Müll

Beim Dekomprimieren ignoriert LZMA Utils stillschweigend alles nach dem ersten .lzma-Stream. In den meisten Fällen ist dies ein Fehler. Dies bedeutet auch, dass LZMA Utils das Dekomprimieren von verketteten .lzma-Dateien nicht unterstützt.

Wenn nach dem ersten .lzma-Stream Daten vorhanden sind, betrachtet xz die Datei als beschädigt, es sei denn, --single-stream wurde verwendet. Dies kann obskure Skripte beschädigen, die davon ausgegangen sind, dass nachgestellter Müll ignoriert wird.

HINWEISE

Die komprimierte Ausgabe kann variieren

Die genaue komprimierte Ausgabe, die aus derselben unkomprimierten Eingabedatei erzeugt wird, kann sich zwischen verschiedenen Versionen von XZ Utils unterscheiden, selbst wenn die Komprimierungsoptionen identisch sind. Dies liegt daran, dass der Encoder verbessert werden kann (schneller oder bessere Komprimierung), ohne das Dateiformat zu beeinträchtigen. Die Ausgabe kann sich selbst zwischen verschiedenen Builds derselben Version von XZ Utils unterscheiden, wenn verschiedene Build-Optionen verwendet werden.

Das bedeutet, dass, sobald --rsyncable implementiert wurde, die resultierenden Dateien nicht unbedingt rsyncfähig sind, es sei denn, sowohl die alte als auch die neue Datei wurden mit derselben xz-Version komprimiert. Dieses Problem kann behoben werden, wenn ein Teil der Encoder-Implementierung eingefroren wird, um eine stabile, rsyncfähige Ausgabe über xz-Versionen hinweg zu gewährleisten.

Eingebettete .xz-Dekomprimierer

Eingebettete .xz-Dekomprimierer-Implementierungen wie XZ Embedded unterstützen nicht unbedingt Dateien, die mit Integritätsprüftypen erstellt wurden, die nicht "none" und "crc32" sind. Da der Standard --check=crc64 ist, müssen Sie --check=none oder --check=crc32 verwenden, wenn Sie Dateien für eingebettete Systeme erstellen.

Außerhalb eingebetteter Systeme unterstützen alle .xz-Format-Dekomprimierer alle Prüftypen oder können die Datei zumindest ohne Überprüfung der Integritätsprüfung dekomprimieren, wenn die jeweilige Prüfung nicht unterstützt wird.

XZ Embedded unterstützt BCJ-Filter, aber nur mit dem Standard-Startoffset.

BEISPIELE

Grundlagen

Komprimieren Sie die Datei foo in foo.xz mit der Standardkomprimierungsstufe (-6) und entfernen Sie foo, wenn die Komprimierung erfolgreich ist:

xz foo

Dekomprimieren Sie bar.xz in bar und entfernen Sie bar.xz nicht, auch wenn die Dekomprimierung erfolgreich ist:

xz -dk bar.xz

Erstellen Sie baz.tar.xz mit der Voreinstellung -4e (-4 --extreme), die langsamer ist als die Standardeinstellung -6, aber weniger Speicher für die Komprimierung und Dekomprimierung benötigt (48 MiB bzw. 5 MiB):

tar cf - baz | xz -4e > baz.tar.xz

Eine Mischung aus komprimierten und unkomprimierten Dateien kann mit einem einzigen Befehl in die Standardausgabe dekomprimiert werden:

xz -dcf a.txt b.txt.xz c.txt d.txt.lzma > abcd.txt

Parallele Komprimierung vieler Dateien

Unter GNU und BSD können find(1) und xargs(1) verwendet werden, um die Komprimierung vieler Dateien zu parallelisieren:

find . -type f \! -name '*.xz' -print0 \
| xargs -0r -P4 -n16 xz -T1

Die Option -P von xargs(1) setzt die Anzahl der parallelen xz-Prozesse. Der beste Wert für die Option -n hängt davon ab, wie viele Dateien komprimiert werden sollen. Wenn es nur ein paar Dateien gibt, sollte der Wert wahrscheinlich 1 sein; bei Zehntausenden von Dateien können 100 oder sogar mehr angemessen sein, um die Anzahl der xz-Prozesse zu reduzieren, die xargs(1) letztendlich erstellt.

Die Option -T1 für xz zwingt es in den Single-Thread-Modus, da xargs(1) verwendet wird, um den Grad der Parallelisierung zu steuern.

Roboter-Modus

Berechnen Sie, wie viele Bytes insgesamt nach dem Komprimieren mehrerer Dateien gespart wurden:

xz --robot --list *.xz | awk '/^totals/{print $5-$4}'

Ein Skript kann feststellen, ob eine neue xz-Version verwendet wird. Das folgende sh(1)-Skript prüft, ob die Versionsnummer des xz-Tools mindestens 5.0.0 beträgt. Diese Methode ist mit alten Beta-Versionen kompatibel, die die Option --robot nicht unterstützten:

if ! eval "$(xz --robot --version 2> /dev/null)" ||
[ "$XZ_VERSION" -lt 50000002 ]; then
echo "Ihr xz ist zu alt."
fi
unset XZ_VERSION LIBLZMA_VERSION

Legen Sie eine Speicherbegrenzung für die Dekomprimierung mit XZ_OPT fest, aber erhöhen Sie sie nicht, wenn bereits eine Begrenzung festgelegt wurde:

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

Benutzerdefinierte Kompressor-Filterketten

Der einfachste Anwendungsfall für benutzerdefinierte Filterketten ist die Anpassung einer LZMA2-Voreinstellung. Dies kann nützlich sein, da die Voreinstellungen nur eine Teilmenge der potenziell nützlichen Kombinationen von Komprimierungseinstellungen abdecken.

Die Spalten CompCPU der Tabellen aus den Beschreibungen der Optionen -0 ... -9 und --extreme sind nützlich, wenn Sie LZMA2-Voreinstellungen anpassen. Hier sind die relevanten Teile, die aus diesen beiden Tabellen gesammelt wurden:

Voreinstellung CompCPU -0 0 -1 1 -2 2 -3 3 -4 4 -5 5 -6 6 -5e 7 -6e 8

Wenn Sie wissen, dass eine Datei ein etwas großes Wörterbuch (z. B. 32 MiB) benötigt, um gut komprimiert zu werden, aber Sie sie schneller komprimieren möchten, als es xz -8 tun würde, kann eine Voreinstellung mit einem niedrigen Wert für CompCPU (z. B. 1) so geändert werden, dass sie ein größeres Wörterbuch verwendet:

xz --lzma2=preset=1,dict=32MiB foo.tar

Mit bestimmten Dateien kann der obige Befehl schneller sein als xz -6 und gleichzeitig deutlich besser komprimieren. Es muss jedoch betont werden, dass nur einige Dateien von einem großen Wörterbuch profitieren, während gleichzeitig ein geringer CompCPU-Wert beibehalten wird. Die offensichtlichste Situation, in der ein großes Wörterbuch sehr hilfreich sein kann, ist ein Archiv, das sehr ähnliche Dateien mit einer Größe von mindestens einigen Megabyte enthält. Die Wörterbuchgröße muss deutlich größer sein als jede einzelne Datei, damit LZMA2 die Ähnlichkeiten zwischen den aufeinanderfolgenden Dateien vollständig ausnutzen kann.

Wenn ein sehr hoher Speicherverbrauch für den Kompressor und Decompressor akzeptabel ist und die zu komprimierende Datei mindestens mehrere hundert Megabyte groß ist, kann es sinnvoll sein, ein noch größeres Wörterbuch als die 64 MiB zu verwenden, die xz -9 verwenden würde:

xz -vv --lzma2=dict=192MiB big_foo.tar

Die Verwendung von -vv (--verbose --verbose) wie im obigen Beispiel kann nützlich sein, um die Speicheranforderungen des Kompressors und Decompressors anzuzeigen. Denken Sie daran, dass die Verwendung eines Wörterbuchs, das größer als die Größe der unkomprimierten Datei ist, Speicher verschwendet, daher ist der obige Befehl für kleine Dateien nicht nützlich.

Manchmal ist die Komprimierungszeit nicht wichtig, aber der Speicherverbrauch des Decompressors muss gering gehalten werden, zum Beispiel, um die Dekomprimierung der Datei auf einem eingebetteten System zu ermöglichen. Der folgende Befehl verwendet -6e (-6 --extreme) als Basis und setzt das Wörterbuch auf nur 64 KiB. Die resultierende Datei kann mit XZ Embedded mit etwa 100 KiB Speicher dekomprimiert werden (daher --check=crc32).

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

Wenn Sie so viele Bytes wie möglich herausquetschen möchten, kann die Anpassung der Anzahl der Literal-Kontext-Bits (lc) und der Anzahl der Positions-Bits (pb) manchmal helfen. Die Anpassung der Anzahl der Literal-Positions-Bits (lp) kann ebenfalls helfen, aber normalerweise sind lc und pb wichtiger. Beispielsweise könnte bei einem Archiv mit Quellcode, das hauptsächlich US-ASCII-Text enthält, etwas wie das folgende eine geringfügig (wie 0,1 %) kleinere Datei als xz -6e ergeben (versuchen Sie auch ohne lc=4):

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

Die Verwendung eines anderen Filters zusammen mit LZMA2 kann die Komprimierung bei bestimmten Dateitypen verbessern. Zum Beispiel, um eine x86-32- oder x86-64-Shared Library mit dem x86 BCJ-Filter zu komprimieren:

xz --x86 --lzma2 libfoo.so

Beachten Sie, dass die Reihenfolge der Filteroptionen wichtig ist. Wenn --x86 nach --lzma2 angegeben wird, gibt xz einen Fehler aus, da nach LZMA2 kein Filter vorhanden sein darf und außerdem der x86 BCJ-Filter nicht als letzter Filter in der Kette verwendet werden kann.

Der Delta-Filter zusammen mit LZMA2 kann bei Bitmap-Bildern gute Ergebnisse liefern. Er sollte normalerweise besser sein als PNG, das ein paar fortschrittlichere Filter als ein einfaches Delta hat, aber Deflate für die eigentliche Komprimierung verwendet.

Das Bild muss im unkomprimierten Format gespeichert werden, z. B. als unkomprimiertes TIFF. Der Distanzparameter des Delta-Filters wird so eingestellt, dass er der Anzahl der Bytes pro Pixel im Bild entspricht. Zum Beispiel benötigt ein 24-Bit-RGB-Bitmap dist=3, und es ist auch gut, pb=0 an LZMA2 zu übergeben, um die dreifache Byte-Ausrichtung zu berücksichtigen.

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

Wenn mehrere Bilder in einem einzigen Archiv gespeichert wurden (z. B. in einer .tar-Datei), funktioniert der Delta-Filter auch dort, solange alle Bilder die gleiche Anzahl von Bytes pro Pixel haben.

SIEHE AUCH

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

XZ-Dienstprogramme: [https://tukaani.org/xz/]
XZ Embedded: [https://tukaani.org/xz/embedded.html]
LZMA SDK: [https://7-zip.org/sdk.html]

SYNTAX

BEFEHLSALIASSE

BESCHREIBUNG

Speichernutzung

Verkettung und Auffüllen mit .xz-Dateien

OPTIONEN

Ganzzahlige Suffixe und spezielle Werte

Betriebsmodus

Operationsmodifikatoren

Grundlegende Dateiformat- und Komprimierungsoptionen

Benutzerdefinierte Kompressor-Filterketten

Andere Optionen

ROBOT-MODUS

Listenmodus

Filter-Hilfe

Version

EXIT-STATUS

UMGEBUNG

LZMA-KOMPATIBILITÄT

Komprimierungs-Preset-Stufen

Gestreamte vs. nicht gestreamte .lzma-Dateien

Nicht unterstützte .lzma-Dateien

Nachgestellter Müll

HINWEISE

Die komprimierte Ausgabe kann variieren

Eingebettete .xz-Dekomprimierer

BEISPIELE

Grundlagen

Parallele Komprimierung vieler Dateien

Roboter-Modus

Benutzerdefinierte Kompressor-Filterketten

SIEHE AUCH

bzip2

gzip

lz

tar

unzip

zip

zlib

cpio