Xz

xz - Beschreibung

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

Beschreibung

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

xz komprimiert oder dekomprimiert jede Datei entsprechend des gewählten Vorgangsmodus. Falls entweder - oder keine Datei angegeben ist, liest xz aus der Standardeingabe und leitet die verarbeiteten Dateien in die 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 dem Namen der Quell-Datei abgeleitet wird (außer wenn --stdout angegeben ist):

• Bei der Kompression wird das Suffix des Formats der Zieldatei (.xz oder .lzma) an den Namen der Quelldatei angehängt und so der Name der Zieldatei gebildet.
• Bei der Dekompression wird das Suffix .xz, .lzma oder .lz vom Dateinamen entfernt und so der Name der 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 diese daher nicht zu den regulären Dateien gezählt.
• Die Datei hat mehr als eine harte Verknüpfung.
• Für die Datei ist das »setuid«-, »setgid«- oder »sticky«-Bit gesetzt.
• Der Aktionsmodus wird auf Kompression gesetzt und die Datei hat bereits das Suffix des Zieldateiformats (.xz oder .txz beim Komprimieren in das .xz-Format und .lzma oder

.tlz beim Komprimieren in das .lzma-Format).

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

Nach erfolgreicher Kompression oder Dekompression der Datei kopiert xz Eigentümer, Gruppe, Zugriffsrechte, 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.

Speicherbedarf In Abhängigkeit von den gewählten Kompressionseinstellungen bewegt sich der Speicherverbrauch zwischen wenigen hundert Kilobyte und mehreren Gigabyte. Die Einstellungen bei der Kompression einer Datei bestimmen dabei den Speicherbedarf bei der Dekompression. Die Dekompression benötigt üblicherweise zwischen 5 % und 20 % des Speichers, der bei der Kompression der Datei erforderlich war. Beispielsweise benötigt die 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 Verkettung und Auffüllung von .xz-Dateien Es ist möglich, .xz-Dateien direkt zu verketten. Solche Dateien werden von xz genauso dekomprimiert wie eine einzelne .xz-Datei.

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

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

Aufruf

xz [Option…] [Datei…]

Aliase

Alias	gleichbedeutend mit
unxz	xz --decompress
xzcat	xz --decompress --stdout
lzma	xz --format=lzma
unlzma	xz --format=lzma --decompress
lzcat	xz --format=lzma --decompress --stdout

Hinweis

In Skripte sollte stets xz mit den entsprechenden Argumenten (xz -d oder xz -dc) anstelle der Aliase unxz und xzcat verwendet werden

Anwendung

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

xz foo

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

xz -dk bar.xz

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

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

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

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

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

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

Anhang

Siehe auch

• Xz
• Xz/Konfiguration
• Xz/Optionen

Dokumentation

Man-Page

1. xzdec(1)
2. xzdiff(1)
3. xzgrep(1)
4. xzless(1)
5. xzmore(1)
6. gzip(1)
7. bzip2(1)
8. 7z(1)

Links

Projekt

XZ Utils: <https://tukaani.org/xz/> XZ Embedded: <https://tukaani.org/xz/embedded.html>

Weblinks

LZMA-SDK: <https://7-zip.org/sdk.html>

TMP

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

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

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.