xz-utils (5.4.5)

Browse
Build Log
Usage
Build Options
Dependencies
Source
Versions
Version Info
(root)/
share/
man/
de/
man1/
xz.1
XZ(1) XZ-Dienstprogramme XZ(1)

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

ÜBERSICHT
xz [Option…] [Datei…]

BEFEHLSALIASE
unxz ist gleichbedeutend mit xz --decompress.
xzcat ist gleichbedeutend mit xz --decompress --stdout.
lzma ist gleichbedeutend mit xz --format=lzma.
unlzma ist gleichbedeutend mit xz --format=lzma --decompress.
lzcat ist gleichbedeutend mit xz --format=lzma --decompress --stdout.

Wenn Sie Skripte schreiben, die Dateien dekomprimieren, sollten Sie stets den Namen xz mit den entsprechenden Ar‐
gumenten (xz -d oder xz -dc) anstelle der Namen unxz und xzcat verwenden.

BESCHREIBUNG
xz ist ein Allzweckwerkzeug zur Datenkompression, dessen Befehlszeilensyntax denen von gzip(1) und bzip2(1)
ähnelt. Das native Dateiformat ist das .xz-Format, aber das veraltete, von den LZMA-Dienstprogrammen verwendete
Format sowie komprimierte Rohdatenströme ohne Containerformat-Header werden ebenfalls unterstützt. Außerdem wird
die Dekompression des von lzip verwendeten .lz-Formats unterstützt.

xz komprimiert oder dekomprimiert jede Datei entsprechend des gewählten Vorgangsmodus. Falls entweder - oder
keine Datei angegeben ist, liest xz aus der Standardeingabe und leitet die verarbeiteten Dateien in die Standard‐
ausgabe. Wenn die Standardausgabe kein Terminal ist, verweigert xz das Schreiben komprimierter Daten in die Stan‐
dardausgabe. Dabei wird eine Fehlermeldung angezeigt und die Datei übersprungen. Ebenso verweigert xz das Lesen
komprimierter Daten aus der Standardeingabe, wenn diese ein Terminal ist.

Dateien, die nicht als - angegeben sind, werden in eine neue Datei geschrieben, deren Name aus dem Namen der
Quell-Datei abgeleitet wird (außer wenn --stdout angegeben ist):

• Bei der Kompression wird das Suffix des Formats der Zieldatei (.xz oder .lzma) an den Namen der Quelldatei
angehängt und so der Name der Zieldatei gebildet.

• Bei der Dekompression wird das Suffix .xz, .lzma oder .lz vom Dateinamen entfernt und so der Name der Zield‐
atei gebildet. Außerdem erkennt xz die Suffixe .txz und .tlz und ersetzt diese durch .tar.

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

Außer beim Schreiben in die Standardausgabe zeigt xz eine Warnung an und überspringt die Datei, wenn eine der
folgenden Bedingungen zutreffend ist:

• Die Datei ist keine reguläre Datei. Symbolischen Verknüpfungen wird nicht gefolgt und diese daher nicht zu den
regulären Dateien gezählt.

• Die Datei hat mehr als eine harte Verknüpfung.

• Für die Datei ist das »setuid«-, »setgid«- oder »sticky«-Bit gesetzt.

• Der Aktionsmodus wird auf Kompression gesetzt und die Datei hat bereits das Suffix des Zieldateiformats (.xz
oder .txz beim Komprimieren in das .xz-Format und .lzma oder .tlz beim Komprimieren in das .lzma-Format).

• Der Aktionsmodus wird auf Dekompression gesetzt und die Datei hat nicht das Suffix eines der unterstützten
Zieldateiformate (.xz, .txz, .lzma, .tlz oder .lz).

Nach erfolgreicher Kompression oder Dekompression der Datei kopiert xz Eigentümer, Gruppe, Zugriffsrechte, Zu‐
griffszeit und Änderungszeit aus der Ursprungs-Datei in die Zieldatei. Sollte das Kopieren der Gruppe fehlschla‐
gen, werden die Zugriffsrechte so angepasst, dass jenen Benutzern der Zugriff auf die Zieldatei verwehrt bleibt,
die auch keinen Zugriff auf die Ursprungs-Datei hatten. Das Kopieren anderer Metadaten wie Zugriffssteuerlisten
oder erweiterter Attribute wird von xz noch nicht unterstützt.

Sobald die Zieldatei erfolgreich geschlossen wurde, wird die Ursprungs-Datei entfernt. Dies wird durch die Option
--keep verhindert. Die Ursprungs-Datei wird niemals entfernt, wenn die Ausgabe in die Standardausgabe geschrieben
wird oder falls ein Fehler auftritt.

Durch Senden der Signale SIGINFO oder SIGUSR1 an den xz-Prozess werden Fortschrittsinformationen in den
Fehlerkanal der Standardausgabe geleitet. Dies ist nur eingeschränkt hilfreich, wenn die Standardfehlerausgabe
ein Terminal ist. Mittels --verbose wird ein automatisch aktualisierter Fortschrittsanzeiger angezeigt.

Speicherbedarf
In Abhängigkeit von den gewählten Kompressionseinstellungen bewegt sich der Speicherverbrauch zwischen wenigen
hundert Kilobyte und mehreren Gigabyte. Die Einstellungen bei der Kompression einer Datei bestimmen dabei den
Speicherbedarf bei der Dekompression. Die Dekompression benötigt üblicherweise zwischen 5 % und 20 % des Speich‐
ers, der bei der Kompression der Datei erforderlich war. Beispielsweise benötigt die Dekompression einer Datei,
die mit xz -9 komprimiert wurde, gegenwärtig etwa 65 MiB Speicher. Es ist jedoch auch möglich, dass .xz-Dateien
mehrere Gigabyte an Speicher zur Dekompression erfordern.

Insbesondere für Benutzer älterer Systeme wird eventuell ein sehr großer Speicherbedarf ärgerlich sein. Um unan‐
genehme Überraschungen zu vermeiden, verfügt xz über eine eingebaute Begrenzung des Speicherbedarfs, die allerd‐
ings in der Voreinstellung deaktiviert ist. Zwar verfügen einige Betriebssysteme über eingebaute Möglichkeiten
zur prozessabhängigen Speicherbegrenzung, doch diese sind zu unflexibel (zum Beispiel kann ulimit(1) beim Begren‐
zen des virtuellen Speichers mmap(2) beeinträchtigen).

Die Begrenzung des Speicherbedarfs kann mit der Befehlszeilenoption --memlimit=Begrenzung aktiviert werden. Oft
ist es jedoch bequemer, die Begrenzung durch Setzen der Umgebungsvariable XZ_DEFAULTS standardmäßig zu ak‐
tivieren, zum Beispiel XZ_DEFAULTS=--memlimit=150MiB. Die Begrenzungen können getrennt für Kompression und Dekom‐
pression mittels --memlimit-compress=Begrenzung und --memlimit-decompress=Begrenzung festgelegt werden. Die Ver‐
wendung einer solchen Option außerhalb der Variable XZ_DEFAULTS ist kaum sinnvoll, da xz in einer einzelnen Ak‐
tion nicht gleichzeitig Kompression und Dekompression ausführen kann und --memlimit=Begrenzung (oder -M Begren‐
zung) lässt sich einfacher in der Befehlszeile eingeben.

Wenn die angegebene Speicherbegrenzung bei der Dekompression überschritten wird, schlägt der Vorgang fehl und xz
zeigt eine Fehlermeldung an. Wird die Begrenzung bei der Kompression überschritten, dann versucht xz die Einstel‐
lungen entsprechend anzupassen, außer wenn --format=raw oder --no-adjust angegeben ist. Auf diese Weise schlägt
die Aktion nicht fehl, es sei denn, die Begrenzung wurde sehr niedrig angesetzt. Die Anpassung der Einstellungen
wird schrittweise vorgenommen, allerdings entsprechen die Schritte nicht den Voreinstellungen der Kompression‐
sstufen. Das bedeutet, wenn beispielsweise die Begrenzung nur geringfügig unter den Anforderungen für xz -9
liegt, werden auch die Einstellungen nur wenig angepasst und nicht vollständig herunter zu den Werten für xz -8

Verkettung und Auffüllung von .xz-Dateien
Es ist möglich, .xz-Dateien direkt zu verketten. Solche Dateien werden von xz genauso dekomprimiert wie eine
einzelne .xz-Datei.

Es ist weiterhin möglich, eine Auffüllung zwischen den verketteten Teilen oder nach dem letzten Teil einzufügen.
Die Auffüllung muss aus Null-Bytes bestehen und deren Größe muss ein Vielfaches von vier Byte sein. Dies kann zum
Beispiel dann vorteilhaft sein, wenn die .xz-Datei auf einem Datenträger gespeichert wird, dessen Dateisystem die
Dateigrößen in 512-Byte-Blöcken speichert.

Verkettung und Auffüllung sind für .lzma-Dateien oder Rohdatenströme nicht erlaubt.

OPTIONEN
Ganzzahlige Suffixe und spezielle Werte
An den meisten Stellen, wo ein ganzzahliges Argument akzeptiert wird, kann ein optionales Suffix große Ganzzahlw‐
erte einfacher darstellen. Zwischen Ganzzahl und dem Suffix dürfen sich keine Leerzeichen befinden.

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 akzep‐
tiert.

Der spezielle Wert max kann dazu verwendet werden, um den von der jeweiligen Option akzeptierten maximalen Ganz‐
zahlwert anzugeben.

Aktionsmodus
Falls mehrere Aktionsmodi angegeben sind, wird der zuletzt angegebene verwendet.

-z, --compress
Kompression. Dies ist der voreingestellte Aktionsmodus, sofern keiner angegeben ist und auch kein bes‐
timmter Modus aus dem Befehlsnamen abgeleitet werden kann (der Befehl unxz impliziert zum Beispiel --de‐
compress).

-d, --decompress, --uncompress
dekomprimpiert.

-t, --test
prüft die Integrität der komprimierten Dateien. Diese Option ist gleichbedeutend mit --decompress --std‐
out, außer dass die dekomprimierten Daten verworfen werden, anstatt sie in die Standardausgabe zu leiten.
Es werden keine Dateien erstellt oder entfernt.

-l, --list
gibt Informationen zu den komprimierten Dateien aus. Es werden keine unkomprimierten Dateien ausgegeben
und keine Dateien angelegt oder entfernt. Im Listenmodus kann das Programm keine komprimierten Daten aus
der Standardeingabe oder anderen nicht durchsuchbaren Quellen lesen.

Die Liste zeigt in der Standardeinstellung grundlegende Informationen zu den Dateien an, zeilenweise pro
Datei. Detailliertere Informationen erhalten Sie mit der Option --verbose. Wenn Sie diese Option zweimal
angeben, werden noch ausführlichere Informationen ausgegeben. Das kann den Vorgang allerdings deutlich
verlangsamen, da die Ermittlung der zusätzlichen Informationen zahlreiche Suchvorgänge erfordert. Die Bre‐
ite der ausführlichen Ausgabe übersteigt 80 Zeichen, daher könnte die Weiterleitung in beispielsweise
less -S sinnvoll sein, falls das Terminal nicht breit genug ist.

Die exakte Ausgabe kann in verschiedenen xz-Versionen und Spracheinstellungen unterschiedlich sein. Wenn
eine maschinell auswertbare Ausgabe gewünscht ist, dann sollten Sie --robot --list verwenden.

Aktionsattribute
-k, --keep
verhindert das Löschen der Eingabedateien.

Seit der xz-Version 5.2.6 wird die Kompression oder Dekompression auch dann ausgeführt, wenn die Eingabe
ein symbolischer Link zu einer regulären Datei ist, mehr als einen harten Link hat oder das »setuid«-,
»setgid«- oder »sticky«-Bit gesetzt ist. Die genannten Bits werden nicht in die Zieldatei kopiert. In
früheren Versionen geschah dies nur mit --force.

-f, --force
Diese Option hat verschiedene Auswirkungen:

• Wenn die Zieldatei bereits existiert, wird diese vor der Kompression oder Dekompression gelöscht.

• Die Kompression oder Dekompression wird auch dann ausgeführt, wenn die Eingabe ein symbolischer Link zu
einer regulären Datei ist, mehr als einen harten Link hat oder das »setuid«-, »setgid«- oder
»sticky«-Bit gesetzt ist. Die genannten Bits werden nicht in die Zieldatei kopiert.

• Wenn es zusammen mit --decompress und --stdout verwendet wird und xz den Typ der Quelldatei nicht er‐
mitteln kann, wird die Quelldatei unverändert in die Standardausgabe kopiert. Dadurch kann xzcat
--force für Dateien, die nicht mit xz komprimiert wurden, wie cat(1) verwendet werden. Zukünftig könnte
xz neue Dateikompressionsformate unterstützen, wodurch xz mehr Dateitypen dekomprimieren kann, anstatt
sie unverändert in die Standardausgabe zu kopieren. Mit der Option --format=Format können Sie xz an‐
weisen, nur ein einzelnes Dateiformat zu dekomprimieren.

-c, --stdout, --to-stdout
schreibt die komprimierten oder dekomprimierten Daten in die Standardausgabe anstatt in eine Datei. Dies
impliziert --keep.

--single-stream
dekomprimiert nur den ersten .xz-Datenstrom und ignoriert stillschweigend weitere Eingabedaten, die
möglicherweise dem Datenstrom folgen. Normalerweise führt solcher anhängender Datenmüll dazu, dass xz eine
Fehlermeldung ausgibt.

xz dekomprimiert niemals mehr als einen Datenstrom aus .lzma-Dateien oder Rohdatenströmen, aber dennoch
wird durch diese Option möglicherweise vorhandener Datenmüll nach der .lzma-Datei oder dem Rohdatenstrom
ignoriert.

Diese Option ist wirkungslos, wenn der Aktionsmodus nicht --decompress oder --test ist.

--no-sparse
verhindert die Erzeugung von Sparse-Dateien. In der Voreinstellung versucht xz, bei der Dekompression in
eine reguläre Datei eine Sparse-Datei zu erzeugen, wenn die dekomprimierten Daten lange Abfolgen von
binären Nullen enthalten. Dies funktioniert auch beim Schreiben in die Standardausgabe, sofern diese in
eine reguläre Datei weitergeleitet wird und bestimmte Zusatzbedingungen erfüllt sind, die die Aktion ab‐
sichern. Die Erzeugung von Sparse-Dateien kann Plattenplatz sparen und beschleunigt die Dekompression
durch Verringerung der Ein-/Ausgaben der Platte.

-S .suf, --suffix=.suf
verwendet .suf bei der Dekompression anstelle von .xz oder .lzma als Suffix für die Zieldatei. Falls nicht
in die Standardausgabe geschrieben wird und die Quelldatei bereits das Suffix .suf hat, wird eine Warnung
angezeigt und die Datei übersprungen.

berücksichtigt bei der Dekompression zusätzlich zu Dateien mit den Suffixen .xz, .txz, .lzma, .tlz oder
.lz auch jene mit dem Suffix .suf. Falls die Quelldatei das Suffix .suf hat, wird dieses entfernt und so
der Name der Zieldatei abgeleitet.

Beim Komprimieren oder Dekomprimieren von Rohdatenströmen mit --format=raw muss das Suffix stets angegeben
werden, außer wenn die Ausgabe in die Standardausgabe erfolgt. Der Grund dafür ist, dass es kein
vorgegebenes Suffix für Rohdatenströme gibt.

--files[=Datei]
liest die zu verarbeitenden Dateinamen aus Datei. Falls keine Datei angegeben ist, werden die Dateinamen
aus der Standardeingabe gelesen. Dateinamen müssen mit einem Zeilenumbruch beendet werden. Ein Bindestrich
(-) wird als regulärer Dateiname angesehen und nicht als Standardeingabe interpretiert. Falls Dateinamen
außerdem als Befehlszeilenargumente angegeben sind, werden diese vor den Dateinamen aus der Datei verar‐
beitet.

--files0[=Datei]
Dies ist gleichbedeutend mit --files[=Datei], außer dass jeder Dateiname mit einem Null-Zeichen
abgeschlossen werden muss.

Grundlegende Dateiformat- und Kompressionsoptionen
-F Format, --format=Format
gibt das Format der zu komprimierenden oder dekomprimierenden Datei an:

auto Dies ist die Voreinstellung. Bei der Kompression ist auto gleichbedeutend mit xz. Bei der Dekom‐
pression wird das Format der Eingabedatei automatisch erkannt. Beachten Sie, dass Rohdatenströme,
wie sie mit --format=raw erzeugt werden, nicht automatisch erkannt werden können.

xz Die Kompression erfolgt in das .xz-Dateiformat oder akzeptiert nur .xz-Dateien bei der Dekompres‐
sion.

lzma, alone
Die Kompression erfolgt in das veraltete .lzma-Dateiformat oder akzeptiert nur .lzma-Dateien bei
der Dekompression. Der alternative Name alone dient der Abwärtskompatibilität zu den LZMA-Dienst‐
programmen.

lzip Akzeptiert nur .lz-Dateien bei der Dekompression. Kompression wird nicht unterstützt.

Das .lz-Format wird in Version 0 und der unerweiterten Version 1 unterstützt. Dateien der Version 0
wurden von lzip 1.3 und älter erstellt. Solche Dateien sind nicht sehr weit verbreitet, können aber
in Dateiarchiven gefunden werden, da einige Quellpakete in diesem Format veröffentlicht wurden. Es
ist auch möglich, dass Benutzer alte persönliche Dateien in diesem Format haben. Die Dekompression‐
sunterstützung für das Format der Version 0 wurde mit der Version 1.18 aus lzip entfernt.

lzip-Versionen ab 1.4 erstellen Dateien im Format der Version 0. Die Erweiterung »Sync Flush
Marker« zur Formatversion 1 wurde in lzip 1.6 hinzugefügt. Diese Erweiterung wird sehr selten ver‐
wendet und wird von xz nicht unterstützt (die Eingabe wird als beschädigt erkannt).

raw Komprimiert oder dekomprimiert einen Rohdatenstrom (ohne Header). Diese Option ist nur für fort‐
geschrittene Benutzer bestimmt. Zum Dekodieren von Rohdatenströmen müssen Sie die Option --for‐
mat=raw verwenden und die Filterkette ausdrücklich angeben, die normalerweise in den (hier fehlen‐
den) Container-Headern gespeichert worden wäre.

-C Prüfung, --check=Prüfung
gibt den Typ der Integritätsprüfung an. Die Prüfsumme wird aus den unkomprimierten Daten berechnet und in
der .xz-Datei gespeichert. Diese Option wird nur bei der Kompression in das .xz-Format angewendet, da das
.lzma-Format keine Integritätsprüfungen unterstützt. Die eigentliche Integritätsprüfung erfolgt (falls
möglich), wenn die .xz-Datei dekomprimiert wird.

Folgende Typen von Prüfungen werden unterstützt:

none führt keine Integritätsprüfung aus. Dies ist eine eher schlechte Idee. Dennoch kann es nützlich
sein, wenn die Integrität der Daten auf andere Weise sichergestellt werden kann.

crc32 berechnet die CRC32-Prüfsumme anhand des Polynoms aus IEEE-802.3 (Ethernet).

crc64 berechnet die CRC64-Prüfsumme anhand des Polynoms aus ECMA-182. Dies ist die Voreinstellung, da
beschädigte Dateien etwas besser als mit CRC32 erkannt werden und die Geschwindigkeitsdifferenz
unerheblich ist.

sha256 berechnet die SHA-256-Prüfsumme. Dies ist etwas langsamer als CRC32 und CRC64.

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

--ignore-check
verifiziert die Integritätsprüfsumme der komprimierten Daten bei der Dekompression nicht. Die CRC32-Werte
in den .xz-Headern werden weiterhin normal verifiziert.

Verwenden Sie diese Option nicht, außer Sie wissen, was Sie tun. Mögliche Gründe, diese Option zu verwen‐
den:

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

• Erhöhung der Geschwindigkeit bei der Dekompression. Dies macht sich meist mit SHA-256 bemerkbar, oder
mit Dateien, die extrem stark komprimiert sind. Wir empfehlen, diese Option nicht für diesen Zweck zu
verwenden, es sei denn, die Integrität der Datei wird extern auf andere Weise überprüft.

-0 … -9
wählt eine der voreingestellten Kompressionsstufen, standardmäßig -6. Wenn mehrere Voreinstellungsstufen
angegeben sind, ist nur die zuletzt angegebene wirksam. Falls bereits eine benutzerdefinierte Filterkette
angegeben wurde, wird diese durch die Festlegung der Voreinstellung geleert.

Die Unterschiede zwischen den Voreinstellungsstufen sind deutlicher als bei gzip(1) und bzip2(1). Die
gewählten Kompressionseinstellungen bestimmen den Speicherbedarf bei der Dekompression, daher ist es auf
älteren Systemen mit wenig Speicher bei einer zu hoch gewählten Voreinstellung schwer, eine Datei zu
dekomprimieren. Insbesondere ist es keine gute Idee, blindlings -9 für alles zu verwenden, wie dies häufig
mit gzip(1) und bzip2(1) gehandhabt wird.

-0 … -3
Diese Voreinstellungen sind recht schnell. -0 ist manchmal schneller als gzip -9, wobei aber die
Kompression wesentlich besser ist. Die schnelleren Voreinstellungen sind im Hinblick auf die
Geschwindigkeit mit bzip2(1) vergleichbar , mit einem ähnlichen oder besseren Kompressionsverhält‐
nis, wobei das Ergebnis aber stark vom Typ der zu komprimierenden Daten abhängig ist.

-4 … -6
Gute bis sehr gute Kompression, wobei der Speicherbedarf für die Dekompression selbst auf alten
Systemen akzeptabel ist. -6 ist die Voreinstellung, welche üblicherweise eine gute Wahl für die
Verteilung von Dateien ist, die selbst noch auf Systemen mit nur 16 MiB Arbeitsspeicher dekomprim‐
iert werden müssen (-5e oder -6e sind ebenfalls eine Überlegung wert. Siehe --extreme).

-7 … -9
Ähnlich wie -6, aber mit einem höheren Speicherbedarf für die Kompression und Dekompression. Sie
sind nur nützlich, wenn Dateien komprimiert werden sollen, die größer als 8 MiB, 16 MiB
beziehungsweise 32 MiB sind.

Auf der gleichen Hardware ist die Dekompressionsgeschwindigkeit ein nahezu konstanter Wert in Bytes kom‐
primierter Daten pro Sekunde. Anders ausgedrückt: Je besser die Kompression, umso schneller wird üblicher‐
weise die Dekompression sein. Das bedeutet auch, dass die Menge der pro Sekunde ausgegebenen unkomprim‐
ierten Daten stark variieren kann.

Die folgende Tabelle fasst die Eigenschaften der Voreinstellungen zusammen:

Voreinst. Wörtb.Gr KomprCPU KompSpeich DekompSpeich
-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

Spaltenbeschreibungen:

• Wörtb.Größe ist die Größe des LZMA2-Wörterbuchs. Es ist Speicherverschwendung, ein Wörterbuch zu ver‐
wenden, das größer als die unkomprimierte Datei ist. Daher ist es besser, die Voreinstellungen -7 … -9
zu vermeiden, falls es keinen wirklichen Bedarf dafür gibt. Mit -6 und weniger wird üblicherweise so
wenig Speicher verschwendet, dass dies nicht ins Gewicht fällt.

• KomprCPU ist eine vereinfachte Repräsentation der LZMA2-Einstellungen, welche die Kompressions‐
geschwindigkeit beeinflussen. Die Wörterbuchgröße wirkt sich ebenfalls auf die Geschwindigkeit aus.
Während KompCPU für die Stufen -6 bis -9 gleich ist, tendieren höhere Stufen dazu, etwas langsamer zu
sein. Um eine noch langsamere, aber möglicherweise bessere Kompression zu erhalten, siehe --extreme.

• KompSpeich enthält den Speicherbedarf des Kompressors im Einzel-Thread-Modus. Dieser kann zwischen den
xz-Versionen leicht variieren. Der Speicherbedarf einiger der zukünftigen Multithread-Modi kann drama‐
tisch höher sein als im Einzel-Thread-Modus.

• DekompSpeich enthält den Speicherbedarf für die Dekompression. Das bedeutet, dass die Kompressionsein‐
stellungen den Speicherbedarf bei der Dekompression bestimmen. Der exakte Speicherbedarf bei der Dekom‐
pression ist geringfügig größer als die Größe des LZMA2-Wörterbuchs, aber die Werte in der Tabelle wur‐
den auf ganze MiB aufgerundet.

-e, --extreme
verwendet eine langsamere Variante der gewählten Kompressions-Voreinstellungsstufe (-0 … -9), um hof‐
fentlich ein etwas besseres Kompressionsverhältnis zu erreichen, das aber in ungünstigen Fällen auch
schlechter werden kann. Der Speicherverbrauch bei der Dekompression wird dabei nicht beeinflusst, aber der
Speicherverbrauch der Kompression steigt in den Voreinstellungsstufen -0 bis -3 geringfügig an.

Da es zwei Voreinstellungen mit den Wörterbuchgrößen 4 MiB und 8 MiB gibt, verwenden die Voreinstel‐
lungsstufen -3e und -5e etwas schnellere Einstellungen (niedrigere KompCPU) als -4e beziehungsweise -6e.
Auf diese Weise sind zwei Voreinstellungen nie identisch.

Voreinst. Wörtb.Gr KomprCPU KompSpeich DekompSpeich
-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 ein 8 MiB großes Wörterbuch verwenden, deren
Reihenfolge von der schnellsten zur langsamsten -5, -6, -5e und -6e ist.

--fast
--best sind etwas irreführende Aliase für -0 beziehungsweise -9. Sie werden nur zwecks Abwärtskompatibilität zu
den LZMA-Dienstprogrammen bereitgestellt. Sie sollten diese Optionen besser nicht verwenden.

--block-size=Größe
teilt beim Komprimieren in das .xz-Format die Eingabedaten in Blöcke der angegebenen Größe in Byte. Die
Blöcke werden unabhängig voneinander komprimiert, was dem Multi-Threading entgegen kommt und Zufallszu‐
griffe bei der Dekompression begrenzt. Diese Option wird typischerweise eingesetzt, um die vorgegebene
Blockgröße im Multi-Thread-Modus außer Kraft zu setzen, aber sie kann auch im Einzel-Thread-Modus angewen‐
det werden.

Im Multi-Thread-Modus wird etwa die dreifache Größe in jedem Thread zur Pufferung der Ein- und Ausgabe
belegt. Die vorgegebene Größe ist das Dreifache der Größe des LZMA2-Wörterbuchs oder 1 MiB, je nachdem,
was mehr ist. Typischerweise ist das Zwei- bis Vierfache der Größe des LZMA2-Wörterbuchs oder wenigstens 1
MB ein guter Wert. Eine Größe, die geringer ist als die des LZMA2-Wörterbuchs, ist Speicherverschwendung,
weil dann der LZMA2-Wörterbuchpuffer niemals vollständig genutzt werden würde. Die Größe der Blöcke wird
in den Block-Headern gespeichert, die von einer zukünftigen Version von xz für eine Multi-Thread-Dekom‐
pression genutzt wird.

Im Einzel-Thread-Modus werden die Blöcke standardmäßig nicht geteilt. Das Setzen dieser Option wirkt sich
nicht auf den Speicherbedarf aus. In den Block-Headern werden keine Größeninformationen gespeichert, daher
werden im Einzel-Thread-Modus erzeugte Dateien nicht zu den im Multi-Thread-Modus erzeugten Dateien iden‐
tisch sein. Das Fehlen der Größeninformation bedingt auch, dass eine zukünftige Version von xz nicht in
der Lage sein wird, die Dateien im Multi-Thread-Modus zu dekomprimieren.

--block-list=Größen
beginnt bei der Kompression in das .xz-Format nach den angegebenen Intervallen unkomprimierter Daten einen
neuen Block.

Die unkomprimierte Größe der Blöcke wird in einer durch Kommata getrennten Liste angegeben. Auslassen
einer Größe (zwei oder mehr aufeinander folgende Kommata) ist ein Kürzel dafür, die Größe des vorherigen
Blocks zu verwenden.

Falls die Eingabedatei größer ist als die Summe der Größen, dann wird der letzte in Größe angegebene Wert
bis zum Ende der Datei wiederholt. Mit dem speziellen Wert 0 können Sie angeben, dass der Rest der Datei
als einzelner Block kodiert werden soll.

Falls Sie Größen angeben, welche die Blockgröße des Encoders übersteigen (entweder den Vorgabewert im
Thread-Modus oder den mit --block-size=Größe angegebenen Wert), wird der Encoder zusätzliche Blöcke erzeu‐
gen, wobei die in den Größen angegebenen Grenzen eingehalten werden. Wenn Sie zum Beispiel
--block-size=10MiB --block-list=5MiB,10MiB,8MiB,12MiB,24MiB angeben und die Eingabedatei 80 MiB groß ist,
erhalten Sie 11 Blöcke: 5, 10, 8, 10, 2, 10, 10, 4, 10, 10 und 1 MiB.

Im Multi-Thread-Modus werden die Blockgrößen in den Block-Headern gespeichert. Dies geschieht im
Einzel-Thread-Modus nicht, daher wird die kodierte Ausgabe zu der im Multi-Thread-Modus nicht identisch
sein.

--flush-timeout=Zeit
löscht bei der Kompression die ausstehenden Daten aus dem Encoder und macht sie im Ausgabedatenstrom
verfügbar, wenn mehr als die angegebene Zeit in Millisekunden (als positive Ganzzahl) seit dem vorherigen
Löschen vergangen ist und das Lesen weiterer Eingaben blockieren würde. Dies kann nützlich sein, wenn xz
zum Komprimieren von über das Netzwerk eingehenden Daten verwendet wird. Kleine Zeit-Werte machen die
Daten unmittelbar nach dem Empfang nach einer kurzen Verzögerung verfügbar, während große Zeit-Werte ein
besseres Kompressionsverhältnis bewirken.

Dieses Funktionsmerkmal ist standardmäßig deaktiviert. Wenn diese Option mehrfach angegeben wird, ist die
zuletzt angegebene wirksam. Für die Angabe der Zeit kann der spezielle Wert 0 verwendet werden, um dieses
Funktionsmerkmal explizit zu deaktivieren.

Dieses Funktionsmerkmal ist außerhalb von POSIX-Systemen nicht verfügbar.

Dieses Funktionsmerkmal ist noch experimentell. Gegenwärtig ist xz aufgrund der Art und Weise, wie xz
puffert, für Dekompression in Echtzeit ungeeignet.

--memlimit-compress=Grenze
legt eine Grenze für die Speichernutzung bei der Kompression fest. Wenn diese Option mehrmals angegeben
wird, ist die zuletzt angegebene wirksam.

Falls die Kompressionseinstellungen die Grenze überschreiten, versucht xz, die Einstellungen nach unten
anzupassen, so dass die Grenze nicht mehr überschritten wird und zeigt einen Hinweis an, dass eine automa‐
tische Anpassung vorgenommen wurde. Die Anpassungen werden in folgender Reihenfolge angewendet: Re‐
duzierung der Anzahl der Threads, Wechsel in den Einzelthread-Modus, falls sogar ein einziger Thread im
Multithread-Modus die Grenze überschreitet, und schlussendlich die Reduzierung der Größe des LZMA2-Wörter‐
buchs.

Beim Komprimieren mit --format=raw oder falls --no-adjust angegeben wurde, wird nur die Anzahl der Threads
reduziert, da nur so die komprimierte Ausgabe nicht beeinflusst wird.

Falls die Grenze nicht anhand der vorstehend beschriebenen Anpassungen gesetzt werden kann, wird ein
Fehler 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 Byte sein. Ein Suffix wie MiB kann dabei hilfreich sein.
Beispiel: --memlimit-compress=80MiB.

• Die Grenze kann als Prozentsatz des physischen Gesamtspeichers (RAM) angegeben werden. Dies ist ins‐
besondere nützlich, wenn in einem Shell-Initialisierungsskript, das mehrere unterschiedliche Rechner
gemeinsam verwenden, die Umgebungsvariable XZ_DEFAULTS gesetzt ist. Auf diese Weise ist die Grenze auf
Systemen mit mehr Speicher höher. Beispiel: --memlimit-compress=70%

• Mit 0 kann die Grenze auf den Standardwert zurückgesetzt werden. Dies ist gegenwärtig gleichbedeutend
mit dem Setzen der Grenze auf max (keine Speicherbegrenzung).

Für die 32-Bit-Version von xz gibt es einen Spezialfall: Falls die Grenze über 4020 MiB liegt, wird die
Grenze auf 4020 MiB gesetzt. Auf MIPS32 wird stattdessen 2000 MB verwendet (die Werte 0 und max werden hi‐
ervon nicht beeinflusst; für die Dekompression gibt es keine vergleichbare Funktion). Dies kann hilfreich
sein, wenn ein 32-Bit-Executable auf einen 4 GiB großen Adressraum (2 GiB auf MIPS32) zugreifen kann,
wobei wir hoffen wollen, dass es in anderen Situationen keine negativen Effekte hat.

Siehe auch den Abschnitt Speicherbedarf.

--memlimit-decompress=Grenze
legt eine Begrenzung des Speicherverbrauchs für die Dekompression fest. Dies beeinflusst auch den Modus
--list. Falls die Aktion nicht ausführbar ist, ohne die Grenze zu überschreiten, gibt xz eine Fehlermel‐
dung aus und die Dekompression wird fehlschlagen. Siehe --memlimit-compress=Grenze zu möglichen Wegen, die
Grenze anzugeben.

--memlimit-mt-decompress=Grenze
legt eine Begrenzung des Speicherverbrauchs für Multithread-Dekompression fest. Dies beeinflusst lediglich
die Anzahl der Threads; xz wird dadurch niemals die Dekompression einer Datei verweigern. Falls die Grenze
für jegliches Multithreading zu niedrig ist, wird sie ignoriert und xz setzt im Einzelthread-modus fort.
Beachten Sie auch, dass bei der Verwendung von --memlimit-decompress dies stets sowohl auf den
Einzelthread-als auch auf den Multithread-Modus angewendet wird und so die effektive Grenze für den Multi‐
thread-Modus niemals höher sein wird als die mit --memlimit-decompress gesetzte Grenze.

Im Gegensatz zu anderen Optionen zur Begrenzung des Speicherverbrauchs hat --memlimit-mt-decompress=Grenze
eine systemspezifisch vorgegebene Grenze. Mit xz --info-memory können Sie deren aktuellen Wert anzeigen
lassen.

Diese Option und ihr Standardwert existieren, weil die unbegrenzte threadbezogene Dekompression bei eini‐
gen Eingabedateien zu unglaublich großem Speicherverbrauch führen würde. Falls die vorgegebene Grenze auf
Ihrem System zu niedrig ist, können Sie die Grenze durchaus erhöhen, aber setzen Sie sie niemals auf einen
Wert größer als die Menge des nutzbaren Speichers, da xz bei entsprechenden Eingabedateien versuchen wird,
diese Menge an Speicher auch bei einer geringen Anzahl von Threads zu verwnden. Speichermangel oder Aus‐
lagerung verbessern die Dekomprimierungsleistung nicht.

Siehe --memlimit-compress=Grenze für mögliche Wege zur Angabe der Grenze. Sezen der Grenze auf 0 setzt
die Grenze auf den vorgegebenen systemspezifischen Wert zurück.

-M Grenze, --memlimit=Grenze, --memory=Grenze
Dies ist gleichbedeutend mit --memlimit-compress=Grenze --memlimit-decompress=Grenze --memlimit-mt-decom‐
press=Grenze.

--no-adjust
zeigt einen Fehler an und beendet, falls die Grenze der Speichernutzung nicht ohne Änderung der Einstel‐
lungen, welche die komprimierte Ausgabe beeinflussen, berücksichtigt werden kann. Das bedeutet, dass xz
daran gehindert wird, den Encoder vom Multithread-Modus in den Einzelthread-Modus zu versetzen und die
Größe des LZMA2-Wörterbuchs zu reduzieren. Allerdings kann bei Verwendung dieser Option dennoch die Anzahl
der Threads reduziert werden, um die Grenze der Speichernutzung zu halten, sofern dies die komprimierte
Ausgabe nicht beeinflusst.

Die automatische Anpassung ist beim Erzeugen von Rohdatenströmen (--format=raw) immer deaktiviert.

-T Threads, --threads=Threads
gibt die Anzahl der zu verwendenden Arbeits-Threads an. Wenn Sie Threads auf einen speziellen Wert 0 set‐
zen, verwendet xz maximal so viele Threads, wie der/die Prozessor(en) im System untestützen. Die
tatsächliche Anzahl kann geringer sein als die angegebenen Threads, wenn die Eingabedatei nicht groß genug
für Threading mit den gegebenen Einstellungen ist oder wenn mehr Threads die Speicherbegrenzung
übersteigen würden.

Die Multithread- bzw. Einzelthread-Kompressoren erzeugen unterschiedliche Ausgaben. Der Einzelthread-Kom‐
pressor erzeugt die geringste Dateigröße, aber nur die Ausgabe des Multithread-Kompressors kann mit
mehreren Threads wieder dekomprimiert werden. Das Setzen der Anzahl der Threads auf 1 wird den
Einzelthread-Modus verwenden. Das Setzen der Anzahl der Threads auf einen anderen Wert einschließlich 0
verwendet den Multithread-Kompressor, und zwar sogar dann, wenn das System nur einen einzigen Hard‐
ware-Thread unterstützt (xz 5.2.x verwendete in diesem Fall noch den Einzelthread-Modus).

Um den Multithread-Modus mit nur einem einzigen Thread zu verwenden, setzen Sie die Anzahl der Threads auf
+1. Das Präfix + hat mit Werten verschieden von 1 keinen Effekt. Eine Begrenzung des Speicherverbrauchs
kann xz dennoch veranlassen, den Einzelthread-Modus zu verwenden, außer wenn --no-adjust verwendet wird.
Die Unterstützung für das Präfix + wurde in xz 5.4.0 hinzugefügt.

Falls das automatische Setzen der Anzahl der Threads angefordert und keine Speicherbegrenzung angegeben
wurde, dann wird eine systemspezifisch vorgegebene weiche Grenze verwendet, um eventuell die Anzahl der
Threads zu begrenzen. Es ist eine weiche Grenze im Sinne davon, dass sie ignoriert wird, falls die Anzahl
der Threads 1 ist; daher wird eine weiche Grenze xz niemals an der Kompression oder Dekompression hindern.
Diese vorgegebene weiche Grenze veranlasst xz nicht, vom Multithread-Modus in den Einzelthread-Modus zu
wechseln. Die aktiven Grenzen können Sie mit dem Befehl xz --info-memory anzeigen lassen.

Die gegenwärtig einzige Threading-Methode teilt die Eingabe in Blöcke und komprimiert diese unabhängig
voneinander. Die vorgegebene Blockgröße ist von der Kompressionsstufe abhängig und kann mit der Option
--block-size=Größe außer Kraft gesetzt werden.

Eine thread-basierte Dekompression wird nur bei Dateien funktionieren, die mehrere Blöcke mit Größeninfor‐
mationen in deren Headern enthalten. Alle im Multi-Thread-Modus komprimierten Dateien, die groß genug
sind, erfüllen diese Bedingung, im Einzel-Thread-Modus komprimierte Dateien dagegen nicht, selbst wenn
--block-size=Größe verwendet wurde.

Benutzerdefinierte Filterketten für die Kompression
Eine benutzerdefinierte Filterkette ermöglicht die Angabe detaillierter Kompressionseinstellungen, anstatt von
den Voreinstellungen auszugehen. Wenn eine benutzerdefinierte Filterkette angegeben wird, werden die vorher in
der Befehlszeile angegebenen Voreinstellungsoptionen (-0 … -9 und --extreme) außer Kraft gesetzt. Wenn eine Vore‐
instellungsoption nach einer oder mehreren benutzerdefinierten Filterkettenoptionen angegeben wird, dann wird die
neue Voreinstellung wirksam und die zuvor angegebenen Filterkettenoptionen werden außer Kraft gesetzt.

Eine Filterkette ist mit dem Piping (der Weiterleitung) in der Befehlszeile vergleichbar. Bei der Kompression
gelangt die unkomprimierte Eingabe in den ersten Filter, dessen Ausgabe wiederum in den zweiten Filter geleitet
wird (sofern ein solcher vorhanden ist). Die Ausgabe des letzten Filters wird in die komprimierte Datei
geschrieben. In einer Filterkette sind maximal vier Filter zulässig, aber typischerweise besteht eine Filterkette
nur aus einem oder zwei Filtern.

Bei vielen Filtern ist die Positionierung in der Filterkette eingeschränkt: Einige Filter sind nur als letzte in
der Kette verwendbar, einige können nicht als letzte Filter gesetzt werden, und andere funktionieren an be‐
liebiger Stelle. Abhängig von dem Filter ist diese Beschränkung entweder auf das Design des Filters selbst
zurückzuführen oder ist aus Sicherheitsgründen vorhanden.

Eine benutzerdefinierte Filterkette wird durch eine oder mehrere Filteroptionen in der Reihenfolge angegeben, in
der sie in der Filterkette wirksam werden sollen. Daher ist die Reihenfolge der Filteroptionen von signifikanter
Bedeutung! Beim Dekodieren von Rohdatenströmen (--format=raw) wird die Filterkette in der gleichen Reihenfolge
angegeben wie bei der Kompression.

Filter akzeptieren filterspezifische Optionen in einer durch Kommata getrennten Liste. Zusätzliche Kommata in den
Optionen werden ignoriert. Jede Option hat einen Standardwert, daher brauchen Sie nur jene anzugeben, die Sie
ändern wollen.

Um die gesamte Filterkette und die Optionen anzuzeigen, rufen Sie xz -vv auf (was gleichbedeutend mit der zweima‐
ligen Angabe von --verbose ist). Dies funktioniert auch zum Betrachten der von den Voreinstellungen verwendeten
Filterkettenoptionen.

--lzma1[=Optionen]
--lzma2[=Optionen]
fügt LZMA1- oder LZMA2-Filter zur Filterkette hinzu. Diese Filter können nur als letzte Filter in der
Kette verwendet werden.

LZMA1 ist ein veralteter Filter, welcher nur wegen des veralteten .lzma-Dateiformats unterstützt wird,
welches nur LZMA1 unterstützt. LZMA2 ist eine aktualisierte Version von LZMA1, welche einige praktische
Probleme von LZMA1 behebt. Das .xz-Format verwendet LZMA2 und unterstützt LZMA1 gar nicht. Kompressions‐
geschwindigkeit und -verhältnis sind bei LZMA1 und LZMA2 praktisch gleich.

LZMA1 und LZMA2 haben die gleichen Optionen:

preset=Voreinstellung
setzt alle LZMA1- oder LZMA2-Optionen auf die Voreinstellung zurück. Diese Voreinstellung wird in
Form einer Ganzzahl angegeben, der ein aus einem einzelnen Buchstaben bestehender Voreinstel‐
lungsmodifikator folgen kann. Die Ganzzahl kann 0 bis 9 sein, entsprechend den Befehlszeilenoptio‐
nen -0 … -9. Gegenwärtig ist e der einzige unterstützte Modifikator, was --extreme entspricht. Wenn
keine Voreinstellung angegeben ist, werden die Standardwerte der LZMA1- oder LZMA2-Optionen der
Voreinstellung 6 entnommen.

dict=Größe
Die Größe des Wörterbuchs (Chronikpuffers) gibt an, wie viel Byte der kürzlich verarbeiteten unkom‐
primierten Daten im Speicher behalten werden sollen. Der Algorithmus versucht, sich wiederholende
Byte-Abfolgen (Übereinstimmungen) in den unkomprimierten Daten zu finden und diese durch Referenzen
zu den Daten zu ersetzen, die sich gegenwärtig im Wörterbuch befinden. Je größer das Wörterbuch,
umso größer ist die Chance, eine Übereinstimmung zu finden. Daher bewirkt eine Erhöhung der Größe
des Wörterbuchs üblicherweise ein besseres Kompressionsverhältnis, aber ein Wörterbuch, das größer
ist als die unkomprimierte Datei, wäre Speicherverschwendung.

Typische Wörterbuch-Größen liegen im Bereich von 64 KiB bis 64 MiB. Das Minimum ist 4 KiB. Das Max‐
imum für die Kompression ist gegenwärtig 1.5 GiB (1536 MiB). Bei der Dekompression wird bereits
eine Wörterbuchgröße bis zu 4 GiB minus 1 Byte unterstützt, welche das Maximum für die LZMA1- und
LZMA2-Datenstromformate ist.

Die Größe des Wörterbuchs und der Übereinstimmungsfinder (Üf) bestimmen zusammen den Speicherver‐
brauch des LZMA1- oder LZMA2-Kodierers. Bei der Dekompression ist ein Wörterbuch der gleichen Größe
(oder ein noch größeres) wie bei der Kompression erforderlich, daher wird der Speicherverbrauch des
Dekoders durch die Größe des bei der Kompression verwendeten Wörterbuchs bestimmt. Die .xz-Header
speichern die Größe des Wörterbuchs entweder als 2^n oder 2^n + 2^(n-1), so dass diese Größen für
die Kompression etwas bevorzugt werden. Andere Größen werden beim Speichern in den .xz-Headern
aufgerundet.

lc=lc gibt die Anzahl der literalen Kontextbits an. Das Minimum ist 0 und das Maximum 4; der Standardwert
ist 3. Außerdem darf die Summe von lc und lp nicht größer als 4 sein.

Alle Bytes, die nicht als Übereinstimmungen kodiert werden können, werden als Literale kodiert.
Solche Literale sind einfache 8-bit-Bytes, die jeweils für sich kodiert werden.

Bei der Literalkodierung wird angenommen, dass die höchsten lc-Bits des zuvor unkomprimierten Bytes
mit dem nächsten Byte in Beziehung stehen. Zum Beispiel folgt in typischen englischsprachigen Tex‐
ten auf einen Großbuchstaben ein Kleinbuchstabe und auf einen Kleinbuchstaben üblicherweise wieder
ein Kleinbuchstabe. Im US-ASCII-Zeichensatz sind die höchsten drei Bits 010 für Großbuchstaben und
011 für Kleinbuchstaben. Wenn lc mindestens 3 ist, kann die literale Kodierung diese Eigenschaft
der unkomprimierten Daten ausnutzen.

Der Vorgabewert (3) ist üblicherweise gut. Wenn Sie die maximale Kompression erreichen wollen, ver‐
suchen Sie lc=4. Manchmal hilft es ein wenig, doch manchmal verschlechtert es die Kompression. Im
letzteren Fall versuchen Sie zum Beispiel auch lc=2.

lp=lp gibt die Anzahl der literalen Positionsbits an. Das Minimum ist 0 und das Maximum 4; die Vorgabe
ist 0.

Lp beeinflusst, welche Art der Ausrichtung der unkomprimierten Daten beim Kodieren von Literalen
angenommen wird. Siehe pb weiter unten für weitere Informationen zur Ausrichtung.

pb=Anzahl
legt die Anzahl der Positions-Bits fest. Das Minimum ist 0 und das Maximum 4; Standard ist 2.

Pb beeinflusst, welche Art der Ausrichtung der unkomprimierten Daten generell angenommen wird.
Standardmäßig wird eine Vier-Byte-Ausrichtung angenommen (2^pb=2^2=4), was oft eine gute Wahl ist,
wenn es keine bessere Schätzung gibt.

Wenn die Ausrichtung bekannt ist, kann das entsprechende Setzen von pb die Dateigröße ein wenig
verringern. Wenn Textdateien zum Beispiel eine Ein-Byte-Ausrichtung haben (US-ASCII, ISO-8859-*,
UTF-8), kann das Setzen von pb=0 die Kompression etwas verbessern. Für UTF-16-Text ist pb=1 eine
gute Wahl. Wenn die Ausrichtung eine ungerade Zahl wie beispielsweise 3 Byte ist, könnte pb=0 die
beste Wahl sein.

Obwohl die angenommene Ausrichtung mit pb und lp angepasst werden kann, bevorzugen LZMA1 und LZMA2
noch etwas die 16-Byte-Ausrichtung. Das sollten Sie vielleicht beim Design von Dateiformaten
berücksichtigen, die wahrscheinlich oft mit LZMA1 oder LZMA2 komprimiert werden.

mf=Üf Der Übereinstimmungsfinder hat einen großen Einfluss auf die Geschwindigkeit des Kodierers, den
Speicherbedarf und das Kompressionsverhältnis. Üblicherweise sind auf Hash-Ketten basierende Übere‐
instimmungsfinder schneller als jene, die mit Binärbäumen arbeiten. Die Vorgabe hängt von der Vore‐
instellungsstufe ab: 0 verwendet hc3, 1-3 verwenden hc4 und der Rest verwendet bt4.

Die folgenden Übereinstimmungsfinder werden unterstützt. Die Formeln zur Ermittlung des Spe‐
icherverbrauchs sind grobe Schätzungen, die der Realität am nächsten kommen, wenn Wörterbuch eine
Zweierpotenz ist.

hc3 Hash-Kette mit 2- und 3-Byte-Hashing
Minimalwert für nice: 3
Speicherbedarf:
dict * 7,5 (falls dict <= 16 MiB);
dict * 5,5 + 64 MiB (falls dict > 16 MiB)

hc4 Hash-Kette mit 2-, 3- und 4-Byte-Hashing
Minimaler Wert für nice: 4
Speicherbedarf:
dict * 7,5 (falls dict <= 32 MiB ist);
dict * 6,5 (falls dict > 32 MiB ist)

bt2 Binärbaum mit 2-Byte-Hashing
Minimaler Wert für nice: 2
Speicherverbrauch: dict * 9.5

bt3 Binärbaum mit 2- und 3-Byte-Hashing
Minimalwert für nice: 3
Speicherbedarf:
dict * 11,5 (falls dict <= 16 MiB ist);
dict * 9,5 + 64 MiB (falls dict > 16 MiB ist)

bt4 Binärbaum mit 2-, 3- und 4-Byte-Hashing
Minimaler Wert für nice: 4
Speicherbedarf:
dict * 11,5 (falls dict <= 32 MiB ist);
dict * 10,5 (falls dict > 32 MiB ist)

mode=Modus
gibt die Methode zum Analysieren der vom Übereinstimmungsfinder gelieferten Daten an. Als Modi wer‐
den fast und normal unterstützt. Die Vorgabe ist fast für die Voreinstellungsstufen 0-3 und normal
für die Voreinstellungsstufen 4-9.

Üblicherweise wird fast mit Hashketten-basierten Übereinstimmungsfindern und normal mit
Binärbaum-basierten Übereinstimmungsfindern verwendet. So machen es auch die Voreinstellungsstufen.

nice=nice
gibt an, was als annehmbarer Wert für eine Übereinstimmung angesehen werden kann. Wenn eine Übere‐
instimmung gefunden wird, die mindestens diesen nice-Wert hat, sucht der Algorithmus nicht weiter
nach besseren Übereinstimmungen.

Der nice-Wert kann 2-273 Byte sein. Höhere Werte tendieren zu einem besseren Kompressionsverhält‐
nis, aber auf Kosten der Geschwindigkeit. Die Vorgabe hängt von der Voreinstellungsstufe ab.

depth=Tiefe
legt die maximale Suchtiefe im Übereinstimmungsfinder fest. Vorgegeben ist der spezielle Wert 0,
der den Kompressor veranlasst, einen annehmbaren Wert für Tiefe aus Üf und nice-Wert zu bestimmen.

Die angemessene Tiefe für Hash-Ketten ist 4-100 und 16-1000 für Binärbäume. Hohe Werte für die
Tiefe können den Kodierer bei einigen Dateien extrem verlangsamen. Vermeiden Sie es, die Tiefe über
einen Wert von 100 zu setzen, oder stellen Sie sich darauf ein, die Kompression abzubrechen, wenn
sie zu lange dauert.

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

--x86[=Optionen]
--arm[=Optionen]
--armthumb[=Optionen]
--arm64[=Optionen]
--powerpc[=Optionen]
--ia64[=Optionen]
--sparc[=Optionen]
fügt ein »Branch/Call/Jump«-(BCJ-)Filter zur Filterkette hinzu. Diese Filter können nicht als letzter Fil‐
ter in der Filterkette verwendet werden.

Ein BCJ-Filter wandelt relative Adressen im Maschinencode in deren absolute Gegenstücke um. Die Datengröße
wird dadurch nicht geändert, aber die Redundanz erhöht, was LZMA2 dabei helfen kann, eine um 10 bis 15%
kleinere .xz-Datei zu erstellen. Die BCJ-Filter sind immer reversibel, daher verursacht die Anwendung
eines BCJ-Filters auf den falschen Datentyp keinen Datenverlust, wobei aber das Kompressionsverhältnis et‐
was schlechter werden könnte. Die BCJ-Filter sind sehr schnell und verbrauchen nur wenig mehr Speicher.

Diese BCJ-Filter haben bekannte Probleme mit dem Kompressionsverhältnis:

• In einigen Dateitypen, die ausführbaren Code enthalten (zum Beispiel Objektdateien, statische Biblio‐
theken und Linux-Kernelmodule), sind die Adressen in den Anweisungen mit Füllwerten gefüllt. Diese
BCJ-Filter führen dennoch die Adressumwandlung aus, wodurch die Kompression bei diesen Dateien
schlechter wird.

• Falls ein BCJ-Filter auf ein Archiv angewendet wird, ist es möglich, dass das Kompressionsverhältnis
schlechter als ohne Filter wird. Falls es beispielsweise ähnliche oder sogar identische ausführbare
Dateien gibt, dann werden diese durch die Filterung wahrscheinlich »unähnlicher« und verschlechtern
dadurch das Kompressionsverhältnis. Der Inhalt nicht-ausführbarer Dateien im gleichen Archiv kann sich
ebenfalls darauf auswirken. In der Praxis werden Sie durch Versuche mit oder ohne BCJ-Filter selbst
herausfinden müssen, was situationsbezogen besser ist.

Verschiedene Befehlssätze haben unterschiedliche Ausrichtungen: Die ausführbare Datei muss in den Eingabe‐
dateien einem Vielfachen dieses Wertes entsprechen, damit dieser Filter funktioniert.

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

Da die BCJ-gefilterten Daten üblicherweise mit LZMA2 komprimiert sind, kann das Kompressionsverhältnis
dadurch etwas verbessert werden, dass die LZMA2-Optionen so gesetzt werden, dass sie der Ausrichtung des
gewählten BCJ-Filters entsprechen. Zum Beispiel ist es beim IA-64-Filter eine gute Wahl, pb=4 oder sogar
pb=4,lp=4,lc=0 mit LZMA2 zu setzen (2^4=16). Der x86-Filter bildet dabei eine Ausnahme; Sie sollten bei
der für LZMA2 voreingestellten 4-Byte-Ausrichtung bleiben, wenn Sie x86-Binärdateien komprimieren.

Alle BCJ-Filter unterstützen die gleichen Optionen:

start=Versatz
gibt den Start-Versatz an, der bei der Umwandlung zwischen relativen und absoluten Adressen verwen‐
det wird. Der Versatz muss ein Vielfaches der Filterausrichtung sein (siehe die Tabelle oben). Der
Standardwert ist 0. In der Praxis ist dieser Standardwert gut; die Angabe eines benutzerdefinierten
Versatzes ist fast immer unnütz.

--delta[=Optionen]
fügt den Delta-Filter zur Filterkette hinzu. Der Delta-Filter kann nicht als letzter Filter in der Filter‐
kette verwendet werden.

Gegenwärtig wird nur eine einfache, Byte-bezogene Delta-Berechnung unterstützt. Beim Komprimieren von zum
Beispiel unkomprimierten Bitmap-Bildern oder unkomprimierten PCM-Audiodaten kann es jedoch sinnvoll sein.
Dennoch können für spezielle Zwecke entworfene Algorithmen deutlich bessere Ergebnisse als Delta und LZMA2
liefern. Dies trifft insbesondere auf Audiodaten zu, die sich zum Beispiel mit flac(1) schneller und
besser komprimieren lassen.

Unterstützte Optionen:

dist=Abstand
gibt den Abstand der Delta-Berechnung in Byte an. Zulässige Werte für den Abstand sind 1 bis 256.
Der Vorgabewert ist 1.

Zum Beispiel wird mit dist=2 und der 8-Byte-Eingabe A1 B1 A2 B3 A3 B5 A4 B7 die Ausgabe A1 B1 01 02
01 02 01 02 sein.

Andere Optionen
-q, --quiet
unterdrückt Warnungen und Hinweise. Geben Sie dies zweimal an, um auch Fehlermeldungen zu unterdrücken.
Diese Option wirkt sich nicht auf den Exit-Status aus. Das bedeutet, das selbst bei einer unterdrückten
Warnung der Exit-Status zur Anzeige einer Warnung dennoch verwendet wird.

-v, --verbose
bewirkt ausführliche Ausgaben. Wenn die Standardfehlerausgabe mit einem Terminal verbunden ist, zeigt xz
den Fortschritt an. Durch zweimalige Angabe von --verbose wird die Ausgabe noch ausführlicher.

Der Fortschrittsanzeiger stellt die folgenden Informationen dar:

• Der Prozentsatz des Fortschritts wird angezeigt, wenn die Größe der Eingabedatei bekannt ist. Das be‐
deutet, dass der Prozentsatz in Weiterleitungen (Pipes) nicht angezeigt werden kann.

• Menge der erzeugten komprimierten Daten (bei der Kompression) oder der verarbeiteten Daten (bei der
Dekompression).

• Menge der verarbeiteten unkomprimierten Daten (bei der Kompression) oder der erzeugten Daten (bei der
Dekompression).

• Kompressionsverhältnis, das mittels Dividieren der Menge der bisher komprimierten Daten durch die Menge
der bisher verarbeiteten unkomprimierten Daten ermittelt wird.

• Kompressions- oder Dekompressionsgeschwindigkeit. Diese wird anhand der Menge der unkomprimierten ver‐
arbeiteten Daten (bei der Kompression) oder der Menge der erzeugten Daten (bei der Dekompression) pro
Sekunde gemessen. Die Anzeige startet einige Sekunden nachdem xz mit der Verarbeitung der Datei be‐
gonnen hat.

• Die vergangene Zeit im Format M:SS oder H:MM:SS.

• Die geschätzte verbleibende Zeit wird nur angezeigt, wenn die Größe der Eingabedatei bekannt ist und
bereits einige Sekunden vergangen sind, nachdem xz mit der Verarbeitung der Datei begonnen hat. Die
Zeit wird in einem weniger präzisen Format ohne Doppelpunkte angezeigt, zum Beispiel 2 min 30 s.

Wenn die Standardfehlerausgabe kein Terminal ist, schreibt xz mit --verbose nach dem Komprimieren oder
Dekomprimieren der Datei in einer einzelnen Zeile den Dateinamen, die komprimierte Größe, die unkomprim‐
ierte Größe, das Kompressionsverhältnis und eventuell auch die Geschwindigkeit und die vergangene Zeit in
die Standardfehlerausgabe. Die Geschwindigkeit und die vergangene Zeit werden nur angezeigt, wenn der Vor‐
gang mindestens ein paar Sekunden gedauert hat. Wurde der Vorgang nicht beendet, zum Beispiel weil ihn der
Benutzer abgebrochen hat, wird außerdem der Prozentsatz des erreichten Verarbeitungsfortschritts aufgenom‐
men, sofern die Größe der Eingabedatei bekannt ist.

-Q, --no-warn
setzt den Exit-Status nicht auf 2, selbst wenn eine Bedingung erfüllt ist, die eine Warnung gerechtfertigt
hätte. Diese Option wirkt sich nicht auf die Ausführlichkeitsstufe aus, daher müssen sowohl --quiet als
auch --no-warn angegeben werden, um einerseits keine Warnungen anzuzeigen und andererseits auch den
Exit-Status nicht zu ändern.

--robot
gibt Meldungen in einem maschinenlesbaren Format aus. Dadurch soll das Schreiben von Frontends erleichtert
werden, die xz anstelle von Liblzma verwenden wollen, was in verschiedenen Skripten der Fall sein kann.
Die Ausgabe mit dieser aktivierten Option sollte über mehrere xz-Veröffentlichungen stabil sein. Details
hierzu finden Sie im Abschnitt ROBOTER-MODUS.

--info-memory
zeigt in einem menschenlesbaren Format an, wieviel physischen Speicher (RAM) und wie viele Prozes‐
sor-Threads das System nach Annahme von xz hat, sowie die Speicherbedarfsbegrenzung für Kompression und
Dekompression, und beendet das Programm erfolgreich.

-h, --help
zeigt eine Hilfemeldung mit den am häufigsten genutzten Optionen an und beendet das Programm erfolgreich.

-H, --long-help
zeigt eine Hilfemeldung an, die alle Funktionsmerkmale von xz beschreibt und beendet das Programm erfol‐
greich.

-V, --version
zeigt die Versionsnummer von xz und Liblzma in einem menschenlesbaren Format an. Um eine maschinell
auswertbare Ausgabe zu erhalten, geben Sie --robot vor --version an.

ROBOTER-MODUS
Der Roboter-Modus wird mit der Option --robot aktiviert. Er bewirkt, dass die Ausgabe von xz leichter von anderen
Programmen ausgewertet werden kann. Gegenwärtig wird --robot nur zusammen mit --version, --info-memory und --list
unterstützt. In der Zukunft wird dieser Modus auch für Kompression und Dekompression unterstützt.

Version
xz --robot --version gibt die Versionsnummern von xz und Liblzma im folgenden Format aus:

XZ_VERSION=XYYYZZZS
LIBLZMA_VERSION=XYYYZZZS

X Hauptversion.

YYY Unterversion. Gerade Zahlen bezeichnen eine stabile Version. Ungerade Zahlen bezeichnen Alpha- oder Be‐
taversionen.

ZZZ Patch-Stufe für stabile Veröffentlichungen oder einfach 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 eine gerade Zahl
ist.

XYYYZZZS sind in beiden Zeilen gleich, sofern xz und Liblzma aus der gleichen Veröffentlichung der XZ-Utils stam‐
men.

Beispiele: 4.999.9beta ist 49990091 und 5.0.0 is 50000002.

Informationen zur Speicherbedarfsbegrenzung
xz --robot --info-memory gibt eine einzelne Zeile mit mehreren durch Tabulatoren getrennten Spalten aus:

1. Gesamter physischer Speicher (RAM) in Byte.

2. Speicherbedarfsbegrenzung für die Kompression in Byte (--memlimit-compress). Ein spezieller Wert von 0 beze‐
ichnet die Standardeinstellung, die im Einzelthread-Modus bedeutet, dass keine Begrenzung vorhanden ist.

3. Speicherbedarfsbegrenzung für die Dekompression in Byte (--memlimit-decompress). Ein spezieller Wert von 0
bezeichnet die Standardeinstellung, die im Einzelthread-Modus bedeutet, dass keine Begrenzung vorhanden ist.

4. Seit xz 5.3.4alpha: Die Speichernutzung für Multithread-Dekompression in Byte (--memlimit-mt-decompress).
Dies ist niemals 0, da ein systemspezifischer Vorgabewert (gezeigt in Spalte 5) verwendet wird, falls keine
Grenze ausdrücklich angegeben wurde. Dies ist außerdem niemals größer als der Wert in in Spalte 3, selbst
wenn mit --memlimit-mt-decompress ein größerer Wert angegeben wurde.

5. Seit xz 5.3.4alpha: Eine systemspezifisch vorgegebene Begrenzung des Speicherverbrauchs, die zur Begrenzung
der Anzahl der Threads beim Komprimieren mit automatischer Anzahl der Threads (--threads=0) und wenn keine
Speicherbedarfsbegrenzung angegeben wurde (--memlimit-compress) verwendet wird. Dies wird auch als Standardw‐
ert für --memlimit-mt-decompress verwendet.

6. Seit xz 5.3.4alpha: Anzahl der verfügbaren Prozessorthreads.

In der Zukunft könnte die Ausgabe von xz --robot --info-memory weitere Spalten enthalten, aber niemals mehr als
eine einzelne Zeile.

Listenmodus
xz --robot --list verwendet eine durch Tabulatoren getrennte Ausgabe. In der ersten Spalte jeder Zeile bezeichnet
eine Zeichenkette den Typ der Information, die in dieser Zeile enthalten ist:

name Dies ist stets die erste Zeile, wenn eine Datei aufgelistet wird. Die zweite Spalte in der Zeile enthält
den Dateinamen.

file Diese Zeile enthält allgemeine Informationen zur .xz-Datei. Diese Zeile wird stets nach der name-Zeile
ausgegeben.

stream Dieser Zeilentyp wird nur verwendet, wenn --verbose angegeben wurde. Es gibt genau so viele stream-Zeilen,
wie Datenströme in der .xz-Datei enthalten sind.

block Dieser Zeilentyp wird nur verwendet, wenn --verbose angegeben wurde. Es gibt so viele block-Zeilen, wie
Blöcke in der .xz-Datei. Die block-Zeilen werden nach allen stream-Zeilen angezeigt; verschiedene Zeilen‐
typen werden nicht verschachtelt.

summary
Dieser Zeilentyp wird nur verwendet, wenn --verbose zwei Mal angegeben wurde. Diese Zeile wird nach allen
block-Zeilen ausgegeben. Wie die file-Zeile enthält die summary-Zeile allgemeine Informationen zur
.xz-Datei.

totals Diese Zeile ist immer die letzte der Listenausgabe. Sie zeigt die Gesamtanzahlen und -größen an.

Die Spalten der file-Zeilen:
2. Anzahl der Datenströme in der Datei
3. Gesamtanzahl der Blöcke in den Datenströmen
4. Komprimierte Größe der Datei
5. Unkomprimierte Größe der Datei
6. Das Kompressionsverhältnis, zum Beispiel 0.123. Wenn das Verhältnis über 9.999 liegt, werden drei Mi‐
nuszeichen (---) anstelle des Kompressionsverhältnisses angezeigt.
7. Durch Kommata getrennte Liste der Namen der Integritätsprüfungen. Für die bekannten Überprüfungstypen
werden folgende Zeichenketten verwendet: None, CRC32, CRC64 und SHA-256. Unbek.N wird verwendet, wobei
N die Kennung der Überprüfung als Dezimalzahl angibt (ein- oder zweistellig).
8. Gesamtgröße der Datenstromauffüllung in der Datei

Die Spalten der stream-Zeilen:
2. Datenstromnummer (der erste Datenstrom ist 1)
3. Anzahl der Blöcke im Datenstrom
4. Komprimierte Startposition
5. Unkomprimierte Startposition
6. Komprimierte Größe (schließt die Datenstromauffüllung nicht mit ein)
7. Unkomprimierte Größe
8. Kompressionsverhältnis
9. Name der Integritätsprüfung
10. Größe der Datenstromauffüllung

Die Spalten der block-Zeilen:
2. Anzahl der in diesem Block enthaltenen Datenströme
3. Blocknummer relativ zum Anfang des Datenstroms (der erste Block ist 1)
4. Blocknummer relativ zum Anfang der Datei
5. Komprimierter Startversatz relativ zum Beginn der Datei
6. Unkomprimierter Startversatz relativ zum Beginn der Datei
7. Komprimierte Gesamtgröße des Blocks (einschließlich Header)
8. Unkomprimierte Größe
9. Kompressionsverhältnis
10. Name der Integritätsprüfung

Wenn --verbose zwei Mal angegeben wurde, werden zusätzliche Spalten in die block-Zeilen eingefügt. Diese werden
mit einem einfachen --verbose nicht angezeigt, da das Ermitteln dieser Informationen viele Suchvorgänge erfordert
und daher recht langsam sein kann:
11. Wert der Integritätsprüfung in hexadezimaler Notation
12. Block-Header-Größe
13. Block-Schalter: c gibt an, dass die komprimierte Größe verfügbar ist, und u gibt an, dass die unkom‐
primierte Größe verfügbar ist. Falls der Schalter nicht gesetzt ist, wird stattdessen ein Bindestrich
(-) angezeigt, um die Länge der Zeichenkette beizubehalten. In Zukunft könnten neue Schalter am Ende
der Zeichenkette hinzugefügt werden.
14. Größe der tatsächlichen komprimierten Daten im Block. Ausgeschlossen sind hierbei die Block-Header,
die Blockauffüllung und die Prüffelder.
15. Größe des Speichers (in Byte), der zum Dekomprimieren dieses Blocks mit dieser xz-Version benötigt
wird.
16. Filterkette. Beachten Sie, dass die meisten der bei der Kompression verwendeten Optionen nicht bekannt
sein können, da in den .xz-Headern nur die für die Dekompression erforderlichen Optionen gespeichert
sind.

Die Spalten der summary-Zeilen:
2. Größe des Speichers (in Byte), der zum Dekomprimieren dieser Datei mit dieser xz-Version benötigt
wird.
3. yes oder no geben an, ob in allen Block-Headern sowohl die komprimierte als auch die unkomprimierte
Größe gespeichert ist.
Seit xz 5.1.2alpha:
4. Minimale xz-Version, die zur Dekompression der Datei erforderlich ist

Die Spalten der totals-Zeile:
2. Anzahl der Datenströme
3. Anzahl der Blöcke
4. Komprimierte Größe
5. Unkomprimierte Größe
6. Durchschnittliches Kompressionsverhältnis
7. Durch Kommata getrennte Liste der Namen der Integritätsprüfungen, die in den Dateien präsent waren.
8. Größe der Datenstromauffüllung
9. Anzahl der Dateien. Dies dient dazu, die Reihenfolge der vorigen Spalten an die in den file-Zeilen
anzugleichen.

Wenn --verbose zwei Mal angegeben wird, werden zusätzliche Spalten in die totals-Zeile eingefügt:
10. Maximale Größe des Speichers (in Byte), der zum Dekomprimieren der Dateien mit dieser xz-Version
benötigt wird.
11. yes oder no geben an, ob in allen Block-Headern sowohl die komprimierte als auch die unkomprimierte
Größe gespeichert ist.
Seit xz 5.1.2alpha:
12. Minimale xz-Version, die zur Dekompression der Datei erforderlich ist

Zukünftige Versionen könnten neue Zeilentypen hinzufügen, weiterhin könnten auch in den vorhandenen Zeilentypen
weitere Spalten hinzugefügt werden, aber die existierenden Spalten werden nicht geändert.

EXIT-STATUS
0 Alles ist in Ordnung.

1 Ein Fehler ist aufgetreten.

2 Es ist etwas passiert, das eine Warnung rechtfertigt, aber es sind keine tatsächlichen Fehler aufgetreten.

In die Standardausgabe geschriebene Hinweise (keine Warnungen oder Fehler), welche den Exit-Status nicht beein‐
flussen.

UMGEBUNGSVARIABLEN
xz wertet eine durch Leerzeichen getrennte Liste von Optionen in den Umgebungsvariablen XZ_DEFAULTS und XZ_OPT
aus (in dieser Reihenfolge), bevor die Optionen aus der Befehlszeile ausgewertet werden. Beachten Sie, dass beim
Auswerten der Umgebungsvariablen nur Optionen berücksichtigt werden; alle Einträge, die keine Optionen sind, wer‐
den stillschweigend ignoriert. Die Auswertung erfolgt mit getopt_long(3), welches auch für die Befehlszeilenargu‐
mente verwendet wird.

XZ_DEFAULTS
Benutzerspezifische oder systemweite Standardoptionen. Typischerweise werden diese in einem Shell-Initial‐
isierungsskript gesetzt, um die Speicherbedarfsbegrenzung von xz standardmäßig zu aktivieren. Außer bei
Shell-Initialisierungsskripten und in ähnlichen Spezialfällen darf die Variable XZ_DEFAULTS in Skripten
niemals gesetzt oder außer Kraft gesetzt werden.

XZ_OPT Dies dient der Übergabe von Optionen an xz, wenn es nicht möglich ist, die Optionen direkt in der Be‐
fehlszeile von xz zu übergeben. Dies ist der Fall, wenn xz von einem Skript oder Dienstprogramm ausgeführt
wird, zum Beispiel GNU tar(1):

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

Skripte können XZ_OPT zum Beispiel zum Setzen skriptspezifischer Standard-Kompressionsoptionen verwenden.
Es ist weiterhin empfehlenswert, Benutzern die Außerkraftsetzung von XZ_OPT zu erlauben, falls dies
angemessen ist. Zum Beispiel könnte in sh(1)-Skripten Folgendes stehen:

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

KOMPATIBILITÄT ZU DEN LZMA-UTILS
Die Befehlszeilensyntax von xz ist praktisch eine Obermenge der von lzma, unlzma und lzcat in den LZMA-Utils der
Versionen 4.32.x. In den meisten Fällen sollte es möglich sein, die LZMA-Utils durch die XZ-Utils zu ersetzen,
ohne vorhandene Skripte ändern zu müssen. Dennoch gibt es einige Inkompatibilitäten, die manchmal Probleme verur‐
sachen können.

Voreinstellungsstufen zur Kompression
Die Nummerierung der Voreinstellungsstufen der Kompression ist in xz und den LZMA-Utils unterschiedlich. Der
wichtigste Unterschied ist die Zuweisung der Wörterbuchgrößen zu den verschiedenen Voreinstellungsstufen. Die
Wörterbuchgröße ist etwa gleich dem Speicherbedarf bei der Dekompression.

Stufe xz LZMA-Utils
-0 256 KiB nicht verfügbar
-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 bei der Kompression, aber es gibt
noch einige andere Unterschiede zwischen den LZMA-Utils und den XZ-Utils, die die Kluft noch vergrößern:

Stufe xz LZMA-Utils 4.32.x
-0 3 MiB nicht verfügbar
-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 standardmäßige Voreinstellungsstufe in den LZMA-Utils ist -7, während diese in den XZ-Utils -6 ist, daher
verwenden beide standardmäßig ein 8 MiB großes Wörterbuch.

Vor- und Nachteile von .lzma-Dateien als Datenströme
Die unkomprimierte Größe der Datei kann in den .lzma-Headern gespeichert werden. Die LZMA-Utils tun das beim Kom‐
primieren gewöhnlicher Dateien. Als Alternative kann die unkomprimierte Größe als unbekannt markiert und eine
Nutzdatenende-Markierung (end-of-payload) verwendet werden, um anzugeben, wo der Dekompressor stoppen soll. Die
LZMA-Utils verwenden diese Methode, wenn die unkomprimierte Größe unbekannt ist, was beispielsweise in Pipes (Be‐
fehlsverkettungen) der Fall ist.

xz unterstützt die Dekompression von .lzma-Dateien mit oder ohne Nutzdatenende-Markierung, aber alle von xz er‐
stellten .lzma-Dateien verwenden diesen Nutzdatenende-Markierung, wobei die unkomprimierte Größe in den
.lzma-Headern als unbekannt markiert wird. Das könnte in einigen unüblichen Situationen ein Problem sein. Zum
Beispiel könnte ein .lzma-Dekompressor in einem Gerät mit eingebettetem System nur mit Dateien funktionieren,
deren unkomprimierte Größe bekannt ist. Falls Sie auf dieses Problem stoßen, müssen Sie die LZMA-Utils oder das
LZMA-SDK verwenden, um .lzma-Dateien mit bekannter unkomprimierter Größe zu erzeugen.

Nicht unterstützte .lzma-Dateien
Das .lzma-Format erlaubt lc-Werte bis zu 8 und lp-Werte bis zu 4. Die LZMA-Utils können Dateien mit beliebigem lc
und lp dekomprimieren, aber erzeugen immer Dateien mit lc=3 und lp=0. Das Erzeugen von Dateien mit anderem lc und
lp ist mit xz und mit dem LZMA-SDK möglich.

Die Implementation des LZMA-Filters in liblzma setzt voraus, dass die Summe von lc und lp nicht größer als 4 ist.
Daher können .lzma-Dateien, welche diese Begrenzung überschreiten, mit xz nicht dekomprimiert werden.

Die LZMA-Utils erzeugen nur .lzma-Dateien mit einer Wörterbuchgröße von 2^n (einer Zweierpotenz), aber akzep‐
tieren Dateien mit einer beliebigen Wörterbuchgröße. Liblzma akzeptiert nur .lzma-Dateien mit einer Wörter‐
buchgröße von 2^n oder 2^n + 2^(n-1). Dies dient zum Verringern von Fehlalarmen beim Erkennen von .lzma-Dateien.

Diese Einschränkungen sollten in der Praxis kein Problem sein, da praktisch alle .lzma-Dateien mit Einstellungen
komprimiert wurden, die Liblzma akzeptieren wird.

Angehängter Datenmüll
Bei der Dekompression ignorieren die LZMA-Utils stillschweigend alles nach dem ersten .lzma-Datenstrom. In den
meisten Situationen ist das ein Fehler. Das bedeutet auch, dass die LZMA-Utils die Dekompression verketteter
.lzma-Dateien nicht unterstützen.

Wenn nach dem ersten .lzma-Datenstrom Daten verbleiben, erachtet xz die Datei als beschädigt, es sei denn, die
Option --single-stream wurde verwendet. Dies könnte die Ausführung von Skripten beeinflussen, die davon ausgehen,
dass angehängter Datenmüll ignoriert wird.

ANMERKUNGEN
Die komprimierte Ausgabe kann variieren
Die exakte komprimierte Ausgabe, die aus der gleichen unkomprimierten Eingabedatei erzeugt wird, kann zwischen
den Versionen der XZ-Utils unterschiedlich sein, selbst wenn die Kompressionsoptionen identisch sind. Das kommt
daher, weil der Kodierer verbessert worden sein könnte (hinsichtlich schnellerer oder besserer Kompression), ohne
das Dateiformat zu beeinflussen. Die Ausgabe kann sogar zwischen verschiedenen Programmen der gleichen Version
der XZ-Utils variieren, wenn bei der Erstellung des Binärprogramms unterschiedliche Optionen verwendet wurden.

Sobald --rsyncable implementiert wurde, bedeutet das, dass die sich ergebenden Dateien nicht notwendigerweise mit
Rsync abgeglichen werden können, außer wenn die alte und neue Datei mit der gleichen xz-Version erzeugt wurden.
Das Problem kann beseitigt werden, wenn ein Teil der Encoder-Implementierung eingefroren wird, um die mit Rsync
abgleichbare Ausgabe über xz-Versionsgrenzen hinweg stabil zu halten.

Eingebettete .xz-Dekompressoren
Eingebettete .xz-Dekompressor-Implementierungen wie XZ Embedded unterstützen nicht unbedingt Dateien, die mit an‐
deren Integritätsprüfungen (Prüfung-Typen) als none und crc32 erzeugt wurden. Da --check=crc64 die Voreinstellung
ist, müssen Sie --check=none oder --check=crc32 verwenden, wenn Sie Dateien für eingebettete Systeme erstellen.

Außerhalb eingebetteter Systeme unterstützen die Dekompressoren des .xz-Formats alle Prüfung-Typen oder sind min‐
destens in der Lage, die Datei zu dekomprimieren, ohne deren Integrität zu prüfen, wenn die bestimmte Prüfung
nicht verfügbar ist.

XZ Embedded unterstützt BCJ-Filter, aber nur mit dem vorgegebenen Startversatz.

BEISPIELE
Grundlagen
Komprimiert die Datei foo mit der Standard-Kompressionsstufe (-6) zu foo.xz und entfernt foo nach erfolgreicher
Kompression:

xz foo

bar.xz in bar dekomprimieren und bar.xz selbst dann nicht löschen, wenn die Dekompression erfolgreich war:

xz -dk bar.xz

baz.tar.xz mit der Voreinstellung -4e (-4 --extreme) erzeugen, was langsamer ist als die Vorgabe -6, aber weniger
Speicher für Kompression und Dekompression benötigt (48 MiB beziehungsweise 5 MiB):

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

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

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

Parallele Kompression von vielen Dateien
Auf GNU- und *BSD-Systemen können find(1) und xargs(1) zum Parallelisieren der Kompression vieler Dateien verwen‐
det werden:

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

Die Option -P von xargs(1) legt die Anzahl der parallelen xz-Prozesse fest. Der beste Wert für die Option -n
hängt davon ab, wie viele Dateien komprimiert werden sollen. Wenn es sich nur um wenige Dateien handelt, sollte
der Wert wahrscheinlich 1 sein; bei Zehntausenden von Dateien kann 100 oder noch mehr angemessener sein, um die
Anzahl der xz-Prozesse zu beschränken, die xargs(1) schließlich erzeugen wird.

Die Option -T1 für xz dient dazu, den Einzelthread-Modus zu erzwingen, da xargs(1) zur Steuerung des Umfangs der
Parallelisierung verwendet wird.

Roboter-Modus
Berechnen, wie viel Byte nach der Kompression mehrerer Dateien insgesamt eingespart wurden:

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

Ein Skript könnte abfragen wollen, ob es ein xz verwendet, das aktuell genug ist. Das folgende sh(1)-Skript
prüft, ob die Versionsnummer des Dienstprogramms xz mindestens 5.0.0 ist. Diese Methode ist zu alten Beta-Versio‐
nen kompatibel, welche die Option --robot nicht unterstützen:

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

Eine Speicherbedarfsbegrenzung für die Dekompression mit XZ_OPT setzen, aber eine bereits gesetzte Begrenzung
nicht erhöhen:

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 Filterketten für die Kompression
Der einfachste Anwendungsfall für benutzerdefinierte Filterketten ist die Anpassung von LZMA2-Voreinstel‐
lungsstufen. Das kann nützlich sein, weil die Voreinstellungen nur einen Teil der potenziell sinnvollen Kombina‐
tionen aus Kompressionseinstellungen abdecken.

Die KompCPU-Spalten der Tabellen aus den Beschreibungen der Optionen -0 … -9 und --extreme sind beim Anpassen der
LZMA2-Voreinstellungen nützlich. Diese sind die relevanten Teile aus diesen zwei Tabellen:

Voreinst. KomprCPU
-0 0
-1 1
-2 2
-3 3
-4 4
-5 5
-6 6
-5e 7
-6e 8

Wenn Sie wissen, dass eine Datei für eine gute Kompression ein etwas größeres Wörterbuch benötigt (zum Beispiel
32 MiB), aber Sie sie schneller komprimieren wollen, als dies mit xz -8 geschehen würde, kann eine Voreinstellung
mit einem niedrigen KompCPU-Wert (zum Beispiel 1) dahingehend angepasst werden, ein größeres Wörterbuch zu ver‐
wenden:

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

Mit bestimmten Dateien kann der obige Befehl schneller sein als xz -6, wobei die Kompression deutlich besser
wird. Dennoch muss betont werden, dass nur wenige Dateien von einem größeren Wörterbuch profitieren, wenn der
KompCPU-Wert niedrig bleibt. Der offensichtlichste Fall, in dem ein größeres Wörterbuch sehr hilfreich sein
kann, ist ein Archiv, das einander sehr ähnliche Dateien enthält, die jeweils wenigstens einige Megabyte groß
sind. Das Wörterbuch muss dann deutlich größer sein als die einzelne Datei, damit LZMA2 den größtmöglichen
Vorteil aus den Ähnlichkeiten der aufeinander folgenden Dateien zieht.

Wenn hoher Speicherbedarf für Kompression und Dekompression kein Problem ist und die zu komprimierende Datei min‐
destens einige Hundert Megabyte groß ist, kann es sinnvoll sein, ein noch größeres Wörterbuch zu verwenden, als
die 64 MiB, die mit xz -9 verwendet werden würden:

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

Die Verwendung von -vv (--verbose --verbose) wie im obigen Beispiel kann nützlich sein, um den Speicherbedarf für
Kompressor und Dekompressor zu sehen. Denken Sie daran, dass ein Wörterbuch, das größer als die unkomprimierte
Datei ist, Speicherverschwendung wäre. Daher ist der obige Befehl für kleine Dateien nicht sinnvoll.

Manchmal spielt die Kompressionszeit keine Rolle, aber der Speicherbedarf bei der Dekompression muss gering
gehalten werden, zum Beispiel um die Datei auf eingebetteten Systemen dekomprimieren zu können. Der folgende Be‐
fehl verwendet -6e (-6 --extreme) als Basis und setzt die Wörterbuchgröße auf nur 64 KiB. Die sich ergebende
Datei kann mit XZ Embedded (aus diesem Grund ist dort --check=crc32) mit nur etwa 100 KiB Speicher dekomprimiert
werden.

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

Wenn Sie so viele Byte wie möglich herausquetschen wollen, kann die Anpassung der Anzahl der literalen Kon‐
textbits (lc) und der Anzahl der Positionsbits (pb) manchmal hilfreich sein. Auch die Anpassung der Anzahl der
literalen Positionsbits (lp) könnte helfen, aber üblicherweise sind lc und pb wichtiger. Wenn ein Quell‐
code-Archiv zum Beispiel hauptsächlich ASCII-Text enthält, könnte ein Aufruf wie der folgende eine etwas kleinere
Datei (etwa 0,1 %) ergeben als mit xz -6e (versuchen Sie es auch lc=4):

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

Die Verwendung eines anderen Filters mit LZMA2 kann die Kompression bei verschiedenen Dateitypen verbessern. So
könnten Sie eine gemeinsam genutzte Bibliothek der Architekturen x86-32 oder x86-64 mit dem BCJ-Filter für x86
komprimieren:

xz --x86 --lzma2 libfoo.so

Beachten Sie, dass die Reihenfolge der Filteroptionen von Bedeutung ist. Falls --x86 nach --lzma2 angegeben wird,
gibt xz einen Fehler aus, weil nach LZMA2 kein weiterer Filter sein darf und auch weil der BCJ-Filter für x86
nicht als letzter Filter in der Filterkette gesetzt werden darf.

Der Delta-Filter zusammen mit LZMA2 kann bei Bitmap-Bildern gute Ergebnisse liefern. Er sollte üblicherweise
besser sein als PNG, welches zwar einige fortgeschrittene Filter als ein simples delta bietet, aber für die
eigentliche Kompression »Deflate« verwendet.

Das Bild muss in einem unkomprimierten Format gespeichert werden, zum Beispiel als unkomprimiertes TIFF. Der Ab‐
standsparameter des Delta-Filters muss so gesetzt werden, dass er der Anzahl der Bytes pro Pixel im Bild
entspricht. Zum Beispiel erfordert ein 24-Bit-RGB-Bitmap dist=3, außerdem ist es gut, pb=0 an LZMA2 zu übergeben,
um die 3-Byte-Ausrichtung zu berücksichtigen:

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

Wenn sich mehrere Bilder in einem einzelnen Archiv befinden (zum Beispiel .tar), funktioniert der Delta-Filter
damit auch, sofern alle Bilder im Archiv die gleiche Anzahl Bytes pro Pixel haben.

SIEHE AUCH
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>

Tukaani 17. Juli 2023 XZ(1)