XZ(1) XZ-Dienstprogramme XZ(1)
BEZEICHNUNG
xz, unxz, xzcat, lzma, unlzma, lzcat - .xz- und .lzma-Dateien kompri-
mieren 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 Argumenten (xz -d oder xz
-dc) anstelle der Namen unxz und xzcat verwenden.
BESCHREIBUNG
xz ist ein Allzweckwerkzeug zur Datenkompression, dessen Befehlszeilen-
syntax 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 Containerfor-
mat-Header werden ebenfalls unterstützt. Außerdem wird die Dekompres-
sion des von lzip verwendeten .lz-Formats unterstützt.
xz komprimiert oder dekomprimierte jede Datei entsprechend des gewähl-
ten Vorgangsmodus. Falls entweder - oder keine Datei angegeben ist,
liest xz aus der Standardeingabe und leitet die verarbeiteten Dateien
in die Standardausgabe. Wenn die Standardausgabe kein Terminal ist,
verweigert xz das Schreiben komprimierter Daten in die Standardausgabe.
Dabei wird eine Fehlermeldung angezeigt und die Datei übersprungen.
Ebenso verweigert xz das Lesen komprimierter Daten aus der Standardein-
gabe, wenn diese ein Terminal ist.
Dateien, die nicht als - angegeben sind, werden in eine neue Datei ge-
schrieben, deren Name aus den 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 Datei-
namen entfernt und so der Name der Zieldatei gebildet. Außerdem er-
kennt 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 zutref-
fend ist:
• Die Datei ist keine reguläre Datei. Symbolischen Verknüpfungen wird
nicht gefolgt und 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 ge-
setzt.
• Der Aktionsmodus wird auf Kompression gesetzt und die Datei hat be-
reits das Suffix des Zieldateiformats (.xz oder .txz beim Komprimie-
ren 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, Zugriffszeit und Änderungszeit aus
der Ursprungs-Datei in die Zieldatei. Sollte das Kopieren der Gruppe
fehlschlagen, werden die Zugriffsrechte so angepasst, dass jenen Benut-
zern der Zugriff auf die Zieldatei verwehrt bleibt, die auch keinen Zu-
griff 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 Ur-
sprungs-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 gelei-
tet. Dies ist nur eingeschränkt hilfreich, wenn die Standardfehleraus-
gabe ein Terminal ist. Mittels --verbose wird ein automatisch aktuali-
sierter 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 Speichers, der bei der
Kompression der Datei erforderlich war. Beispielsweise benötigt die De-
kompression einer Datei, die mit xz -9 komprimiert wurde, gegenwärtig
etwa 65 MiB Speicher. Es ist jedoch auch möglich, dass .xz-Dateien meh-
rere Gigabyte an Speicher zur Dekompression erfordern.
Insbesondere für Benutzer älterer Systeme wird eventuell ein sehr gro-
ßer Speicherbedarf ärgerlich sein. Um unangenehme Überraschungen zu
vermeiden, verfügt xz über eine eingebaute Begrenzung des Speicherbe-
darfs, die allerdings in der Voreinstellung deaktiviert ist. Zwar ver-
fügen einige Betriebssysteme über eingebaute Möglichkeiten zur prozess-
abhängigen Speicherbegrenzung, doch diese sind zu unflexibel (zum Bei-
spiel kann ulimit(1) beim Begrenzen 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 aktivieren, zum Beispiel XZ_DEFAULTS=--memlimit=150MiB. Die Begren-
zungen können getrennt für Kompression und Dekompression mittels --mem-
limit-compress=Begrenzung und --memlimit-decompress=Begrenzung festge-
legt werden. Die Verwendung einer solchen Option außerhalb der Variable
XZ_DEFAULTS ist kaum sinnvoll, da xz in einer einzelnen Aktion nicht
gleichzeitig Kompression und Dekompression ausführen kann und --memli-
mit=Begrenzung (oder -M Begrenzung) lässt sich einfacher in der Be-
fehlszeile eingeben.
Wenn die angegebene Speicherbegrenzung bei der Dekompression über-
schritten wird, schlägt der Vorgang fehl und xz zeigt eine Fehlermel-
dung an. Wird die Begrenzung bei der Kompression überschritten, dann
versucht xz die Einstellungen 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 vorgenom-
men, allerdings entsprechen die Schritte nicht den Voreinstellungen der
Kompressionsstufen. 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 Tei-
len 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 Datei-
größ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 Ganzzahlwerte einfacher darstellen.
Zwischen Ganzzahl und dem Suffix dürfen sich keine Leerzeichen befin-
den.
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 dazu verwendet werden, um den von der je-
weiligen Option akzeptierten maximalen Ganzzahlwert 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 bestimmter Modus aus dem Be-
fehlsnamen abgeleitet werden kann (der Befehl unxz impliziert
zum Beispiel --decompress).
-d, --decompress, --uncompress
dekomprimpiert.
-t, --test
prüft die Integrität der komprimierten Dateien. Diese Option ist
gleichbedeutend mit --decompress --stdout, außer dass die dekom-
primierten Daten verworfen werden, anstatt sie in die Standard-
ausgabe zu leiten. Es werden keine Dateien erstellt oder ent-
fernt.
-l, --list
gibt Informationen zu den komprimierten Dateien aus. Es werden
keine unkomprimierten Dateien ausgegeben und keine Dateien ange-
legt oder entfernt. Im Listenmodus kann das Programm keine kom-
primierten Daten aus der Standardeingabe oder anderen nicht
durchsuchbaren Quellen lesen.
Die Liste zeigt in der Standardeinstellung grundlegende Informa-
tionen 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 Infor-
mationen ausgegeben. Das kann den Vorgang allerdings deutlich
verlangsamen, da die Ermittlung der zusätzlichen Informationen
zahlreiche Suchvorgänge erfordert. Die Breite der ausführlichen
Ausgabe ist breiter als 80 Zeichen, daher könnte die Weiterlei-
tung 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 Dekompres-
sion 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 Kom-
pression oder Dekompression gelöscht.
• Die Kompression oder Dekompression wird auch dann ausgeführt,
wenn die Eingabe ein symbolischer Link zu einer regulären Da-
tei 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 ermitteln kann, wird die
Quelldatei unverändert in die Standardausgabe kopiert. Da-
durch kann xzcat --force für Dateien, die nicht mit xz kom-
primiert wurden, wie cat(1) verwendet werden. Zukünftig
könnte xz neue Dateikompressionsformate unterstützen, wodurch
xz mehr Dateitypen dekomprimieren kann, anstatt sie unverän-
dert in die Standardausgabe zu kopieren. Mit der Option
--format=Format können Sie xz anweisen, nur ein einzelnes Da-
teiformat 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 still-
schweigend weitere Eingabedaten, die möglicherweise dem Daten-
strom folgen. Normalerweise führt solcher anhängender Datenmüll
dazu, dass xz eine Fehlermeldung ausgibt.
xz dekomprimiert niemals mehr als einen Datenstrom aus .lzma-Da-
teien 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 --de-
compress oder --test ist.
--no-sparse
verhindert die Erzeugung von Sparse-Dateien. In der Voreinstel-
lung 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 Zusatzbedingun-
gen erfüllt sind, die die Aktion absichern. Die Erzeugung von
Sparse-Dateien kann Plattenplatz sparen und beschleunigt die De-
kompression 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 die-
ses 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 Standardein-
gabe gelesen. Dateinamen müssen mit einem Zeilenumbruch beendet
werden. Ein Bindestrich (-) wird als regulärer Dateiname angese-
hen und nicht als Standardeingabe interpretiert. Falls Dateina-
men außerdem als Befehlszeilenargumente angegeben sind, werden
diese vor den Dateinamen aus der Datei verarbeitet.
--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 Dekompression wird das
Format der Eingabedatei automatisch erkannt. Beachten
Sie, dass Rohdatenströme, wie sie mit --format=raw er-
zeugt werden, nicht automatisch erkannt werden können.
xz Die Kompression erfolgt in das .xz-Dateiformat oder ak-
zeptiert nur .xz-Dateien bei der Dekompression.
lzma, alone
Die Kompression erfolgt in das veraltete .lzma-Dateifor-
mat oder akzeptiert nur .lzma-Dateien bei der Dekompres-
sion. Der alternative Name alone dient der Abwärtskompa-
tibilität zu den LZMA-Dienstprogrammen.
lzip Akzeptiert nur .lz-Dateien bei der Dekompression. Kom-
pression wird nicht unterstützt.
Das .lz-Format wird in Version 0 und der unerweiterten
Version 1 unterstützt. Dateien der Version 0 wurden 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öffent-
licht wurden. Es ist auch möglich, dass Benutzer alte
persönliche Dateien in diesem Format haben. Die Dekom-
pressionsunterstü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 For-
matversion 1 wurde in lzip 1.6 hinzugefügt. Diese Erwei-
terung wird sehr selten verwendet 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 fortgeschrittene Benut-
zer bestimmt. Zum Dekodieren von Rohdatenströmen müssen
Sie die Option --format=raw verwenden und die Filterkette
ausdrücklich angeben, die normalerweise in den (hier feh-
lenden) 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 gespei-
chert. Diese Option wird nur bei der Kompression in das .xz-For-
mat 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 wer-
den 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 Da-
teien 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 wer-
den weiterhin normal verifiziert.
Verwenden Sie diese Option nicht, außer Sie wissen, was Sie tun.
Mögliche Gründe, diese Option zu verwenden:
• Versuchen, Daten aus einer beschädigten .xz-Datei wiederher-
zustellen.
• 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 Inte-
gritä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 benutzer-
definierte Filterkette angegeben wurde, wird diese durch die
Festlegung der Voreinstellung geleert.
Die Unterschiede zwischen den Voreinstellungsstufen sind deutli-
cher als bei gzip(1) und bzip2(1). Die gewählten Kompressions-
einstellungen bestimmen den Speicherbedarf bei der Dekompres-
sion, daher ist es auf älteren Systemen mit wenig Speicher bei
einer zu hoch gewählten Voreinstellung schwer, eine Datei zu de-
komprimieren. 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 manch-
mal schneller als gzip -9, wobei aber die Kompression we-
sentlich besser ist. Die schnelleren Voreinstellungen
sind im Hinblick auf die Geschwindigkeit mit bzip2(1)
vergleichbar , mit einem ähnlichen oder besseren Kompres-
sionsverhältnis, 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 akzepta-
bel 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
dekomprimiert 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 komprimierter Daten pro Se-
kunde. Anders ausgedrückt: Je besser die Kompression, umso
schneller wird üblicherweise die Dekompression sein. Das bedeu-
tet auch, dass die Menge der pro Sekunde ausgegebenen unkompri-
mierten Daten stark variieren kann.
Die folgende Tabelle fasst die Eigenschaften der Voreinstellun-
gen 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 Spei-
cherverschwendung, ein Wörterbuch zu verwenden, das größer
als die unkomprimierte Datei ist. Daher ist es besser, die
Voreinstellungen -7 … -9 zu vermeiden, falls es keinen wirk-
lichen Bedarf dafür gibt. Mit -6 und weniger wird üblicher-
weise so wenig Speicher verschwendet, dass dies nicht ins Ge-
wicht fällt.
• KomprCPU ist eine vereinfachte Repräsentation der LZMA2-Ein-
stellungen, welche die Kompressionsgeschwindigkeit beeinflus-
sen. Die Wörterbuchgröße wirkt sich ebenfalls auf die Ge-
schwindigkeit 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 Ein-
zel-Thread-Modus. Dieser kann zwischen den xz-Versionen
leicht variieren. Der Speicherbedarf einiger der zukünftigen
Multithread-Modi kann dramatisch höher sein als im Ein-
zel-Thread-Modus.
• DekompSpeich enthält den Speicherbedarf für die Dekompres-
sion. Das bedeutet, dass die Kompressionseinstellungen den
Speicherbedarf bei der Dekompression bestimmen. Der exakte
Speicherbedarf bei der Dekompression ist geringfügig größer
als die Größe des LZMA2-Wörterbuchs, aber die Werte in der
Tabelle wurden auf ganze MiB aufgerundet.
-e, --extreme
verwendet eine langsamere Variante der gewählten Kompressi-
ons-Voreinstellungsstufe (-0 … -9), um hoffentlich ein etwas
besseres Kompressionsverhältnis zu erreichen, das aber in ungün-
stigen Fällen auch schlechter werden kann. Der Speicherverbrauch
bei der Dekompression wird dabei nicht beeinflusst, aber der
Speicherverbrauch der Kompression steigt in den Voreinstellungs-
stufen -0 bis -3 geringfügig an.
Da es zwei Voreinstellungen mit den Wörterbuchgrößen 4 MiB und
8 MiB gibt, verwenden die Voreinstellungsstufen -3e und -5e et-
was schnellere Einstellungen (niedrigere KompCPU) als -4e bezie-
hungsweise -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-Dienstpro-
grammen 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än-
gig voneinander komprimiert, was dem Multi-Threading entgegen
kommt und Zufallszugriffe bei der Dekompression begrenzt. Diese
Option wird typischerweise eingesetzt, um die vorgegebene Block-
größe im Multi-Thread-Modus außer Kraft zu setzen, aber sie kann
auch im Einzel-Thread-Modus angewendet werden.
Im Multi-Thread-Modus wird etwa die dreifache Größe in jedem
Thread zur Pufferung der Ein- und Ausgabe belegt. Die vorgege-
bene 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 wenig-
stens 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-De-
kompression genutzt wird.
Im Einzel-Thread-Modus werden die Blöcke standardmäßig nicht ge-
teilt. Das Setzen dieser Option wirkt sich nicht auf den Spei-
cherbedarf aus. In den Block-Headern werden keine Größeninforma-
tionen gespeichert, daher werden im Einzel-Thread-Modus erzeugte
Dateien nicht zu den im Multi-Thread-Modus erzeugten Dateien
identisch 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 angegebe-
nen 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 zu-
sätzliche Blöcke erzeugen, wobei die in den Größen angegebenen
Grenzen eingehalten werden. Wenn Sie zum Beispiel
--block-size=10MiB --block-list=5MiB,10MiB,8MiB,12MiB,24MiB an-
geben 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-Hea-
dern 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 En-
coder 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 ver-
wendet werden, um dieses Funktionsmerkmal explizit zu deaktivie-
ren.
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 automatische Anpassung vorgenommen wurde. Die An-
passungen werden in folgender Reihenfolge angewendet: Reduzie-
rung 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örterbuchs.
Beim Komprimieren mit --format=raw oder falls --no-adjust ange-
geben 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 An-
passungen 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-com-
press=80MiB.
• Die Grenze kann als Prozentsatz des physischen Gesamtspei-
chers (RAM) angegeben werden. Dies ist insbesondere nützlich,
wenn in einem Shell-Initialisierungsskript, das mehrere un-
terschiedliche Rechner gemeinsam verwenden, die Umgebungsva-
riable XZ_DEFAULTS gesetzt ist. Auf diese Weise ist die
Grenze auf Systemen mit mehr Speicher höher. Beispiel: --mem-
limit-compress=70%
• Mit 0 kann die Grenze auf den Standardwert zurückgesetzt wer-
den. 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 ge-
setzt. Auf MIPS32 wird stattdessen 2000 MB verwendet (die Werte
0 und max werden hiervon nicht beeinflusst; für die Dekompres-
sion gibt es keine vergleichbare Funktion). Dies kann hilfreich
sein, wenn ein 32-Bit-Executable auf einen 4 GiB großen Adress-
raum (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 Dekompres-
sion fest. Dies beeinflusst auch den Modus --list. Falls die Ak-
tion nicht ausführbar ist, ohne die Grenze zu überschreiten,
gibt xz eine Fehlermeldung aus und die Dekompression wird fehl-
schlagen. Siehe --memlimit-compress=Grenze zu möglichen Wegen,
die Grenze anzugeben.
--memlimit-mt-decompress=Grenze
legt eine Begrenzung des Speicherverbrauchs für Multithread-De-
kompression 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-mo-
dus fort. Beachten Sie auch, dass bei der Verwendung von --mem-
limit-decompress dies stets sowohl auf den Einzelthread-als auch
auf den Multithread-Modus angewendet wird und so die effektive
Grenze für den Multithread-Modus niemals höher sein wird als die
mit --memlimit-decompress gesetzte Grenze.
Im Gegensatz zu anderen Optionen zur Begrenzung des Speicherver-
brauchs hat --memlimit-mt-decompress=Grenze eine systemspezi-
fisch vorgegebene Grenze. Mit xz --info-memory können Sie deren
aktuellen Wert anzeigen lassen.
Diese Option und ihr Standardwert existieren, weil die unbe-
grenzte threadbezogene Dekompression bei einigen 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 ei-
nen 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 Auslagerung verbessern die Dekomprimierungs-
leistung nicht.
Siehe --memlimit-compress=Grenze für mögliche Wege zur Angabe
der Grenze. Sezen der Grenze auf 0 setzt die Grenze auf den vor-
gegebenen systemspezifischen Wert zurück.
-M Grenze, --memlimit=Grenze, --memory=Grenze
Dies ist gleichbedeutend mit --memlimit-compress=Grenze --memli-
mit-decompress=Grenze --memlimit-mt-decompress=Grenze.
--no-adjust
zeigt einen Fehler an und beendet, falls die Grenze der Spei-
chernutzung nicht ohne Änderung der Einstellungen, welche die
komprimierte Ausgabe beeinflussen, berücksichtigt werden kann.
Das bedeutet, dass xz daran gehindert wird, den Encoder vom Mul-
tithread-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 redu-
ziert werden, um die Grenze der Speichernutzung zu halten, so-
fern 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 setzen, verwendet xz maximal
so viele Threads, wie der/die Prozessor(en) im System untestüt-
zen. Die tatsächliche Anzahl kann geringer sein als die angege-
benen Threads, wenn die Eingabedatei nicht groß genug für Threa-
ding mit den gegebenen Einstellungen ist oder wenn mehr Threads
die Speicherbegrenzung übersteigen würden.
Die Multithread- bzw. Einzelthread-Kompressoren erzeugen unter-
schiedliche Ausgaben. Der Einzelthread-Kompressor erzeugt die
geringste Dateigröße, aber nur die Ausgabe des Multithread-Kom-
pressors kann mit mehreren Threads wieder dekomprimiert werden.
Das Setzen der Anzahl der Threads auf 1 wird den Ein-
zelthread-Modus verwenden. Das Setzen der Anzahl der Threads auf
einen anderen Wert einschließlich 0 verwendet den Multi-
thread-Kompressor, und zwar sogar dann, wenn das System nur ei-
nen einzigen Hardware-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 ver-
wenden, 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 Ein-
zelthread-Modus zu verwenden, außer wenn --no-adjust verwendet
wird. Die Unterstützung für das Präfix + wurde in xz 5.4.0 hin-
zugefügt.
Falls das automatische Setzen der Anzahl der Threads angefordert
und keine Speicherbegrenzung angegeben wurde, dann wird eine sy-
stemspezifisch 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 Ein-
zelthread-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 vorge-
gebene Blockgröße ist von der Kompressionsstufe abhängig und
kann mit der Option --block-size=Größe außer Kraft gesetzt wer-
den.
Eine thread-basierte Dekompression wird nur bei Dateien funktio-
nieren, die mehrere Blöcke mit Größeninformationen in deren Hea-
dern enthalten. Alle im Multi-Thread-Modus komprimierten Da-
teien, die groß genug sind, erfüllen diese Bedingung, im Ein-
zel-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 Voreinstellungsoption
nach einer oder mehreren benutzerdefinierten Filterkettenoptionen ange-
geben wird, dann wird die neue Voreinstellung wirksam und die zuvor an-
gegebenen Filterkettenoptionen werden außer Kraft gesetzt.
Eine Filterkette ist mit dem Piping (der Weiterleitung) in der Befehls-
zeile vergleichbar. Bei der Kompression gelangt die unkomprimierte Ein-
gabe in den ersten Filter, dessen Ausgabe wiederum in den zweiten Fil-
ter 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 be-
steht eine Filterkette nur aus einem oder zwei Filtern.
Bei vielen Filtern ist die Positionierung in der Filterkette einge-
schränkt: Einige Filter sind nur als letzte in der Kette verwendbar,
einige können nicht als letzte Filter gesetzt werden, und andere funk-
tionieren an beliebiger Stelle. Abhängig von dem Filter ist diese Be-
schrä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 Fil-
teroptionen 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 (--for-
mat=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 anzuge-
ben, die Sie ändern wollen.
Um die gesamte Filterkette und die Optionen anzuzeigen, rufen Sie xz
-vv auf (was gleichbedeutend mit der zweimaligen Angabe von --verbose
ist). Dies funktioniert auch zum Betrachten der von den Voreinstellun-
gen verwendeten Filterkettenoptionen.
--lzma1[=Optionen]
--lzma2[=Optionen]
fügt LZMA1- oder LZMA2-Filter zur Filterkette hinzu. Diese Fil-
ter können nur als letzte Filter in der Kette verwendet werden.
LZMA1 ist ein veralteter Filter, welcher nur wegen des veralte-
ten .lzma-Dateiformats unterstützt wird, welches nur LZMA1 un-
terstützt. LZMA2 ist eine aktualisierte Version von LZMA1, wel-
che einige praktische Probleme von LZMA1 behebt. Das .xz-Format
verwendet LZMA2 und unterstützt LZMA1 gar nicht. Kompressionsge-
schwindigkeit 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 Voreinstel-
lung zurück. Diese Voreinstellung wird in Form einer
Ganzzahl angegeben, der ein aus einem einzelnen Buchsta-
ben bestehender Voreinstellungsmodifikator folgen kann.
Die Ganzzahl kann 0 bis 9 sein, entsprechend den Befehls-
zeilenoptionen -0 … -9. Gegenwärtig ist e der einzige un-
terstützte Modifikator, was --extreme entspricht. Wenn
keine Voreinstellung angegeben ist, werden die Standard-
werte 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 unkomprimierten Da-
ten im Speicher behalten werden sollen. Der Algorithmus
versucht, sich wiederholende Byte-Abfolgen (Übereinstim-
mungen) in den unkomprimierten Daten zu finden und diese
durch Referenzen zu den Daten zu ersetzen, die sich ge-
genwärtig im Wörterbuch befinden. Je größer das Wörter-
buch, umso größer ist die Chance, eine Übereinstimmung zu
finden. Daher bewirkt eine Erhöhung der Größe des Wörter-
buchs üblicherweise ein besseres Kompressionsverhältnis,
aber ein Wörterbuch, das größer ist als die unkompri-
mierte Datei, wäre Speicherverschwendung.
Typische Wörterbuch-Größen liegen im Bereich von 64 KiB
bis 64 MiB. Das Minimum ist 4 KiB. Das Maximum 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 Speicherverbrauch des LZMA1-
oder LZMA2-Kodierers. Bei der Dekompression ist ein Wör-
terbuch der gleichen Größe (oder ein noch größeres) wie
bei der Kompression erforderlich, daher wird der Spei-
cherverbrauch 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 wer-
den 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öch-
sten lc-Bits des zuvor unkomprimierten Bytes mit dem
nächsten Byte in Beziehung stehen. Zum Beispiel folgt in
typischen englischsprachigen Texten auf einen Großbuch-
staben ein Kleinbuchstabe und auf einen Kleinbuchstaben
üblicherweise wieder ein Kleinbuchstabe. Im US-ASCII-Zei-
chensatz sind die höchsten drei Bits 010 für Großbuchsta-
ben 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, versuchen Sie
lc=4. Manchmal hilft es ein wenig, doch manchmal ver-
schlechtert es die Kompression. Im letzteren Fall versu-
chen Sie zum Beispiel auch lc=2.
lp=lp gibt die Anzahl der literalen Positionsbits an. Das Mini-
mum ist 0 und das Maximum 4; die Vorgabe ist 0.
Lp beeinflusst, welche Art der Ausrichtung der unkompri-
mierten 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 unkompri-
mierten 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ät-
zung 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 ange-
passt werden kann, bevorzugen LZMA1 und LZMA2 noch etwas
die 16-Byte-Ausrichtung. Das sollten Sie vielleicht beim
Design von Dateiformaten berücksichtigen, die wahrschein-
lich 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 Übereinstimmungsfinder schneller
als jene, die mit Binärbäumen arbeiten. Die Vorgabe hängt
von der Voreinstellungsstufe ab: 0 verwendet hc3, 1-3
verwenden hc4 und der Rest verwendet bt4.
Die folgenden Übereinstimmungsfinder werden unterstützt.
Die Formeln zur Ermittlung des Speicherverbrauchs 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 Übereinstim-
mungsfinder gelieferten Daten an. Als Modi werden fast
und normal unterstützt. Die Vorgabe ist fast für die Vor-
einstellungsstufen 0-3 und normal für die Voreinstel-
lungsstufen 4-9.
Üblicherweise wird fast mit Hashketten-basierten Überein-
stimmungsfindern und normal mit Binärbaum-basierten Über-
einstimmungsfindern verwendet. So machen es auch die Vor-
einstellungsstufen.
nice=nice
gibt an, was als annehmbarer Wert für eine Übereinstim-
mung angesehen werden kann. Wenn eine Übereinstimmung ge-
funden wird, die mindestens diesen nice-Wert hat, sucht
der Algorithmus nicht weiter nach besseren Übereinstim-
mungen.
Der nice-Wert kann 2-273 Byte sein. Höhere Werte tendie-
ren zu einem besseren Kompressionsverhältnis, 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 Kom-
pressor 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 Filter in der Filterkette
verwendet werden.
Ein BCJ-Filter wandelt relative Adressen im Maschinencode in de-
ren 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 etwas schlechter werden
könnte. Die BCJ-Filter sind sehr schnell und verbrauchen nur we-
nig mehr Speicher.
Diese BCJ-Filter haben bekannte Probleme mit dem Kompressions-
verhältnis:
• In einigen Dateitypen, die ausführbaren Code enthalten (zum
Beispiel Objektdateien, statische Bibliotheken und Linux-Ker-
nelmodule), sind die Adressen in den Anweisungen mit Füllwer-
ten gefüllt. Diese BCJ-Filter führen dennoch die Adressum-
wandlung 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ühr-
barer 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 situationsbe-
zogen besser ist.
Verschiedene Befehlssätze haben unterschiedliche Ausrichtungen:
Die ausführbare Datei muss in den Eingabedateien einem Vielfa-
chen dieses Wertes entsprechen, damit dieser Filter funktio-
niert.
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 bil-
det dabei eine Ausnahme; Sie sollten bei der für LZMA2 voreinge-
stellten 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 zwi-
schen relativen und absoluten Adressen verwendet 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 Filterkette verwendet wer-
den.
Gegenwärtig wird nur eine einfache, Byte-bezogene Delta-Berech-
nung unterstützt. Beim Komprimieren von zum Beispiel unkompri-
mierten 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äs-
sige Werte für den Abstand sind 1 bis 256. Der Vorgabe-
wert 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 ei-
ner unterdrückten Warnung der Exit-Status zur Anzeige einer War-
nung 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 aus-
führlicher.
Der Fortschrittsanzeiger stellt die folgenden Informationen dar:
• Der Prozentsatz des Fortschritts wird angezeigt, wenn die
Größe der Eingabedatei bekannt ist. Das bedeutet, 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 Kom-
pression) oder der erzeugten Daten (bei der Dekompression).
• Kompressionsverhältnis, das mittels Dividieren der Menge der
bisher komprimierten Daten durch die Menge der bisher verar-
beiteten unkomprimierten Daten ermittelt wird.
• Kompressions- oder Dekompressionsgeschwindigkeit. Diese wird
anhand der Menge der unkomprimierten verarbeiteten Daten (bei
der Kompression) oder der Menge der erzeugten Daten (bei der
Dekompression) pro Sekunde gemessen. Die Anzeige startet ei-
nige 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 Sekun-
den 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 Da-
tei in einer einzelnen Zeile den Dateinamen, die komprimierte
Größe, die unkomprimierte Größe, das Kompressionsverhältnis und
eventuell auch die Geschwindigkeit und die vergangene Zeit in
die Standardfehlerausgabe. Die Geschwindigkeit und die vergan-
gene Zeit werden nur angezeigt, wenn der Vorgang 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 aufge-
nommen, 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 einer-
seits 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 an-
stelle von Liblzma verwenden wollen, was in verschiedenen Skrip-
ten der Fall sein kann. Die Ausgabe mit dieser aktivierten Op-
tion sollte über mehrere xz-Veröffentlichungen stabil sein. De-
tails hierzu finden Sie im Abschnitt ROBOTER-MODUS.
--info-memory
zeigt in einem menschenlesbaren Format an, wieviel physischen
Speicher (RAM) und wie viele Prozessor-Threads das System nach
Annahme von xz hat, sowie die Speicherbedarfsbegrenzung für Kom-
pression und Dekompression, und beendet das Programm erfolg-
reich.
-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 erfolgreich.
-V, --version
zeigt die Versionsnummer von xz und Liblzma in einem menschen-
lesbaren 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. Un-
gerade Zahlen bezeichnen Alpha- oder Betaversionen.
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 stammen.
Beispiele: 4.999.9beta ist 49990091 und 5.0.0 is 50000002.
Informationen zur Speicherbedarfsbegrenzung
xz --robot --info-memory gibt eine einzelne Zeile mit drei durch Tabu-
latoren getrennten Spalten aus:
1. Gesamter physischer Speicher (RAM) in Byte.
2. Speicherbedarfsbegrenzung für die Kompression in Byte (--memli-
mit-compress). Ein spezieller Wert von 0 bezeichnet die Standard-
einstellung, die im Einzelthread-Modus bedeutet, dass keine Begren-
zung vorhanden ist.
3. Speicherbedarfsbegrenzung für die Dekompression in Byte (--memli-
mit-decompress). Ein spezieller Wert von 0 bezeichnet die Standard-
einstellung, die im Einzelthread-Modus bedeutet, dass keine Begren-
zung vorhanden ist.
4. Seit xz 5.3.4alpha: Die Speichernutzung für Multithread-Dekompres-
sion 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
Standardwert 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-Da-
tei. Die block-Zeilen werden nach allen stream-Zeilen angezeigt;
verschiedene Zeilentypen werden nicht verschachtelt.
summary
Dieser Zeilentyp wird nur verwendet, wenn --verbose zwei Mal an-
gegeben wurde. Diese Zeile wird nach allen block-Zeilen ausgege-
ben. Wie die file-Zeile enthält die summary-Zeile allgemeine In-
formationen 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 Minuszeichen (---)
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. Un-
bek.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 Suchvor-
gä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 ver-
fügbar ist, und u gibt an, dass die unkomprimierte 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. Ausge-
schlossen 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 Kom-
pression verwendeten Optionen nicht bekannt sein können, da
in den .xz-Headern nur die für die Dekompression erforderli-
chen 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 erfor-
derlich 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 vo-
rigen 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 Dekomprimie-
ren 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 erfor-
derlich 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 Feh-
ler), welche den Exit-Status nicht beeinflussen.
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ück-
sichtigt werden; alle Einträge, die keine Optionen sind, werden still-
schweigend ignoriert. Die Auswertung erfolgt mit getopt_long(3), wel-
ches auch für die Befehlszeilenargumente verwendet wird.
XZ_DEFAULTS
Benutzerspezifische oder systemweite Standardoptionen. Typi-
scherweise werden diese in einem Shell-Initialisierungsskript
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 Skrip-
ten niemals gesetzt oder außer Kraft gesetzt werden.
XZ_OPT Dies dient der Übergabe von Optionen an xz, wenn es nicht mög-
lich ist, die Optionen direkt in der Befehlszeile 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 emp-
fehlenswert, Benutzern die Außerkraftsetzung von XZ_OPT zu er-
lauben, 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 verursachen
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 Voreinstellungsstu-
fen. Die Wörterbuchgröße ist etwa gleich dem Speicherbedarf bei der De-
kompression.
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 Speicher-
bedarf bei der Kompression, aber es gibt noch einige andere Unter-
schiede 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äh-
rend 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 gespei-
chert werden. Die LZMA-Utils tun das beim Komprimieren gewöhnlicher Da-
teien. Als Alternative kann die unkomprimierte Größe als unbekannt mar-
kiert und eine Nutzdatenende-Markierung (end-of-payload) verwendet wer-
den, um anzugeben, wo der Dekompressor stoppen soll. Die LZMA-Utils
verwenden diese Methode, wenn die unkomprimierte Größe unbekannt ist,
was beispielsweise in Pipes (Befehlsverkettungen) der Fall ist.
xz unterstützt die Dekompression von .lzma-Dateien mit oder ohne Nutz-
datenende-Markierung, aber alle von xz erstellten .lzma-Dateien verwen-
den 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 Da-
teien 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 er-
zeugen.
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 wer-
den.
Die LZMA-Utils erzeugen nur .lzma-Dateien mit einer Wörterbuchgröße von
2^n (einer Zweierpotenz), aber akzeptieren 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 prak-
tisch alle .lzma-Dateien mit Einstellungen komprimiert wurden, die Li-
blzma 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 un-
terschiedlich 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 Datei-
format 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 wur-
den.
Sobald --rsyncable implementiert wurde, bedeutet das, dass die sich er-
gebenden 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 unter-
stützen nicht unbedingt Dateien, die mit anderen 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 verwen-
den, 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 mindestens in der Lage, die
Datei zu dekomprimieren, ohne deren Integrität zu prüfen, wenn die be-
stimmte 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 Paralleli-
sieren der Kompression vieler Dateien verwendet 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 Da-
teien 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 insge-
samt 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-Versionen kompatibel, welche die Option --robot nicht unterstüt-
zen:
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-Voreinstellungsstufen. Das kann nützlich sein,
weil die Voreinstellungen nur einen Teil der potenziell sinnvollen Kom-
binationen aus Kompressionseinstellungen abdecken.
Die KompCPU-Spalten der Tabellen aus den Beschreibungen der Optionen -0
… -9 und --extreme sind beim Anpassen der LZMA2-Voreinstellungen nütz-
lich. 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 verwenden:
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 ein-
ander sehr ähnliche Dateien enthält, die jeweils wenigstens einige Me-
gabyte groß sind. Das Wörterbuch muss dann deutlich größer sein als die
einzelne Datei, damit LZMA2 den größtmöglichen Vorteil aus den Ähnlich-
keiten der aufeinander folgenden Dateien zieht.
Wenn hoher Speicherbedarf für Kompression und Dekompression kein Pro-
blem ist und die zu komprimierende Datei mindestens einige Hundert Me-
gabyte 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 Dekompres-
sor 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 Speicherbe-
darf bei der Dekompression muss gering gehalten werden, zum Beispiel um
die Datei auf eingebetteten Systemen dekomprimieren zu können. Der fol-
gende Befehl verwendet -6e (-6 --extreme) als Basis und setzt die Wör-
terbuchgröße auf nur 64 KiB. Die sich ergebende Datei kann mit XZ Em-
bedded (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 An-
passung der Anzahl der literalen Kontextbits (lc) und der Anzahl der
Positionsbits (pb) manchmal hilfreich sein. Auch die Anpassung der An-
zahl der literalen Positionsbits (lp) könnte helfen, aber üblicherweise
sind lc und pb wichtiger. Wenn ein Quellcode-Archiv zum Beispiel haupt-
sä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 ge-
nutzte Bibliothek der Architekturen x86-32 oder x86-64 mit dem BCJ-Fil-
ter 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 Ergeb-
nisse 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 Abstandsparameter des Delta-Fil-
ters 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-Ausrich-
tung zu berücksichtigen:
xz --delta=dist=3 --lzma2=pb=0 foo.tiff
Wenn sich mehrere Bilder in einem einzelnen Archiv befinden (zum Bei-
spiel .tar), funktioniert der Delta-Filter damit auch, sofern alle Bil-
der 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: <http://7-zip.org/sdk.html>
Tukaani 1. Dezember 2022 XZ(1)
Generated by dwww version 1.15 on Sat Jun 29 00:40:09 CEST 2024.