XZ(1)

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

ÜBERSICHT
xz [Option…] [Datei…]

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

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

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

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 oder .lzma 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 oder .tlz).

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.

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

  Speicherbedarf
In Abhängigkeit von den gewählten Kompressionseinstellungen bewegt sich der Speicherverbrauch zwischen wenigen hundert Kilobyte und mehrere 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.

Especially users of older systems may find the possibility of very large memory usage annoying. To prevent uncomfortable surprises, xz has a built-in memory usage limiter, which is disabled by default. While some operating systems provide ways to limit the memory usage of processes, relying on it wasn't deemed to be flexible enough (for example, using ulimit(1) to limit virtual memory tends to cripple mmap(2)).

The memory usage limiter can be enabled with the command line option --memlimit=limit. Often it is more convenient to enable the limiter by default by setting the environment variable XZ_DEFAULTS, for example, XZ_DEFAULTS=--memlimit=150MiB. It is possible to set the limits separately for compression and decompression by using --memlimit-compress=limit and --memlimit-decompress=limit. Using these two options outside XZ_DEFAULTS is rarely useful because a single run of xz cannot do both compression and decompression and --memlimit=limit (or -M limit) is shorter to type on the command line.

If the specified memory usage limit is exceeded when decompressing, xz will display an error and decompressing the file will fail. If the limit is exceeded when compressing, xz will try to scale the settings down so that the limit is no longer exceeded (except when using --format=raw or --no-adjust). This way the operation won't fail unless the limit is very small. The scaling of the settings is done in steps that don't match the compression level presets, for example, if the limit is only slightly less than the amount required for xz -9, the settings will be scaled down only a little, not all the way down to 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.

It is possible to insert padding between the concatenated parts or after the last part. The padding must consist of null bytes and the size of the padding must be a multiple of four bytes. This can be useful, for example, if the .xz file is stored on a medium that measures file sizes in 512-byte blocks.

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 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.

  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 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.

    The default listing shows basic information about files, one file per line. To get more detailed information, use also the --verbose option. For even more information, use --verbose twice, but note that this may be slow, because getting all the extra information requires many seeks. The width of verbose output exceeds 80 characters, so piping the output to, for example, less -S may be convenient if the terminal isn't wide enough.

    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.

    Since xz 5.2.6, this option also makes xz compress or decompress even if the input is a symbolic link to a regular file, has more than one hard link, or has the setuid, setgid, or sticky bit set. The setuid, setgid, and sticky bits are not copied to the target file. In earlier versions this was only done with --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 oder .tlz 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.

  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 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.

    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
        Good to very good compression while keeping decompressor memory usage reasonable even for old systems. -6 is the default, which is usually a good choice for distributing files that need to be decompressible even on systems with only 16 MiB RAM. (-5e or -6e may be worth considering too. See --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:

        Voreinstellung | DictGröße | KompCPU | KompSpeicher | DekSpeicher
        -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:

    •   DictGröß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.

    •   KompCPU 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.

    •   KompSpeicher 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.

    •   DekSpeicher 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 der 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.

        Voreinstellung | DictGröße | KompCPU | KompSpeicher | DekSpeicher
        -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.

    In multi-threaded mode about three times size bytes will be allocated in each thread for buffering input and output. The default size is three times the LZMA2 dictionary size or 1 MiB, whichever is more. Typically a good value is 2–4 times the size of the LZMA2 dictionary or at least 1 MiB. Using size less than the LZMA2 dictionary size is waste of RAM because then the LZMA2 dictionary buffer will never get fully used. The sizes of the blocks are stored in the block headers, which a future version of xz will use for multi-threaded decompression.

    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, passt xz die Einstellungen nach unten an, so dass die Grenze nicht mehr überschritten wird und zeigt einen Hinweis an, dass eine automatische Anpassung vorgenommen wurde. Solche Anpassungen erfolgen nicht, wenn mit --format=raw komprimiert wird oder wenn --no-adjust angegeben wurde. In diesen Fällen wird eine Fehlermeldung mit dem Exit-Status 1 ausgegeben und xz 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). Sobald die Unterstützung für Multi-Threading implementiert wurde, kann es im Multi-Thread-Fall einen Unterschied zwischen 0 und max geben, daher wird empfohlen, 0 anstelle von max zu verwenden, bis die Einzelheiten hierzu geklärt sind.

    For 32-bit xz there is a special case: if the limit would be over 4020 MiB, the limit is set to 4020 MiB. On MIPS32 2000 MiB is used instead. (The values 0 and max aren't affected by this. A similar feature doesn't exist for decompression.) This can be helpful when a 32-bit executable has access to 4 GiB address space (2 GiB on MIPS32) while hopefully doing no harm in other situations.

    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.

-M Grenze, --memlimit=Grenze, --memory=Grenze
    This is equivalent to specifying --memlimit-compress=limit --memlimit-decompress=limit.

--no-adjust
    zeigt einen Fehler an und bricht die Ausführung ab, falls die Kompressionseinstellungen die Begrenzung der Speichernutzung überschreiten. Standardmäßig werden die Einstellungen nach unten korrigiert, so dass diese Grenze nicht überschritten wird. Bei der Erzeugung von Rohdatenströmen (--format=raw) ist die automatische Korrektur stets 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 so viele Threads, wie Prozessorkerne im System verfügbar sind. 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 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 wurde bislang noch nicht implementiert. Sie wird nur bei Dateien funktionieren, die mehrere Blöcke mit Größeninformationen in deren Headern enthalten. Alle im Multi-Thread-Modus komprimierten Dateien erfüllen diese Bedingung, im Einzel-Thread-Modus komprimierte Dateien dagegen nicht, selbst wenn --block-size=Größe verwendet wird.

  Benutzerdefinierte Filterketten für die Kompression
A custom filter chain allows specifying the compression settings in detail instead of relying on the settings associated to the presets. When a custom filter chain is specified, preset options (-0 ... -9 and --extreme) earlier on the command line are forgotten. If a preset option is specified after one or more custom filter chain options, the new preset takes effect and the custom filter chain options specified earlier are forgotten.

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
        Reset all LZMA1 or LZMA2 options to preset. Preset consist of an integer, which may be followed by single-letter preset modifiers. The integer can be from 0 to 9, matching the command line options -0 ... -9. The only supported modifier is currently e, which matches --extreme. If no preset is specified, the default values of LZMA1 or LZMA2 options are taken from the preset 6.

    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.

        The literal coding makes an assumption that the highest lc bits of the previous uncompressed byte correlate with the next byte. For example, in typical English text, an upper-case letter is often followed by a lower-case letter, and a lower-case letter is usually followed by another lower-case letter. In the US-ASCII character set, the highest three bits are 010 for upper-case letters and 011 for lower-case letters. When lc is at least 3, the literal coding can take advantage of this property in the uncompressed data.

        The default value (3) is usually good. If you want maximum compression, test lc=4. Sometimes it helps a little, and sometimes it makes compression worse. If it makes it worse, test lc=2 too.

    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.

        When the alignment is known, setting pb accordingly may reduce the file size a little. For example, with text files having one-byte alignment (US-ASCII, ISO-8859-*, UTF-8), setting pb=0 can improve compression slightly. For UTF-16 text, pb=1 is a good choice. If the alignment is an odd number like 3 bytes, pb=0 might be the best choice.

        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
        Match finder has a major effect on encoder speed, memory usage, and compression ratio. Usually Hash Chain match finders are faster than Binary Tree match finders. The default depends on the preset: 0 uses hc3, 1–3 use hc4, and the rest use 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
        Compression mode specifies the method to analyze the data produced by the match finder. Supported modes are fast and normal. The default is fast for presets 0–3 and normal for presets 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.

        Nice can be 2–273 bytes. Higher values tend to give better compression ratio at the expense of speed. The default depends on the preset.

    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.

        Reasonable depth for Hash Chains is 4–100 and 16–1000 for Binary Trees. Using very high values for depth can make the encoder extremely slow with some files. Avoid setting the depth over 1000 unless you are prepared to interrupt the compression in case it is taking far too long.

    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]
--powerpc[=Optionen]
--ia64[=Optionen]
--arm[=Optionen]
--armthumb[=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.

    A BCJ filter converts relative addresses in the machine code to their absolute counterparts. This doesn't change the size of the data, but it increases redundancy, which can help LZMA2 to produce 0–15 % smaller .xz file. The BCJ filters are always reversible, so using a BCJ filter for wrong type of data doesn't cause any data loss, although it may make the compression ratio slightly worse.

    Es ist in Ordnung, einen BCJ-Filter auf eine gesamte Binärdatei anzuwenden; es ist nicht nötig, dies nur auf den binären Bereich zu beschränken. Die Anwendung eines BCJ-Filters auf ein Archiv, das sowohl binäre als auch nicht-binäre Dateien enthält, kann gute Ergebnisse liefern, muss es aber nicht. Daher ist es generell nicht gut, einen BCJ-Filter blindlings anzuwenden, wenn Sie Binärpakete zwecks Weitergabe komprimieren wollen.

    Diese BCJ-Filter sind sehr schnell und erhöhen den Speicherbedarf nur unerheblich. Wenn ein BCJ-Filter das Kompressionsverhältnis einer Datei verbessert, kann er auch gleichzeitig die Dekompressionsgeschwindigkeit verbessern. Das kommt daher, dass auf der gleichen Hardware die Dekompressionsgeschwindigkeit von LZMA2 ungefähr eine feste Anzahl Byte an komprimierten Daten pro Sekunde ist.

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

    •   Some types of files containing executable code (for example, object files, static libraries, and Linux kernel modules) have the addresses in the instructions filled with filler values. These BCJ filters will still do the address conversion, which will make the compression worse with these files.

    •   Bei der Anwendung eines BCJ-Filters auf ein Archiv, das mehrere ähnliche Binärdateien enthält, kann das Kompressionsverhältnis schlechter sein als ohne BCJ-Filter. Das kommt daher, weil der BCJ-Filter die Grenzen der Binärdateien nicht erkennt und den Zähler der Adressumwandlung für jede Binärdatei nicht zurücksetzt.

    Beide der oben genannten Probleme werden in der Zukunft in einem neuen Filter nicht mehr auftreten. Die alten BCJ-Filter werden noch in eingebetteten Systemen von Nutzen sein, weil der Dekoder des neuen Filters größer sein und mehr Speicher beanspruchen wird.

    Verschiedene Befehlssätze haben unterschiedliche Ausrichtungen:

        Filter | Ausrichtung | Hinweise
        x86 | 1 | 32-Bit oder 64-Bit x86
        PowerPC | 4 | Nur Big Endian
        ARM | 4 | Nur Little Endian
        ARM-Thumb | 2 | Nur Little Endian
        IA-64 | 16 | Big oder Little Endian
        SPARC | 4 | Big oder Little Endian

    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 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.

    Currently only simple byte-wise delta calculation is supported. It can be useful when compressing, for example, uncompressed bitmap images or uncompressed PCM audio. However, special purpose algorithms may give significantly better results than Delta + LZMA2. This is true especially with audio, which compresses faster and better, for example, with flac(1).

    Unterstützte Optionen:

    dist=Abstand
        Specify the distance of the delta calculation in bytes. distance must be 1–256. The default is 1.

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

  Andere Optionen

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

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

    Der Fortschrittsanzeiger stellt die folgenden Informationen dar:

    •   Der Prozentsatz des Fortschritts wird angezeigt, wenn die Größe der Eingabedatei bekannt ist. Das 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.

    •   Estimated remaining time is shown only when the size of the input file is known and a couple of seconds have already passed since xz started processing the file. The time is shown in a less precise format which never has any colons, for example, 2 min 30 s.

    When standard error is not a terminal, --verbose will make xz print the filename, compressed size, uncompressed size, compression ratio, and possibly also the speed and elapsed time on a single line to standard error after compressing or decompressing the file. The speed and elapsed time are included only when the operation took at least a few seconds. If the operation didn't finish, for example, due to user interruption, also the completion percentage is printed if the size of the input file is known.

-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) 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.

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

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

XZ_VERSION=XYYYZZZS
LIBLZMA_VERSION=XYYYZZZS

X   Hauptversion.

YYY Unterversion. Gerade Zahlen bezeichnen eine stabile Version. Ungerade Zahlen bezeichnen Alpha- oder 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 Tabulatoren getrennten Spalten aus:

1.  Gesamter physischer Speicher (RAM) in Byte

2.  Speicherbedarfsbegrenzung für die Kompression in Byte. Ein spezieller Wert von Null bezeichnet die Standardeinstellung, die im Einzelthread-Modus bedeutet, dass keine Begrenzung vorhanden ist.

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

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

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

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

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

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

block
    Dieser Zeilentyp wird nur verwendet, wenn --verbose angegeben wurde. Es gibt so viele block-Zeilen, wie Blöcke in der .xz-Datei. Die block-Zeilen werden nach allen stream-Zeilen angezeigt; verschiedene 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.  Compression ratio, for example, 0.123. If ratio is over 9.999, three dashes (---) are displayed instead of the ratio.
    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.

EXIT-STATUS

0   Alles ist in Ordnung.

1   Ein Fehler ist aufgetreten.

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

In die Standardausgabe geschriebene Hinweise (keine Warnungen oder Fehler), welche den Exit-Status nicht 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ü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
    This is for passing options to xz when it is not possible to set the options directly on the xz command line. This is the case when xz is run by a script or tool, for example, GNU tar(1):

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

    Scripts may use XZ_OPT, for example, to set script-specific default compression options. It is still recommended to allow users to override XZ_OPT if that is reasonable. For example, in sh(1) scripts one may use something like this:

        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 Voreinstellungsstufen. Die Wörterbuchgröße ist etwa gleich dem Speicherbedarf bei der Dekompression.

    Stufe | xz | LZMA-Utils
    -0 | 256 KiB | nicht verfügbar
    -1 | 1 MiB | 64 KiB
    -2 | 2 MiB | 1 MiB
    -3 | 4 MiB | 512 KiB
    -4 | 4 MiB | 1 MiB
    -5 | 8 MiB | 2 MiB
    -6 | 8 MiB | 4 MiB
    -7 | 16 MiB | 8 MiB
    -8 | 32 MiB | 16 MiB
    -9 | 64 MiB | 32 MiB

Die Unterschiede in der Wörterbuchgröße beeinflussen auch den Speicherbedarf bei der Kompression, aber es gibt noch einige andere Unterschiede zwischen den LZMA-Utils und den XZ-Utils, die die Kluft noch vergrößern:

    Stufe | xz | LZMA-Utils 4.32.x
    -0 | 3 MiB | nicht verfügbar
    -1 | 9 MiB | 2 MiB
    -2 | 17 MiB | 12 MiB
    -3 | 32 MiB | 12 MiB
    -4 | 48 MiB | 16 MiB
    -5 | 94 MiB | 26 MiB
    -6 | 94 MiB | 45 MiB
    -7 | 186 MiB | 83 MiB
    -8 | 370 MiB | 159 MiB
    -9 | 674 MiB | 311 MiB

Die standardmäßige Voreinstellungsstufe in den LZMA-Utils ist -7, während diese in den XZ-Utils -6 ist, daher verwenden beide standardmäßig ein 8 MiB großes Wörterbuch.

  Vor- und Nachteile von .lzma-Dateien als Datenströme
The uncompressed size of the file can be stored in the .lzma header. LZMA Utils does that when compressing regular files. The alternative is to mark that uncompressed size is unknown and use end-of-payload marker to indicate where the decompressor should stop. LZMA Utils uses this method when uncompressed size isn't known, which is the case, for example, in pipes.

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.

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

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

Die LZMA-Utils erzeugen nur .lzma-Dateien mit einer Wörterbuchgröße von 2^n (einer Zweierpotenz), aber 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.

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

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

ANMERKUNGEN

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

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

  Eingebettete .xz-Dekompressoren
Eingebettete .xz-Dekompressor-Implementierungen wie XZ Embedded unterstützen nicht unbedingt Dateien, die mit 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.

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

Create baz.tar.xz with the preset -4e (-4 --extreme), which is slower than the default -6, but needs less memory for compression and decompression (48 MiB and 5 MiB, respectively):

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

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

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

  Parallele Kompression von vielen Dateien
Auf GNU- und *BSD-Systemen können find(1) und xargs(1) zum Parallelisieren der Kompression vieler Dateien 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.

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

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

Ein Skript könnte abfragen wollen, ob es ein xz verwendet, das aktuell genug ist. Das folgende sh(1)-Skript prüft, ob die Versionsnummer des Dienstprogramms xz mindestens 5.0.0 ist. Diese Methode ist zu alten Beta-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

  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 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:

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

If you know that a file requires somewhat big dictionary (for example, 32 MiB) to compress well, but you want to compress it quicker than xz -8 would do, a preset with a low CompCPU value (for example, 1) can be modified to use a bigger dictionary:

    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.

Sometimes the compression time doesn't matter, but the decompressor memory usage has to be kept low, for example, to make it possible to decompress the file on an embedded system. The following command uses -6e (-6 --extreme) as a base and sets the dictionary to only 64 KiB. The resulting file can be decompressed with XZ Embedded (that's why there is --check=crc32) using about 100 KiB of memory.

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

If you want to squeeze out as many bytes as possible, adjusting the number of literal context bits (lc) and number of position bits (pb) can sometimes help. Adjusting the number of literal position bits (lp) might help too, but usually lc and pb are more important. For example, a source code archive contains mostly US-ASCII text, so something like the following might give slightly (like 0.1 %) smaller file than xz -6e (try also without lc=4):

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

Using another filter together with LZMA2 can improve compression with certain file types. For example, to compress a x86-32 or x86-64 shared library using the x86 BCJ filter:

    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.

The image has to be saved in uncompressed format, for example, as uncompressed TIFF. The distance parameter of the Delta filter is set to match the number of bytes per pixel in the image. For example, 24-bit RGB bitmap needs dist=3, and it is also good to pass pb=0 to LZMA2 to accommodate the three-byte alignment:

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

If multiple images have been put into a single archive (for example, .tar), the Delta filter will work on that too as long as all images have the same number of bytes per pixel.

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>