xz, unxz, xzcat, lzma, unlzma, lzcat - .xz- und .lzma-Dateien komprimieren oder
dekomprimieren
xz [
Option…] [
Datei…]
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.
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 dekomprimierte 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 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 Standardeingabe, wenn diese ein Terminal ist.
Dateien, die nicht als
- angegeben sind, werden in eine neue Datei
geschrieben, 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 Dateinamen entfernt und so der Name der
Zieldatei 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 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, Zugriffszeit und
Änderungszeit aus der Ursprungs-
Datei in die Zieldatei. Sollte
das Kopieren der Gruppe fehlschlagen, 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.
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 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 unangenehme
Überraschungen zu vermeiden, verfügt
xz über eine
eingebaute Begrenzung des Speicherbedarfs, die allerdings 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 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 Begrenzungen können getrennt
für Kompression und Dekompression mittels
--memlimit-compress=Begrenzung und
--memlimit-decompress=Begrenzung festgelegt 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
--memlimit= Begrenzung (oder
-M Begrenzung)
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 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 vorgenommen, 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
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.
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 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 akzeptiert.
Der spezielle Wert
max kann dazu verwendet werden, um den von der
jeweiligen Option akzeptierten maximalen Ganzzahlwert anzugeben.
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
Befehlsnamen 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 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 Breite der
ausführlichen Ausgabe ist breiter als 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.
-
-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
ermitteln 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 anweisen, 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 absichern. 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 verarbeitet.
-
--files0[=Datei]
- Dies ist gleichbedeutend mit
--files[=Datei], außer dass jeder Dateiname
mit einem Null-Zeichen abgeschlossen werden muss.
-
-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 erzeugt werden,
nicht automatisch erkannt werden können.
- xz
- Die Kompression erfolgt in das .xz-Dateiformat oder
akzeptiert nur .xz-Dateien bei der Dekompression.
-
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-Dienstprogrammen.
- 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
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 Dekompressionsunterstü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 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 Benutzer
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 fehlenden)
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
verwenden:
- •
- 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ä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 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 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 Sekunde. Anders ausgedrückt: Je besser die
Kompression, umso schneller wird üblicherweise die Dekompression
sein. Das bedeutet auch, dass die Menge der pro Sekunde ausgegebenen
unkomprimierten 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 verwenden, 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 Kompressionsgeschwindigkeit 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 dramatisch höher sein als
im Einzel-Thread-Modus.
- •
- DekompSpeich enthält den Speicherbedarf für
die Dekompression. 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
Kompressions-Voreinstellungsstufe ( -0 … -9), um
hoffentlich 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 Voreinstellungsstufen -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 Zufallszugriffe
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 angewendet 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-Dekompression 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 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 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 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 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 automatische Anpassung vorgenommen
wurde. Die Anpassungen werden in folgender Reihenfolge angewendet:
Reduzierung 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 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 insbesondere
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 hiervon 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 Fehlermeldung 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 Multithread-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 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 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 Auslagerung 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-decompress= Grenze.
- --no-adjust
- zeigt einen Fehler an und beendet, falls die Grenze der
Speichernutzung nicht ohne Änderung der Einstellungen, 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 setzen,
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-Kompressor 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 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
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ößeninformationen 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.
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 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 beliebiger 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 zweimaligen 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.
Kompressionsgeschwindigkeit 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 Voreinstellungsmodifikator folgen kann. Die Ganzzahl kann
0 bis 9 sein, entsprechend den Befehlszeilenoptionen
-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
unkomprimierten 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 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ö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 Texten 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, versuchen 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 Ü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
Übereinstimmungsfinder gelieferten Daten an. Als Modi werden
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
Übereinstimmung 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ä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 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 Filter 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 etwas 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 Bibliotheken 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 Eingabedateien
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 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
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.
-
-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 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
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 verarbeiteten 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 begonnen 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 unkomprimierte 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 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 aufgenommen, 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 Prozessor-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 erfolgreich.
-
-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.
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.
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 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.
xz --robot --info-memory gibt eine einzelne Zeile mit drei 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
bezeichnet 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
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.
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 Zeilentypen 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 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.
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
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. 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.
- 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 beeinflussen.
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,
werden stillschweigend ignoriert. Die Auswertung erfolgt mit
getopt_long(3), welches auch für die Befehlszeilenargumente
verwendet wird.
- XZ_DEFAULTS
- Benutzerspezifische oder systemweite Standardoptionen.
Typischerweise 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 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 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 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
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.
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.
Die unkomprimierte Größe der Datei kann in den
.lzma-Headern gespeichert werden. Die LZMA-Utils tun das beim
Komprimieren 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 (Befehlsverkettungen) der Fall ist.
xz unterstützt die Dekompression von
.lzma-Dateien mit oder
ohne Nutzdatenende-Markierung, aber alle von
xz erstellten
.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.
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 akzeptieren Dateien mit einer beliebigen
Wörterbuchgröße. Liblzma akzeptiert nur
.lzma-Dateien mit einer Wörterbuchgröß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.
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.
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-Dekompressor-Implementierungen wie XZ Embedded
unterstü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 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 mindestens
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.
Komprimiert die Datei
foo mit der Standard-Kompressionsstufe (
-6)
zu
foo.xz und entfernt
foo nach erfolgreicher Kompression:
bar.xz in
bar dekomprimieren und
bar.xz selbst dann nicht
löschen, wenn die Dekompression erfolgreich war:
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
Auf GNU- und *BSD-Systemen können
find(1) und
xargs(1) zum
Parallelisieren 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 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.
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-Versionen 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
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 Kombinationen
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 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 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 mindestens 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 Befehl
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 Kontextbits (
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
Quellcode-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 Abstandsparameter 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.
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>