Provided by: manpages-ja_0.5.0.0.20221215+dfsg-1_all 
名前
xz, unxz, xzcat, lzma, unlzma, lzcat - .xz, .lzma ファイルの圧縮、伸長
書式
xz [option...] [file...]
コマンドエイリアス
unxz は xz --decompress と同じです。
xzcat は xz --decompress --stdout と同じです。
lzma は xz --format=lzma と同じです。
unlzma は xz --format=lzma --decompress と同じです。
lzcat は xz --format=lzma --decompress --stdout と同じです。
ファイル圧縮を行うスクリプトを記述する場合は、unxz や xzcat などを用いるのではなく、常に xz コマンドに適
切な引数 (xz -d or xz -dc) をつけて利用することをお勧めします。
説明
xz は汎用目的のデータ圧縮ツールです。コマンドラインには gzip(1) や bzip2(1) と同等の文法が用いられていま
す。ネイティブなファイルフォーマットは .xz です。さらに LZMA Utils が利用しているこれまでの .lzma フォー
マットや、コンテナーフォーマットヘッダーを持たない、生の (raw) 圧縮ストリームにも対応しています。
xz は指定されたオペレーションモードに従って、各 file の圧縮、伸長を行います。files が指定されていない、ま
たは - と指定された場合、xz は標準入力からデータを読み込んで、処理結果を標準出力へ書き出します。端末上に
おいて圧縮データを標準出力に書き出そうとした場合には、xz は処理停止します (エラーを表示して file の処理を
スキップします)。同様に端末上において圧縮データを標準入力から読み込もうとした場合も、xz は処理停止しま
す。
--stdout の指定がなく files が - でない場合は新規のファイル生成となり、そのファイル名は元の file から命名
されます。
• 圧縮時は、目的とするファイルフォーマット (.xz または .lzma) をサフィックスとして、元のファイル名にこれ
を加えたファイル名とします。
• 伸長時は、サフィックス .xz または .lzma を取り除いて、目的のファイル名とします。xz はサフィックスとし
て .txz と .tlz も識別します。この場合はサフィックスを .tar として置き換えます。
目的とするファイルがすでに存在している場合、エラーが表示されて file に対する処理はスキップされます。
出力先が標準出力でなく、以下のいずれかに該当する場合、xz は警告を表示して file の処理をスキップします。
• file が通常の (regular) ファイルではない場合。シンボリックリンクをたどることはありません。したがってそ
の場合は通常のファイルではないものとして扱われます。
• file が複数のハードリンクを持つ場合。
• file に setuid、setgid、スティッキービット (sticky bit) セットがある場合。
• オペレーションモードが圧縮として設定されていて、file のサフィックスが目的とするファイルフォーマットに
すでになっていた場合 (.xz への圧縮時にすでに .xz や .txz であった場合、また .lzma への圧縮時にすでに
.lzma や .tlz であった場合)。
• オペレーションモードが伸長として設定されていて、file のサフィックスが対応しているファイルフォーマット
(.xz, .txz, .lzma, .tlz) でない場合。
file に対する圧縮または伸長が正常に処理された後は、元のソース file の所有者、グループ、パーミッション、ア
クセス時刻、更新時刻を、目的とするファイルにコピーします。グループ情報のコピーに失敗した場合は、パーミッ
ションを修正して、元のソース file にアクセス権を有していなかったユーザーが、目的のファイルにアクセスでき
ないようにします。現状の xz では、アクセスコントロールリストや拡張属性のようなメタデータのコピーには対応
していません。
目的とするファイルのクローズ処理が正常終了したら、--keep が指定されていない限り、ソース file は削除されま
す。このソース file は、出力先が標準出力である場合には削除されません。
xz に対して SIGINFO や SIGUSR1 を送信すると、標準エラー出力に対して進捗情報を出力します。この用途は限られ
ています。なぜなら標準エラー出力先が端末である場合、--verbose を利用すれば進捗インジケーターが自動的に更
新されるためです。
メモリ利用
xz が利用するメモリ量は、圧縮の設定により数 100 キロバイトから数ギガバイトまでとさまざまです。ファイル圧
縮時に利用される設定は、ファイル伸長時のメモリ利用を決定づけます。通常、伸長処理に要するメモリ容量は、圧
縮処理においてファイル生成に必要となるメモリ容量の 5 % から 20 % です。たとえば xz -9 によって圧縮された
ファイルを伸長するには、今のところ 65 MiB のメモリを要します。ただし .xz ファイルの伸長に数ギガバイトを利
用することも可能です。
特に、古いシステムを利用してきたユーザーは、あまりにもメモリが大量に消費されるので、好ましく思わないかも
しれません。そのような状況を回避するために xz にはビルトインのメモリ制限機能があります。これはデフォルト
では無効化されています。オペレーティングシステムの中には、プロセスのメモリ利用を制限する方法を提供するも
のがありますが、そこに依存するのは、柔軟性に欠けると考えられてきました (たとえば ulimit(1) を利用して仮想
メモリを制限すると、mmap(2) が機能しなくなる傾向にあるなどです)。
メモリ制限機能を有効にするには、コマンドラインオプション --memlimit=limit を指定します。この制限機能
は、環境変数 XZ_DEFAULTS を用いて XZ_DEFAULTS=--memlimit=150MiB のようにしてデフォルトで有効にしておく
と、利用しやすくなります。この制限機能は、圧縮時と伸長時のそれぞれに対して --memlimit-compress=limit およ
び --memlimit-decompress=limit を使えば、個別に指定することができます。この 2 つのオプションを
XZ_DEFAULTS 以外のところで用いるのは、あまり意味がありません。なぜなら xz が圧縮と伸長を同時に処理するこ
とはありえず、また --memlimit=limit (あるいは -M limit) と設定しておくことの方が、コマンドラインから入力
するよりも短くて済むからです。
伸長時に、指定したメモリ利用制限を超過した場合、xz はエラーを表示し伸長処理は失敗します。圧縮時にその制限
が超過した場合、xz はその制限値を引き下げて、制限を超過しないようにします (ただし --format=raw または
--no-adjust の指定時は除きます)。このような処理方法により、制限値が極端に小さくない限り、処理は失敗しない
ようになります。設定値を引き下げていく際には、圧縮レベルを示すプリセット値までには至らない範囲で、徐々に
引き下げられていきます。たとえばこの設定値が xz -9 に必要となる容量よりも少しだけ小さかった場合、設定値の
引き下げはほんの少しだけ行われるものであって、xz -8 に必要となる容量まで一気に引き下げられるわけではあり
ません。
.xz ファイルの連結とパディング
複数の .xz ファイルは、その状態のまま連結 (concatenate) することができます。連結されたファイルを xz が伸
長する際には、あたかも 1 つの .xz ファイルであるかのようにして処理します。
連結した間の部分や連結の最後に、パディング (padding) という追加データを挿入することができます。パディング
はヌルバイトによって構成されるものであり、そのサイズは 4 バイトの倍数でなければなりません。これが有用とな
るのは、たとえば 512 バイト単位のブロックごとにファイルサイズを定めるような媒体に .xz ファイルを保存する
場合です。
連結とパディングは、.lzma ファイルや生の (raw) ストリームにおいて行うことはできません。
オプション
整数に対するサフィックスと特別な値
整数引数を必要とする場面の多くにおいては、サフィックスをさらにつけることで多大な数値を簡単に表現できるよ
うにしています。整数値とそのサフィックスの間には空白文字を含めないでください。
KiB 1,024 (2^10) の倍数を表現します。KiB と同じ意味を表す Ki, k, kB, K, KB が利用できます。
MiB 1,048,576 (2^20) の倍数を表現します。MiB と同じ意味を表す Mi, m, M, MB が利用できます。
GiB 1,073,741,824 (2^30) の倍数を表現します。GiB と同じ意味を表す Gi, g, G, GB が利用できます。
特別な数値指定 max が利用できます。これはそのオプションにおいてサポートされている最大整数値を表します。
オペレーションモード
オペレーションモードオプションが複数指定された場合は、最後の指定が有効となります。
-z, --compress
圧縮を指示します。これはデフォルトのオペレーションモードです。オペレーションモードオプションが指定
されなかった場合、あるいはコマンドラインからの指定において暗にオペレーションモードの指定が含まれて
いない場合に採用されます (たとえば unxz には --decompress が暗に含まれています)。
-d, --decompress, --uncompress
伸長を指示します。
-t, --test
圧縮された files の整合性をテストします。このオプションは --decompress --stdout とすることと同じで
す。ただし伸長されるデータが、標準出力へは書き込まれずに捨てられてしまう場合を除きます。このオプ
ションでは、ファイル生成や削除は発生しません。
-l, --list
圧縮された files に関する情報を一覧表示します。伸長処理が行われるわけではなく、ファイル生成や削除
は発生しません。このリストモードでは、標準入力あるいは他のシークできない入力ソースからの圧縮データ
は読み込むことができません。
このオプションによる一覧出力では、files に関する基本的な情報が、1 つにつき 1 行ずつ表示されま
す。さらに詳しい情報を得るには --verbose オプションも併用します。それ以上に細かい情報を得るには
--verbose を 2 回指定します。ただしこれを行うと処理が遅くなるかもしれません。細かい情報を得るため
には、数多くの検索処理が必要となるためです。詳細な情報を出力する際の出力幅は 80 文字を超えます。し
たがって less -S を利用するなどして出力をパイプすれば、横幅が十分に取れない端末であっても問題なく
利用できます。
実際の出力は xz のバージョンやロケール指定により変わります。マシンにとって読み込み可能な出力とする
には、--robot --list を利用してください。
オペレーション修飾子 (operation modifiers)
-k, --keep
入力ファイルを削除しません。
-f, --force
このオプションには複数の効果があります。
• 目的とするファイルがすでに存在していた場合、そのファイルを削除してから圧縮や伸長を行います。
• 入力ファイルが通常ファイルへのシンボリックリンクである場合、ハードリンクを複数持つ場合、setuid,
setgid, スティッキービット (sticky bit) セットを持つ場合であっても、圧縮または伸長を行いま
す。setuid, setgid, スティッキービットは目的となるファイルにはコピーされません。
• --decompress --stdout が指定された際に xz がソースファイルの種類を認識できなかった場合は、ソー
スファイルがそのまま標準出力へコピーされます。これは xzcat --force を利用した際に、ソースファイ
ルが xz によって圧縮されていないファイルであっても cat(1) と同じように処理できることになりま
す。将来的に xz は新たな圧縮ファイルフォーマットをサポートするかもしれないので、単に標準出力へ
コピーするのではなく、多くのファイルタイプを伸長できるようになるかもしれません。--format=format
を指定すれば、xz が伸長を行うファイルフォーマットをただ 1 つに限定することができます。
-c, --stdout, --to-stdout
圧縮または伸長する際に、出力先をファイルではなく標準出力とします。このオプションには --keep の指定
が暗に含まれます。
--single-stream
.xz の入力ストリームから最初の 1 つだけを伸長します。そしてそのストリームの続きとして入力データが
残っていても、そのことを示さずに無視します。ただし通常は、そういったゴミデータが続いていると xz は
エラーを出力します。
xz では .lzma ファイルや生の (raw) ストリームからの複数ストリームは伸長処理を行いません。そこでこ
のオプションを利用しておけば、.lzma ファイルや生のストリームの次にくるゴミデータを無視できます。
本オプションは、オペレーションモードが --decompress または --test である場合には何も行いません。
--no-sparse
スパース (sparse) ファイルを生成しないようにします。伸長処理によって通常ファイルを生成する際に、伸
長したデータ内にバイナリ値ゼロの並びが長く続く場合、xz はデフォルトでスパースファイルを生成しよう
とします。このような処理は、たとえ出力先が標準出力であっても、この標準出力が通常ファイルに結びつい
ていて、かつ所定の条件をいくつか満たすことで安全に処理が進められるのであれば、同様に処理されま
す。スパースファイルを生成すれば、ディスク容量を節約できます。またディスク I/O の回数が減るの
で、伸長処理時間が短縮されます。
-S .suf, --suffix=.suf
圧縮処理においては、目的とするファイルのサフィックスを .xz や .lzma ではなく .suf とします。標準出
力への書き出しではなく、ソースファイルがすでにサフィックス .suf を持っていた場合は、警告メッセージ
が表示されて、そのファイルの処理はスキップされます。
伸長処理においては、ファイルのサフィックスを .xz, .txz, .lzma, .tlz に加えて .suf を扱うようにしま
す。ソースファイルのサフィックスが .suf である場合、このサフィックスを取り除いたものを目的のファイ
ル名とします。
生の (raw) ストリームを圧縮または伸長する場合 (--format=raw)、標準出力に書き込む場合を除き、サ
フィックスは必ずつけなければなりません。生のストリームに対するデフォルトのサフィックスがないためで
す。
--files[=file]
処理対象とする file のファイル名を読み込みます。file を省略した場合、ファイル名は標準入力から読み
込まれます。ファイル名は改行文字によって終了していなければなりません。ダッシュ (-) は通常のファイ
ル名として扱われます。つまり標準入力を意味するものではありません。ファイル名がコマンドライン引数か
らも指定された場合、file からファイル名を読み込む前にその指定が処理されます。
--files0[=file]
これは --files[=file] と同等です。ただしこれを利用する場合、各ファイル名はヌル文字で区切られていな
ければなりません。
基本的なファイルフォーマットと圧縮オプション
-F format, --format=format
圧縮または伸長を行う際のファイルフォーマットを format に指定します。
auto これがデフォルトの設定です。圧縮処理の場合、auto は xz と同じになります。伸長処理の場合、入
力ファイルのフォーマットは自動検出されます。ただし生の (raw) ストリーム (--format=raw によ
り生成される) は自動検出されません。
xz ファイルフォーマット .xz として圧縮します。また伸長時には .xz ファイルのみを受けつけます。
lzma, alone
古いファイルフォーマット .lzma として圧縮します。また伸長時には .lzma ファイルのみを受けつ
けます。別名 alone は LZMA Utils との後方互換性のために提供されています。
raw 生の (raw) ストリームを (ヘッダーはなしにして) 圧縮または伸長します。これは上級者向けの利用
を意図しています。生のストリームをデコードするためには、--format=raw の指定、および明示的な
フィルターチェーン (filter chain) の指定が必要です。フィルターチェーンは通常はコンテナー
ヘッダー内に保存されます。
-C check, --check=check
整合性チェックのタイプを指定します。このチェックは伸長データから計算され、.xz ファイル内に保存され
ます。本オプションは、.xz フォーマットへの圧縮時にのみ効果があります。つまり .lzma フォーマットで
は、整合性チェック機能はサポートされていません。整合性チェックは (もしあれば) .xz ファイルの伸長時
に検証されます。
サポートされる check のタイプは以下です：
none 整合性チェックを一切行いません。通常はあまりよくないことです。別の方法によってデータ整合性
が検証されるのであれば、このタイプを利用することができます。
crc32 IEEE-802.3 (Ethernet) による多項式を利用して CRC32 を計算します。
crc64 ECMA-182 による多項式を用いて CRC64 を計算します。これがデフォルトです。CRC32 に比べる
と、破損ファイルの検出に若干有利であり、処理速度の違いは気にならない程度であるからです。
sha256 SHA-256 を計算します。CRC32 や CRC64 に比べると、処理速度がやや劣ります。
.xz ヘッダーの整合性を、常に CRC32 によって検証します。これを変更したり無効化することはできませ
ん。
--ignore-check
伸長時に圧縮データの整合性チェックを検証しません。.xz ヘッダー内にある CRC32 値は、それでも普通に
検証されます。
このオプションが何を行うのかを理解していない場合は利用しないでください。 本オプションを利用する状
況は以下のとおりです：
• 壊れた .xz ファイルからデータ回復を試みる場合。
• 伸長処理の速度改善を図る場合。このオプションが効果があるのは、たいていは、 SHA-256 を利用する場
合、または極めて効率よく圧縮されたファイルの場合です。ただしこの目的であっても、外部の別手段を
利用してファイル整合性の検証を完全に行う場合を除き、推奨されません。
-0 ... -9
圧縮プリセットレベル (preset level) を選択します。デフォルトは -6 です。複数のプリセットレベルが指
定された場合、最後に指定されたものが採用されます。カスタムフィルターチェーン (custom filter chain)
がすでに指定されている場合、圧縮プリセットレベルの指定により、そのカスタムフィルターチェーンの指定
は解除されます。
プリセットの違いは、gzip(1) や bzip2(1) にはない重要な意味があります。圧縮処理に対するプリセット指
定は、伸長時におけるメモリ容量を決定づけます。したがってより高度なプリセットレベルを用いると、小容
量の RAM しかない旧来のシステムでは、伸長時に相当な負荷がかかるかもしれません。特に gzip(1) や
bzip2(1) では -9 をよく指定しますが、xz では 何も考えず常に -9 を用いるのは得策ではありません。
-0 ... -3
比較的速いプリセットです。-0 は gzip -9 よりも圧縮性能がよく、高速に処理されます。より高い
プリセット値では、bzip2(1) と同等またはそれ以上の圧縮率が得られ、より高速に処理されます。た
だしこの結果は、圧縮を行うデータタイプに大きく依存します。
-4 ... -6
古いシステムでの利用時でも伸長処理におけるメモリ利用は妥当なもので、圧縮処理も良好に行われ
ます。-6 がデフォルトです。たとえば、たった 16 MiB の RAM しかないシステム上において伸長処
理を行うことになっても、これを選んでおけば間違いはなく、配布を問題なく行うことができま
す。(-5e や -6e を選ぶことも有効かもしれません。--extreme 参照のこと。)
-7 ... -9
これらは -6 と同様ですが、より高圧縮になるとともに、伸長時はより多くのメモリを必要としま
す。これが有効になるのは、圧縮ファイルがそれぞれ 8 MiB, 16 MiB, 32 MiB を超える場合です。
同一のハードウェア上であれば、伸長にかかる処理速度は毎秒、データ圧縮に要したバイト数の倍数にほぼ一
致します。言い換えると、通常は圧縮率が高ければ伸長処理は速くなります。ということはつまり、単位時間
内に生成される伸長処理の出力データ量は、状況によりさまざまであるということです。
以下の表はプリセットの特徴をまとめたものです。
プリセット DictSize CompCPU CompMem DecMem
-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
各カラムは以下のとおりです。
• DictSize とは LZMA2 辞書サイズです。辞書を利用すると、伸長するファイルサイズ以上にメモリを消費
します。つまり -7 ... -9 は、本当に利用する必要がないのであれば、用いるべきでない理由がここにあ
ります。-6 またはこれ未満において、消費されるメモリ容量は通常は十分に少なく、問題にならない程度
です。
• CompCPU とは LZMA2 設定における簡易表現であり、圧縮速度に影響を及ぼすものです。辞書サイズももち
ろん速度に影響します。したがって CompCPU が同一である -6 ... -9 に対しては、プリセット値が高く
なるほど、処理速度が低下する傾向にあります。処理が低下するということは、その分、圧縮率が向上す
る可能性があります。--extreme を参照してください。
• CompMem はシングルスレッドモードにおいて、圧縮処理時のメモリ消費量を表します。これは xz バー
ジョンが異なることで変化する場合があります。メモリ消費量は、マルチスレッドモードでの機能によっ
ては、シングルスレッドモードよりも急激に高まる場合があります。
• DecMem は伸長処理時におけるメモリ消費量を表します。つまり圧縮時の設定が、伸長処理時のメモリ消費
量を決定づけるものです。実際に伸長処理におけるメモリ消費量は、LZMA2 辞書サイズより若干大きくな
ります。ただし上の表に示した値は、きれいな MiB 値になるように切り上げています。
-e, --extreme
指定されているプリセットレベル (-0 ... -9) に比較して、より遅い処理方式 (variant) を用います。これ
により少しでも高圧縮率が得られるようにします。ただし場合によっては、期待に沿わない結果となることも
あります。伸長処理時におけるメモリ利用量には影響しません。ただし圧縮処理時のメモリ利用量は、そのと
きのレベルが -0 ... -3 である場合には若干増加します。
辞書サイズを 4 MiB、8 MiB とするプリセットが 2 つずつあり、プリセット -3e と -5e はそれぞれ -4e と
-6e に比べて若干高速になる (CompCPU は低くなる) 設定です。このようにして 2 つのプリセットが異なる
ことになります。
プリセット DictSize CompCPU CompMem DecMem
-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
たとえば 8 MiB の辞書サイズとなるプリセットは、全部で 4 つあります。これらにおいて処理が高速となる
順は -5, -6, -5e, -6e です。
--fast
--best これらはそれぞれ -0 と -9 に対するエイリアスですが、やや誤解を招きやすいものです。これは LZMA
Utils との後方互換性のために提供されています。このオプションを利用することは避けてください。
--block-size=size
.xz フォーマットに圧縮する場合に、入力データを size バイトごとのブロックに分割します。このブロック
は互いに独立して圧縮されます。これはマルチスレッド対応のためであり、限定されたランダムアクセス伸張
を可能にします。このオプションによって、通常はマルチスレッドモードでのデフォルトブロックサイズを
オーバーライドします。ただしこのオプションは、シングルスレッドモードでも利用することができます。
マルチスレッドモードにおいては、size バイトのおよそ 3 倍分が、各スレッドの入出力バッファとして割り
当てられます。デフォルトの size は LZMA2 辞書サイズの 3 倍か、1 MiB のいずれか大きい方になりま
す。通常なら、LZMA2 辞書サイズの 2 ～ 4 倍か、最低 1 MiB が適正な値です。size に LZMA2 辞書サイズ
よりも小さな値を用いると、RAM を無駄に消費します。LZMA2 辞書のバッファはすべてが十分に利用されるこ
とはないためです。ブロックサイズはブロックヘッダー内に保存されます。これは xz の将来版において、マ
ルチスレッドでの伸長処理に利用される予定です。
シングルスレッドモードでは、デフォルトではブロック分割処理は行われません。本オプションを設定して
も、メモリ利用量には影響しません。サイズ情報はブロックヘッダーに保存されないため、シングルモードに
おいて生成されたファイルは、マルチスレッドで生成されたファイルと同一にはならなくなります。サイズ情
報を含んでいないということは、つまり xz の将来版において、マルチスレッドモードにおける伸長処理が不
能となる場合があることを意味します。
--block-list=sizes
.xz フォーマットに圧縮する場合に、非圧縮データから指定された間隔分をあけて、新たなブロックを開始し
ます。
非圧縮ブロックの sizes は、カンマ区切りリストとして指定します。サイズを省略する (2 つ以上の連続し
たカンマのみを記述する) と、それは省略表記として前ブロックのサイズを利用する指定となります。
入力ファイルが size の合計よりも大きかった場合、sizes の最後に指定された値を用いて、入力ファイルを
繰り返し処理します。特別な設定値として 0 を用いると、これが最終の値として用いられ、ファイルの残り
のデータを単一のブロックとしてエンコード処理を行うことを指示します。
sizes に設定した値が、エンコード処理するブロックサイズ (スレッドモードにおけるデフォルト値、あるい
は --block-size=size に指定された値) を超える場合、sizes に指定されたブロック範囲を超えたところで
追加のブロックを生成します。たとえば--block-size=10MiB --block-list=5MiB,10MiB,8MiB,12MiB,24MiB と
指定し、入力ファイルが 80 MiB であった場合、合計で 11 ブロック、つまり順番に 5, 10, 8, 10, 2, 10,
10, 4, 10, 10, 1 MiB のブロックとなります。
マルチスレッドモードの場合、ブロックサイズはブロックヘッダー内に保存されます。これはシングルスレッ
ドモードでは行われません。したがってエンコード処理結果は、マルチスレッドモードによるものとは同一に
なりません。
--flush-timeout=timeout
圧縮時に、前回のフラッシュ処理からtimeoutミリ秒(正の整数)以上経過し、それ以上の入力を読み取るとブ
ロックされるような場合、処理中断していた入力データがエンコード処理からフラッシュされて、出力スト
リームでの利用が可能になります。こういった処理は、xz がネットワーク越しにストリームされたデータを
圧縮する際に活用されます。timeout に小さな値を設定しておくと、受信したデータの最終分を利用する際
に、わずかな遅延を起こすものとなります。もっともこの timeout に大きな値を設定しておけば、高圧縮率
が得られます。
この機能はデフォルトでは無効化されています。本オプションが複数回指定されると、最後の指定が適用され
ます。特別な値として timeout に 0 を設定すると、本機能を明示的に無効にするものとなります。
本機能は非 POSIX システム上では利用できません。
なお 本機能はまだ実験段階のものです。 今のところ xz のバッファリング方法に問題があるため、ストリー
ムをリアルタイムで伸長する処理には適していません。
--memlimit-compress=limit
圧縮時のメモリ利用制限を設定します。本オプションが複数回指定された場合、最後の指定が適用されます。
圧縮設定が limit を超えた場合、xz はその設定を引き下げて、制限を超えないようにします。そして自動調
整がなされたことを出力表示します。このような調整処理は、圧縮処理にあたって --format=raw や
--no-adjust が指定された場合には行われません。この場合 xz はエラーを表示して、終了ステータス 1 を
返して終了します。
limit を指定する方法はいくつかあります。
• limit にバイト数の絶対値を指定します。この際には MiB のような整数サフィックスを利用するのが便利
です。たとえば --memlimit-compress=80MiB とします。
• limit に物理メモリ (RAM) の総容量に対するパーセントを指定することができます。環境変数
XZ_DEFAULTS を用いてさまざまなコンピューター間において、シェル初期化スクリプトを利用するような
場合に特に活用することができます。この方法を用いると、よりメモリ容量の多いシステムでは、自動的
に制限値が大きくなります。たとえば --memlimit-compress=70% とします。
• limit を 0 に指定すれば、デフォルト設定に戻すことができます。現時点では limit に max (メモリ利
用制限なし) と指定することと同じです。ただし、マルチスレッド対応が実装されたら、マルチスレッド
処理時の 0 と max の意味が変わるかもしれません。したがって詳細が決定するまでの間は、max ではな
く 0 を用いておくことをお勧めします。
32 ビット版 xz には特別なケースがあります。limit の設定が 4020 MiB を超える場合、limit は 4020 MiB
に設定されます。(そうなったとしても 0 と max には影響しません。なお伸長処理にこのような機能はあり
ません。) この機能が他に支障を引き起こさない限りは、32 ビット実行モジュールが 4 GiB アドレス空間に
アクセスするものとして有用です。
メモリ利用 のセクションも参照してください。
--memlimit-decompress=limit
伸長時のメモリ利用制限を設定します。これは --list モードに影響します。limit を超えなければ処理でき
なくなった場合、xz はエラーを表示して伸長処理は失敗します。limit の設定する別の方法については
--memlimit-compress=limit を参照してください。
-M limit, --memlimit=limit, --memory=limit
これは --memlimit-compress=limit --memlimit-decompress=limit と指定することと同じです。
--no-adjust
圧縮設定がメモリ利用制限を超えた場合、xz はエラーを表示して終了します。デフォルトでは、設定内容は
引き下げられる方向に調整されます。そのようにしてメモリ利用制限を超えないようにします。この自動調整
機能は、生の (raw) ストリーム生成時 (--format=raw 指定時) は常に無効です。
-T threads, --threads=threads
ワーカースレッド数を指定します。threads に対して特別な値 0 を指定すると、xz はシステム上の CPU コ
ア分のスレッドを利用します。実際のスレッド数は threads の指定値より小さくなることがあります。それ
は入力ファイルのサイズが、指定されたスレッドを必要とするほどには大きくない場合や、スレッドを多く利
用しすぎることによってメモリ利用制限を超える場合などです。
現在行われているスレッド処理方法は 1 つだけです。入力データをブロック分けして、互いに独立して圧縮
を行うという方法です。デフォルトのブロックサイズは、圧縮レベルに依存します。これは
--block-size=size オプションによってオーバーライドすることができます。
伸長処理時のスレッド化はまだ実装されていません。スレッド化に対応しているのは、入力ファイルに複数ブ
ロックが含まれていて、そのサイズ情報がブロックヘッダーに存在しているファイルのみです。マルチスレッ
ドモードにおいて圧縮されたファイルは、この条件をすべて満たします。しかしシングルスレッドモードにお
いて圧縮されたファイルでは、--block-size=size を指定していたとしても、この条件を満たしません。
カスタム圧縮フィルターチェーン
カスタムフィルターチェーン (custom filter chain) を用いると、圧縮設定を細かく設定することができ、プリセッ
ト値に関連づいた設定に頼る必要がなくなります。カスタムフィルターチェーンが指定されると、コマンドライン上
でプリセットオプション (-0 ... -9 および --extreme) が初めに指定されていても無視されます。また複数のカス
タムフィルター指定の後ろにプリセットオプションが指定された場合は、新たな意味になるプリセット指定が採用さ
れて、それよりも前に指定されていたカスタムフィルターチェーンは無視されます。
フィルターチェーンというものは、コマンドライン上のパイプ処理と同じように動作します。圧縮時には、伸長され
ている入力データが 1 つめのフィルターに受け渡されます。そしてその出力は、次のフィルターがあればそこに受け
渡されます。最終のフィルターから出力される結果が、圧縮ファイルとして書き出されます。指定できるフィルター
チェーンは最大 4 つまでです。通常、フィルターチェーンを利用するのは、せいぜい 1 つか 2 つまでです。
フィルターの多くは、どこに記述するかという制限があります。たとえばフィルターの中にはチェーン内の最終フィ
ルターとしてしか動作しないものがあります。逆に最終フィルターとしては動作しないものもあります。もちろんど
の場所に置いても動作するものも存在します。フィルターにもよりますが、こういった制約はフィルター設計によっ
て発生している場合や、セキュリティ問題を回避するために存在している場合もあります。
カスタムフィルターチェーンは、フィルターオプションを必要な分だけ、またフィルターチェーンの中で実行させた
い順番で指定します。つまりフィルターオプションとして指定する順番が極めて重要です。生の (raw) ストリーム
(--format=raw 指定) をデコードする際には、それが圧縮された際に指定された順番どおりのフィルターチェーンを
指定します。
フィルターには、フィルター固有の options があり、カンマで区切ったリストにより指定します。options に余計な
カンマがあると無視されます。すべてのオプションにはデフォルト値が設定されています。したがってオプション
は、変更したいもののみ指定するだけで十分です。
フィルターチェーンと options をすべて見るには xz -vv を入力します (つまり --verbose を 2 回指定しま
す)。これにより、プリセットが利用するフィルターチェーンオプションも参照することができます。
--lzma1[=options]
--lzma2[=options]
フィルター LZMA1 および LZMA2 をフィルターチェーンに追加します。これらのフィルターは、チェーン内の
最終フィルターとしてのみ利用できます。
LZMA1 は古いフィルターです。古い .lzma ファイルフォーマットは LZMA1 のみに対応していて、つまりこの
フィルターは .lzma 向けだけにサポートされています。LZMA2 は LZMA1 の更新版であり、LZMA1 が抱えてい
る具体的な問題を修正しています。.xz フォーマットは LZMA2 を利用していて、LZMA1 には一切対応してい
ません。圧縮速度および圧縮率は、LZMA1 と LZMA2 において実質変わりません。
LZMA1 と LXMA2 における options は共通しています。
preset=preset
LZMA1 および LZMA2 の options をすべて preset にリセットします。preset は整数により構成さ
れ、英字 1 文字からなるプリセット修飾子をつける場合があります。整数とは 0 から 9 までの値で
あり、コマンドラインオプション -0 ... -9 に対応します。プリセット修飾子とは、今のところ e
というもののみがサポートされています。これは --extreme に対応します。preset の指定がなかっ
た場合、LZMA1 および LZMA2 の options はともにプリセット 6 に対応する値がデフォルトして採用
されます。
dict=size
辞書の (履歴バッファの) size は、直近にメモリ上で処理され保持されている伸長データのバイト量
を表します。そのアルゴリズムでは、伸長データの中からバイトシーケンスの繰り返し (合致するも
の) を探し出そうとします。そしてその時点での辞書内データへの参照に置き換えます。辞書が大き
くなれば、それだけ合致する機会は増えることになります。つまり辞書の size を増やしておけ
ば、普通は圧縮率が向上します。ただし伸長ファイル以上に辞書サイズが大きいと、メモリを無駄に
消費します。
辞書の size は通常は 64 KiB から 64 MiB です。最小でも 4 KiB です。圧縮用の最大値は、今のと
ころ 1.5 GiB (1536 MiB) です。伸長処理においては 4 GiB 未満、1 バイトまでの辞書がすでにサ
ポートされています。4 GiB は LZMA1 および LZMA2 のストリームフォーマットにおける最大値で
す。
辞書の size とマッチ検索処理 (match finder; mf) はともに、LZMA1 または LZMA2 のエンコード処
理におけるメモリ利用量を決定づけます。伸長処理においては、圧縮時に用いられた辞書 size と同
じ (あるいはそれよりも大きい) サイズが必要になります。つまり伸長処理時のメモリ利用量は、圧
縮時に用いられた辞書サイズによって決定します。.xz ヘッダーには辞書の size が、2^n または
2^n + 2^(n-1) のいずれかとして保存されます。したがってこの sizes はどちらかと言うと、圧縮時
に適したものです。これ以外の sizes は .xz ヘッダーに保存される際に切り上げられます。
lc=lc リテラルコンテキスト (literal context) のビット数を指定します。最小値は 0、最大値は 4、デ
フォルトは 3 です。また lc と lp を合計した値は 4 を超えてはなりません。
エンコード処理に際して合致しなかったバイトは、すべてリテラルとしてエンコードされます。つま
りリテラルとは、1 回に 1 つずつエンコードされる、単純な 8 ビットのバイト列です。
リテラルの処理では、直前に伸長したバイトの上位 lc ビットは、次のバイトと相関関係にあること
を前提にしています。たとえば通常の英文の場合、英大文字の次にたいていは小文字が続きます。そ
してその小文字の次には、たいていは別の小文字が続きます。また US-ASCII キャラクターセットの
場合、大文字の上位 3 ビットは 010 であり、小文字の場合は 011 です。lc が最低 3 として設定さ
れていれば、リテラル処理は伸長データ内のこの特性を利用することができます。
デフォルト値 (3) は通常はうまく動作します。圧縮率を最大にしたい場合は lc=4 を試してみてくだ
さい。これによって多少はうまくいくことがありますが、場合によっては圧縮率が悪くなることもあ
ります。もし悪くなった場合には lc=2 といった指定も試してみてください。
lp=lp リテラルポジション (literal position) のビット数を指定します。最小値は 0、最大値は 4、デ
フォルトは 0 です。
lp はリテラルをエンコードする際に、伸長データ内においてどのようなバイトの並び (alignment)
を前提にするのかという点に影響します。バイトの並びに関する詳細は、以下の pb を参照してくだ
さい。
pb=pb ポジションのビット数を指定します。最小値は 0、最大値は 4、デフォルトは 2 です。
pb は全般に、伸長データ内においてどのようなバイトの並び (alignment) を前提にするのかという
点に影響します。デフォルト値は 4 バイトの並びを意味します (2^pb=2^2=4)。他に類推する手段が
ない場合には、これがうまく動作します。
バイトの並び方がわかっている場合、それに応じて pb を設定しておけば、ファイルサイズをやや小
さくできる場合があります。たとえば 1 バイト並びのテキストファイル (US-ASCII, ISO-8859-*,
UTF-8) の場合、pb=0 に設定しておくと、圧縮率がやや向上します。UTF-16 テキストであれば pb=1
とするのが最適です。バイトの並びが 3 バイトなどのような奇数である場合、pb=0 とするのが最良
かもしれません。
前提となったバイトの並びは pb や lp を使って調整ができますが、それでも LZMA1 や LZMA2 は 16
バイトの並びの方がふさわしいものです。したがって LZMA1 や LZMA2 を使って圧縮することが多い
ファイル形式を設計する場合には、このことに配慮しておく価値があるかもしれません。
mf=mf マッチ検索処理 (match finder) は、エンコード処理速度、メモリ利用量、圧縮率に大きな影響を与
えます。通常はバイナリツリーによるマッチ検索処理よりも、ハッシュチェーンによるマッチ検索処
理の方が早くなります。デフォルト値は preset の値により変わります。0 のときは hc3、1-3 のと
きは hc4、それ以外は bt4 がデフォルトになります。
マッチ検索処理は以下に示すものがサポートされます。以下に示すメモリ利用計算式 (memory usage
formulas) はかなりの概算であり、dict が 2 のべき乗である場合に、実際の値に最も近くなりま
す。
hc3 2 バイトまたは 3 バイトハッシング (hashing) を用いたハッシュチェーン (hash chain)。
nice の最小値は 3 です。
メモリ利用量：
dict * 7.5 (dict <= 16 MiB である場合);
dict * 5.5 + 64 MiB (dict > 16 MiB である場合)
hc4 2 バイト、3 バイト、4 バイトハッシングを用いたハッシュチェーン。
nice の最小値は 4 です。
メモリ利用量：
dict * 7.5 (dict <= 32 MiB である場合);
dict * 6.5 (dict > 32 MiB である場合)
bt2 2 バイトハッシングを用いたバイナリツリー (binary tree)。
nice の最小値は 2 です。
メモリ利用量: dict * 9.5
bt3 2 バイトと 3 バイトハッシングを用いたバイナリツリー。
nice の最小値は 3 です。
メモリ利用量：
dict * 11.5 (dict <= 16 MiB である場合);
dict * 9.5 + 64 MiB (dict > 16 MiB である場合)
bt4 2 バイト、3 バイト、4 バイトハッシングを用いたバイナリツリー。
nice の最小値は 4 です。
メモリ利用量：
dict * 11.5 (dict <= 32 MiB である場合);
dict * 10.5 (dict > 32 MiB である場合)
mode=mode
圧縮の mode は、マッチ検索処理によって生成されるデータの分析手法を指定します。サポートされ
る modes は fast と normal です。デフォルトは presets が 0-3 のとき fast、presets が 4-9 の
とき normal です。
一般的に fast が用いられるのはハッシュチェーンによるマッチ検索処理の場合であり、normal はバ
イナリツリーによるマッチ検索処理の場合です。これは presets が用いるものと同じです。
nice=nice
マッチ処理に対して適切なバイト数と思われる値を指定します。最低 nice バイト分にマッチしたと
き、アルゴリズムはそれ以上、マッチする可能性をあきらめて探さないようにします。
Nice は 2 ～ 273 バイトの範囲とします。値を大きくすれば処理速度は低下しますが、より高い圧縮
率が得られる傾向にあります。デフォルト値は preset の値によって変わります。
depth=depth
マッチ検索処理において、検索する最大深さを指定します。デフォルトは特別な値 0 です。この値
は、圧縮処理において mf と nice の値から妥当な値 depth が決定されることを意味します。
ハッシュチェーンに対しての妥当な depth の値は 4 ～ 100 です。バイナリツリーでは 16 ～ 1000
です。depth に対して非常に大きな値を設定すると、ファイル内容によってはエンコード処理が極端
に遅くなる場合があります。時間が無用に長くなりすぎた際に圧縮を取りやめる段取りが整っていな
いのであれば、depth に 1000 以上の値を設定することは避けてください。
生の (raw) ストリーム (--format=raw 指定) に対するデコード処理の際には、LZMA2 は辞書サイズ size だ
けが必要です。LZMA1 の場合は lc, lp, pb だけあれば十分です。
--x86[=options]
--powerpc[=options]
--ia64[=options]
--arm[=options]
--armthumb[=options]
--sparc[=options]
branch/call/jump (BCJ) フィルターをフィルターチェーンに追加します。このフィルターは、フィルター
チェーン内の最終フィルターとして利用することはできません。
BCJ フィルターは、マシンコード内の相対アドレスを絶対アドレスに変換します。これによりデータサイズは
変わりません。ただし冗長性は増します。LZMA2 からは 0 ～ 15 % 小さな .xz ファイルが生成されることに
なります。BCJ フィルターはいつでも元に戻すことができます。つまり誤ったデータタイプに対して BCJ
フィルターを用いても、データを失うことはありません。ただし圧縮率がやや低下することがあります。
BCJ フィルターを実行ファイル全体に適用しても、問題はありません。そしてこのフィルターを実行ファイル
の実行セクション (executable section) にのみ適用する必要はありません。実行モジュールと実行不可ファ
イルを両方含むアーカイブに対してこのフィルターを適用すると、良い結果が得られる場合もあり、そうでな
い場合もあります。したがって一般的には、バイナリパッケージを配布向けに圧縮する際にまで、BCJ フィル
ターを用いるのは適切ではありません。
この BCJ フィルターは非常に高速であり、目立ったメモリ消費は発生しません。BCJ フィルターによって
ファイル圧縮率が向上したとすれば、伸長処理の速度が向上します。なぜなら同一のハードウェア上であれ
ば、伸長にかかる処理速度は毎秒、データ圧縮に要したバイト数の倍数にほぼ一致するからです。
この BCJ フィルターには、圧縮率に関して以下のような問題があります。
• 実行コードを含んだファイル (たとえばオブジェクトファイル、スタティックライブラリ、Linux カーネ
ルモジュールなど) の中には、命令内のアドレスにフィルター値が埋め込まれることになります。この
BCJ フィルターは、それでもアドレス変換を続行しますが、そういったファイルにおいては圧縮率が悪く
なる場合があります。
• 似通った実行ファイルが複数含まれるアーカイブに対して BCJ フィルターを適用すると、BCJ フィルター
を使わなかった場合に比べて圧縮率が悪くなります。これは BCJ フィルターが実行ファイル間の境界を検
出しないためであり、各実行ファイルに対してアドレス変換のカウンターをリセットしないことから発生
します。
将来的には新たなフィルターを通じて、上記の 2 つの問題は解消される予定です。従来の BCJ フィルター
は、埋め込みシステムにおいては引き続き有用となるはずです。というのも、新たなフィルターはより大きく
なり、メモリ消費も増加するはずだからです。
命令セットが異なるとバイトの並びも異なります:
フィルター Alignment 説明
x86 1 32 ビット、64 ビット x86
PowerPC 4 ビッグエンディアンのみ
ARM 4 リトルエンディアンのみ
ARM-Thumb 2 リトルエンディアンのみ
IA-64 16 ビッグエンディアンおよびリトルエンディアン
SPARC 4 ビッグエンディアンおよびリトルエンディアン
BCJ フィルターによって処理したデータは、通常は LZMA2 によって圧縮されるので、利用された BCJ フィル
ターのバイト並びにマッチするように LZMA2 オプションが設定されていれば、圧縮率はわずかながら改善さ
れます。たとえば IA-64 フィルターを用いた場合、LZMA2 に対しては pb=4 (2^4=16) とするのが適切で
す。ただし、x86 フィルターの場合は例外と考えてください。x86 実行ファイルを圧縮する場合には、LZMA2
のデフォルトである 4 バイト並びを必ず用いるようにするのが適切です。
BCJ フィルターはすべて同一の options をサポートします。
start=offset
相対および絶対アドレス間の変換の際に用いられる、オフセット値 offset の開始位置を指定しま
す。offset はフィルターのバイト並びの倍数でなければなりません (上表参照)。デフォルトはゼロ
です。現実にはデフォルト値で十分です。つまり offset を独自に設定しても、たいていは役に立ち
ません。
--delta[=options]
フィルターチェーンにデルタ (delta) フィルターを追加します。デルタフィルターは、フィルターチェーン
内の最終フィルターとして利用することはできません。
現時点では、単純にバイト単位によるデルタ計算のみがサポートされています。これはたとえばビットマップ
イメージあるいは PCM オーディオを圧縮する際に利用できます。ただし特別に用意されたアルゴリズムを使
えば Delta + LZMA2 よりも優れた結果が得られるかもしれません。これはオーディオデータに対しては明ら
かなことで、flac(1) などを用いれば、圧縮はより速く適切なものになります。
サポートされている options：
dist=distance
デルタ計算の distance をバイト単位で指定します。distance は 1 ～ 256 であることが必要で
す。デフォルトは 1 です。
たとえば dist=2 を指定し、入力が 8 バイト A1 B1 A2 B3 A3 B5 A4 B7 であったとすると、出力は
A1 B1 01 02 01 02 01 02 となります。
その他のオプション
-q, --quiet
警告メッセージや通知メッセージを省略します。この指定を 2 つ重ねると、エラーメッセージも省略しま
す。本オプションは終了ステータスには影響しません。警告メッセージがたとえ省略されていても変わらない
ことなので、終了ステータスには警告を示す値が返されます。
-v, --verbose
詳細な出力とします。標準エラー出力が端末に接続されている場合、xz は進捗インジケーターを表示しま
す。--verbose を 2 つ重ねて指定すると、さらに詳細な出力が行われます。
進捗インジケーターには以下の情報が表示されます。
• 入力ファイルのサイズがわかっている場合は、完了率が表示されます。これはパイプ処理の場合には表示
されません。
• 生成された圧縮データ量 (圧縮時) または消費された圧縮データ量 (伸長時) が表示されます。
• 消費された伸長データ量 (圧縮時) または生成された伸長データ量 (伸長時) が表示されます。
• 圧縮率が表示されます。これはその時点までに圧縮されたデータ量を、未圧縮のデータ量で割った値とし
て算出されます。
• 圧縮または伸長の処理速度が表示されます。これは消費された伸長データ (圧縮時) または生成された伸
長データ (伸長時) の秒ごとの処理量です。処理量の表示は xz がファイル処理を開始した後、しばらく
たってから表示されます。
• 経過時間を M:SS または H:MM:SS の書式により表示します。
• 入力ファイルのサイズがわかっている場合だけ、残り時間の見積もりが表示されます。その場合、xz が
ファイル処理を開始してから、数秒が経過した後に表示が始まります。時刻表記は精度を落として、小数
点表記を行いません。たとえば 2 min 30 s とします。
標準エラー出力先が端末ではない場合、--verbose によって出力される内容は、ファイル名、圧縮サイズ、伸
長サイズ、圧縮率です。また圧縮あるいは伸長が始まると、表示可能であれば処理速度や経過時間を 1 行に
まとめて標準エラー出力に書き出します。処理速度や経過時間が表示されるのは、あくまで処理時間が一定秒
数以上かかる場合のみです。ユーザーによる処理中断のように処理が完了しなかった場合でも、入力ファイル
サイズがわかっていれば、完了率は表示されます。
-Q, --no-warn
警告に相当する状況が発生したとしても、終了ステータスは 2 に設定しないでください。本オプションは詳
細表示のレベルには影響しません。したがって --quiet と --no-warn の 2 つは、警告を非表示とするため
に利用するものであって、終了ステータスを変更する目的で用いてはなりません。
--robot
マシン解析が可能な書式でメッセージ出力を行います。これは liblzma でなく xz を利用したフロントエン
ドを容易に構築できるように意図したものです。さまざまなスクリプトを用いることが想定されるでしょ
う。本オプションを使って出力した結果は、xz の将来のリリースに向けて安定して提供していくつもりで
す。詳しくは ロボットモード セクションを参照してください。
--info-memory
読みやすい書式で以下の出力を行います。xz が識別している、システム搭載の物理メモリ (RAM) 量。圧縮お
よび伸長におけるメモリ利用制限。これを表示して正常終了します。
-h, --help
よく利用されるオプションに対するヘルプメッセージを表示して、正常終了します。
-H, --long-help
xz の全機能を説明するヘルプメッセージを表示して、正常終了します。
-V, --version
xz と liblzma のバージョン番号を読みやすい書式で表示します。マシンが解析しやすい出力とするに
は、--version の前に --robot を指定します。
ロボットモード
ロボットモードは --robot オプションを指定することで有効になります。これを指定すると、別プログラムが xz の
出力を解析しやすくなります。今のところ --robot は、--version, --info-memory, --list をともに指定したとき
のみ機能するようになっています。将来は圧縮時、伸長時にも対応する予定です。
バージョン
xz --robot --version を実行すると、xz と liblzma のバージョンを以下の書式により出力します:
XZ_VERSION=XYYYZZZS
LIBLZMA_VERSION=XYYYZZZS
X メジャーバージョン。
YYY マイナーバージョン。偶数が安定版を意味します。奇数はアルファ版かベータ版を表します。
ZZZ 安定版に対するパッチレベル。または単に開発版の割り振り番号。
S 安定度。0 はアルファ版、1 はベータ版、2 は安定版をそれぞれ表します。YYY が偶数のとき S は必ず 2 と
なります。
xz と liblzma が同一 XZ Utils リリースのものである限り、2 行に表示されている XYYYZZZS の表記は同一になり
ます。
例： 4.999.9beta は 49990091、5.0.0 は 50000002 と表記されます。
メモリ制限に関する情報
xz --robot --info-memory を指定すると、タブで区切った 3 つの情報を 1 行で出力します：
1. 物理メモリ (RAM) の総容量。バイト単位。
2. 圧縮時のメモリ利用制限。バイト単位。特別な値としてゼロがあります。これはシングルスレッドモードでのデ
フォルト値であり、無制限を意味します。
3. 伸長時のメモリ利用制限。バイト単位。特別な値としてゼロがあります。これはシングルスレッドモードでのデ
フォルト値であり、無制限を意味します。
xz --robot --info-memory の出力項目は、今後追加される可能性があります。ただし複数行にわたって出力するよう
な変更は行いません。
リストモード
xz --robot --list はタブ区切りによる出力を行います。各行における先頭カラムは、それぞれの行に示される情報
の種類を表します。
name ファイルの一覧を示す際にはこれが必ず第 1 行目に置かれます。その行の第 2 カラムにはファイル名が出力
されます。
file この行には .xz ファイルに関する全体的な情報が示されます。この行は必ず name 行の次に表示されます。
stream この行タイプは --verbose が指定された場合にのみ表示されます。.xz ファイル内に存在するストリーム分
だけ stream 行が出力されます。
block この行タイプは --verbose が指定された場合にのみ表示されます。.xz ファイル内に存在するブロック分だ
け block 行が出力されます。block 行は stream 行の出力がすべて行われた後に出力されます。つまりタイ
プの異なる両者が混在して出力されることはありません。
summary
この行タイプは --verbose が 2 重に指定された場合にのみ表示されます。この行は block 行の次に出力さ
れます。file 行と同様に summary 行には .xz ファイルに関する全体的な情報が示されます。
totals 本行は必ず出力結果の最終行に位置します。ここには総数、総サイズが示されます。
file 行のカラム：
2. ファイル内のストリーム数。
3. ストリーム内のブロック総数。
4. ファイルの圧縮サイズ。
5. ファイルの伸長サイズ。
6. 圧縮率。たとえば 0.123 など。圧縮率が 9.999 を超える場合は、圧縮率は表示せず 3 つのダッシュ
(---) が表示されます。
7. 整合性チェックの名称をカンマ区切りで指定したリスト。既知の整合性チェック名として、以下の表記が
用いられます。None, CRC32, CRC64, SHA-256。未知のチェックタイプには Unknown-N が用いられま
す。ここで N は 10 進数 (1 桁または 2 桁) で表されるチェック ID です。
8. ファイル内ストリームのパディング (padding) データの総量。
stream 行のカラム：
2. ストリーム番号 (先頭を 1 とします)。
3. ストリーム内のブロック数。
4. 圧縮データの開始オフセット。
5. 伸長データの開始オフセット。
6. 圧縮サイズ (ストリームパディングを含みません)。
7. 伸長サイズ。
8. 圧縮率。
9. 整合性チェック名。
10. ストリームパディングのサイズ。
block 行のカラム：
2. 当ブロックに含まれるストリーム数。
3. ストリーム先頭からの相対的なブロック数 (先頭ブロックを 1 とします)。
4. ファイル先頭からの相対的なブロック数。
5. ファイル先頭からの相対的な圧縮開始オフセット。
6. ファイル先頭からの相対的な伸長開始オフセット。
7. ブロックの総圧縮サイズ (ヘッダーを含みます)。
8. 伸長サイズ。
9. 圧縮率。
10. 整合性チェック名。
--verbose が 2 重に指定された場合、block 行にはさらに以下のカラムが出力されます。これは --verbose が 1 つ
だけ指定された際には表示されません。この情報取得にあたってはさらにシークを必要とするため、その分だけ処理
が遅くなります。
11. 16 進数表記による整合性チェック値。
12. ブロックヘッダーサイズ。
13. ブロックフラグ。c は圧縮サイズが存在することを示します。u は伸長サイズが存在することを示しま
す。このフラグが設定されていない場合、固定幅の文字出力は行わずにダッシュ (-) だけを表示しま
す。将来の版においては、新しいフラグがこの文字列の後ろに追加されるかもしれません。
14. ブロック内の実際の圧縮データサイズ (ブロックヘッダー、ブロックパディング、チェック項目は除きま
す)。
15. xz の現バージョンを使って、このブロックの伸長を行うために必要となるメモリ利用量。バイト単位。
16. フィルターチェーン。圧縮時に利用されたオプションは、ほとんど知ることができません。.xz ヘッダー
にオプションが保存されますが、それは伸長時に必要となるオプションだけだからです。
summary 行のカラム：
2. xz の現バージョンを使って、このファイルの伸長を行うために必要となるメモリ利用量。バイト単位。
3. yes または no。全ブロックヘッダー内に、圧縮サイズと伸長サイズがともに保存されているかどうかを
表します。
xz 5.1.2alpha 以降：
4. ファイル伸長に必要となる xz の最低バージョン。
totals 行のカラム：
2. ストリーム数。
3. ブロック数。
4. 圧縮サイズ。
5. 伸長サイズ。
6. 圧縮率の平均。
7. ファイル内に存在している整合性チェック名をカンマで区切ったリスト。
8. ストリームパディングのサイズ。
9. ファイル数。ここにこのカラムを設けることで、これ以前のカラムの並びが file 行と同じになるように
します。
--verbose が 2 重に指定され totals 行にカラムが追加された場合：
10. xz の現バージョンを使って、このファイルの伸長を行うために必要となる最大メモリ利用量。バイト単
位。
11. yes または no。全ブロックヘッダー内に、圧縮サイズと伸長サイズがともに保存されているかどうかを
表します。
xz 5.1.2alpha 以降：
12. ファイル伸長に必要となる xz の最低バージョン。
将来の版において、新たな行タイプの追加、あるいは既存の行タイプへのカラム追加があるかもしれません。ただし
既存のカラムが変更されることはありません。
終了ステータス
0 正常終了。
1 エラー発生。
2 警告に相当する何かが発生。ただし実際のエラーが発生したわけではない。
通知 (警告やエラーではない) が標準エラー出力に表示されても、終了ステータスには影響しません。
環境変数
xz では環境変数 XZ_DEFAULTS および XZ_OPT からこの順で、設定された空白区切りのオプションを読み込みま
す。これは、コマンドラインから指定されたオプションよりも前に処理されます。環境変数から読み取られるのはオ
プションだけです。オプション以外の情報はすべて無視されます。オプションの読み込みは getopt_long(3) を使っ
て行われますが、コマンドライン引数の読み込みにも用いられています。
XZ_DEFAULTS
ユーザー定義あるいはシステムワイドなデフォルトオプションを指定します。通常はシェル初期化スクリプト
内において設定され、デフォルトで利用する xz のメモリ利用制限処理を有効にします。シェル初期化スクリ
プトあるいはこれに相当する特別なケースを除くと、スクリプトにおいて XZ_DEFAULTS を設定したり未設定
にしたりしてはなりません。
XZ_OPT xz コマンドラインからオプション指定ができない場合に、B(xz) にオプションを受け渡すために用いま
す。これを利用するのは、たとえばスクリプトから、あるいは GNU tar(1) のようなツールから xz を実行す
る場合です:
XZ_OPT=-2v tar caf foo.tar.xz foo
スクリプトにおいてそのスクリプト固有のデフォルト圧縮オプションを設定するために XZ_OPT を用いる場合
があります。その場合であっても XZ_OPT のオーバーライドが認められるのは、たとえば以下に示すように
sh(1) スクリプト内にて妥当な利用の仕方をする場合に限ります：
XZ_OPT=${XZ_OPT-"-7e"}
export XZ_OPT
LZMA Utils との互換性
xz のコマンドラインの文法は、実質的に LZMA Utils 4.32.x にある lzma, unlzma, lzcat のスーパーセットになっ
ています。LZMA Utils を用いる既存のスクリプトは、たいていは特に変更することなくそのまま XZ Utils に置き換
えることができます。ただし非互換性も存在しており、中には問題が発生する場合もあります。
圧縮プリセットレベル
圧縮レベルのプリセット値は xz と LZMA Utils において同一の番号振りにはなっていません。もっとも重要な違い
は、さまざまなプリセットに対する辞書サイズがどのように割り振られているか、という点です。辞書サイズは、お
おまかに言えば伸長処理時のメモリ利用量に等しくなります。
レベル xz LZMA Utils
-0 256 KiB なし
-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
辞書サイズの違いは、圧縮時でのメモリ利用量にも影響します。ただし LZMA Utils と XZ Utils の違いは他にあっ
て、その違いの方がより大きなものです。
レベル xz LZMA Utils 4.32.x
-0 3 MiB なし
-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
デフォルトのプリセットレベルは LZMA Utils では -7 ですが、XZ Utils では -6 です。ともにデフォルトで 8 MiB
の辞書を利用します。
ストリーム化されている/されていない .lzma ファイル
ファイルの伸長サイズは .lzma ヘッダーに保存されます。LZMA Utils は、通常のファイルを圧縮する際にはこれを
保存します。代替策として、伸長サイズが不明であるとマークしておき、ペイロード終了マーカー (end-of-payload
marker) を使って伸長処理の終了位置を示すこともあります。LZMA Utils はこの方法を、伸長サイズが不明なときに
利用します。たとえばパイプを使った場合がこの利用にあたります。
xz では .lzma ファイルを伸長する際に、ペイロード終了マーカーを利用することも利用しないこともできます。し
かし xz から生成された すべての .lzma に対しては、ペイロード終了マーカーを利用して、.lzma ヘッダー内に伸
長サイズが不明であるものとしてマークします。これは特殊なケースで問題となる場合があります。たとえば埋め込
みデバイス上での .lzma 伸長処理は、伸長サイズがわかっていないファイルでは動作しないかもしれません。このよ
うな問題に遭遇した場合は、LZMA Utils または LZMA SDK を利用して、伸長サイズが明確となっている .lzma ファ
イルを生成してください。
サポートされない .lzma ファイル
.lzma フォーマットが用いる lc 値は 8 まで、lp 値は 4 までです。LZMA Utils がファイル伸長する際には lc と
lp の値はどのような値であってもかまいませんが、ただし lc=3 かつ lp=0 のファイルが常に生成されます。これ以
外の lc や lp を生成するには xz か LZMA SDK を利用してください。
liblzma 内の LZMA1 フィルターの実装では、lc と lp の合計が 4 を超えてはならないものとなっています。した
がってこの制限を超えた .lzma ファイルは xz を使って伸長することはできません。
LZMA Utils が生成する .lzma ファイルは、辞書サイズが 2^n (2 のべき乗) のものだけです。ただしどのようなサ
イズのファイルでも受けることはできます。一方 liblzma が受け付けられるのは、辞書サイズが 2^n または 2^n +
2^(n-1) であるような .lzma ファイルのみです。これは .lzma ファイルを検出する際に、誤った検出を回避するた
めです。
上のような制約は現実に問題となることはありません。事実上 .lzma ファイルは liblzma が受け入れる設定すべて
を使って圧縮されるものとなっているからです。
ゴミデータ
LZMA Utils は伸長時に、最初の .lzma ストリーム以降のデータは完全に無視します。ほとんどの場合、これはバグ
になります。これはまた LZMA Utils が、連結された .lzma ファイルを伸長できないことを表しています。
.lzma の最初のストリーム以降にデータが残っている場合、xz は --single-stream が指定されていない限りは、そ
のファイルが壊れているとみなします。したがって、ゴミデータは無視されるという前提で作られているスクリプト
は、動作しなくなるかもしれません。
情報
圧縮結果はさまざま
同一の圧縮前ファイルを使って圧縮ファイルを生成したとしても、XZ Utils のバージョンが異なると、その生成結果
は異なることになります。それは圧縮オプションが全く同じであっても起こります。ファイルフォーマットに影響を
与えることなく、エンコード処理は常に (より高速に、より高圧縮に) 改善されているためです。XZ Utils のバー
ジョンが同一であっても、ビルド時のオプションが違っていると、生成結果が異なる場合があります。
このことは --rsyncable が実装された際には問題となります。rsync の機能を用いる際には、古いファイルと新しい
ファイルを同一の xz バージョンで圧縮しておかないと、rsync 処理ができないということになります。この問題を
解決するには、どちらかのエンコード実装を凍結して、xz バージョン間において安定して rsync 処理ができるよう
な出力とすることが必要になります。
埋め込み .xz の伸長処理
XZ Embedded のような埋め込み .xz 伸長処理の実装では、整合性チェックのうち none と crc32 以外のものを使っ
たファイル生成には対応する必要がありません。デフォルトは --check=crc64 ですから、埋め込みシステム上での
ファイル生成時は --check=none か --check=crc32 を指定しなければなりません。
埋め込みシステムを除くと、.xz フォーマットにおける伸長処理では、check タイプすべてに対応しています。ある
いは特定の check がサポートされていなかったとしても、最低でも整合性チェックの検証を行わずにファイル伸長処
理が可能となっています。
XZ Embedded は BCJ フィルターに対応しています。ただしデフォルトの開始オフセットしか利用できません。
利用例
基本
ファイル foo を圧縮して foo.xz を生成します。利用する圧縮レベルはデフォルト (-6) です。圧縮が成功したら
foo を削除します:
xz foo
bar.xz を伸長して bar を得ます。伸長処理に成功しても bar.xz は削除しません:
xz -dk bar.xz
プリセット -4e (-4 --extreme) を用いて baz.tar.xz を生成します。これはたとえばデフォルトの -6 に比べて処
理速度は低下しますが、圧縮時や伸長時のメモリ消費は少なくて済みます (それぞれ 48 MiB と 5 MiB)：
tar cf - baz | xz -4e > baz.tar.xz
圧縮されたファイルや未圧縮のファイルを混在させ、ただ 1 つのコマンドを使って標準出力を行うことができます:
xz -dcf a.txt b.txt.xz c.txt d.txt.lzma > abcd.txt
複数ファイルの並行圧縮処理
GNU および *BSD の find(1) や xargs(1) では、複数ファイルを並行処理により圧縮することができます:
find . -type f \! -name '*.xz' -print0 \
| xargs -0r -P4 -n16 xz -T1
xargs(1) に対する -P オプションが、xz 処理に対する並行処理数を設定しています。-n オプションの最適値は、ど
れだけのファイルを圧縮するかによって変わります。ファイル数がほんの数個である場合、おそらくこの値は 1 が適
切です。ファイル数が数万のレベルなら 100 以上が適切であり、これによって xargs(1) が最終的に作り出す xz プ
ロセスを抑えられます。
xz に対してオプション -T1 を指定していますが、これは強制的にシングルスレッドモードにするためです。並行処
理数の制御のために、既に xargs(1) が使用されているからです。
ロボットモード
複数ファイルを圧縮したことによって、合計で何バイト分が保存されたかを計算します:
xz --robot --list *.xz | awk '/^totals/{print $5-$4}'
スクリプト実行の際には、利用している xz が最新版であるかどうかを確認したい場合があります。以下の sh(1) ス
クリプトでは、xz ツールのバージョン番号が最低でも 5.0.0 であるかどうかを確認しています。この方法は
--robot オプションに対応していない古いベータ版に対しても利用できます:
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
XZ_OPT を利用して伸長時のメモリ利用制限を設定します。ただしすでに設定されていた場合、その設定が増えること
はありません:
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
カスタム圧縮フィルターチェーン
カスタムフィルターチェーンを利用する一番簡単な方法は LZMA2 プリセットを用いることです。プリセットには、圧
縮設定の中から有用な設定を組み合わせて、その一部を割り当てているため、それを使うのが簡単です。
オプション -0 ... -9, --extreme のところで説明した一覧表内の CompCPU カラムは、LZMA2 プリセット値をカスタ
マイズする際に活用できます。上で説明済の 2 つの表から、関連するところを抜粋したものが以下です:
プリセット CompCPU
-0 0
-1 1
-2 2
-3 3
-4 4
-5 5
-6 6
-5e 7
-6e 8
効率よく圧縮するためには、ある程度大きな (たとえば 32 MiB 程度の) 辞書が必要であることがわかっているとし
ます。一方で xz -8 の指定時よりも速く処理がしたいとします。その場合は CompCPU 値が低い (たとえば 1 である
ような) プリセットを使えば、より大きな辞書を利用するように調整ができます:
xz --lzma2=preset=1,dict=32MiB foo.tar
ファイルによっては、上のコマンドの実行により、圧縮効率が著しく改善されて xz -6 よりも高速処理される場合が
あります。ただし CompCPU 値を低くしたとしても、大きな辞書を使ったことが効果を発揮するようなファイルは限ら
れることは強調しておきます。大きな辞書を用いた効果が発揮される状況は、おそらく最低数メガバイトの総量
で、似通ったファイルを含むアーカイブである場合です。辞書サイズは、個々のファイルに比べれば十分に大きなサ
イズにする必要があります。そうしておけば、LZMA2 が並んだファイルの類似性に対して効果を発揮する処理を行っ
てくれます。
仮に圧縮時や伸長時のメモリ利用を大きな値とするのが有効であり、また圧縮するファイルが最低でも数 100 メガバ
イトあるなら、xz -9 が利用する辞書サイズ 64 MiB よりもさらに大きなサイズを利用するのが効果的かもしれませ
ん:
xz -vv --lzma2=dict=192MiB big_foo.tar
上の利用例に示しているように -vv (--verbose --verbose) を用いると、圧縮および伸長におけるメモリ必要量が確
認できます。なお伸長ファイルサイズよりも大きな辞書を利用すると、メモリを無駄に消費します。したがって上の
コマンドは、容量が少ないファイルに対しては効果が期待できません。
圧縮時間は問題にならないこともあります。しかし伸長時のメモリ利用量は低く抑えるべきです。たとえば埋め込み
システムでは、ファイル伸長時のメモリ利用は極力低く抑えたいところです。以下のコマンドでは、基本として -6e
(-6 --extreme) を利用し、辞書サイズは 64 KiB と小さくしています。XZ Embedded を利用すると (だからこそ
--check=crc32 を用いるのですが)、伸長処理によるファイル生成の際には 100 KiB のメモリ利用に抑えられます。
xz --check=crc32 --lzma2=preset=6e,dict=64KiB foo
できるだけ多くのバイトを圧縮したい場合は、リテラルコンテキスト (lc) ビット値と、ポジションビット (pb) を
調整するのが有効になる場合があります。リテラルポジションビット (lp) の調整も有効かもしれませんが、通常は
lc と pb の方が重要です。たとえばソースコードアーカイブと言えば、ほとんどが US-ASCII テキストであるた
め、以下に示すように処理すれば、xz -6e の処理よりもほんの少しだけ (0.1 % 程度) 小さくなります (lc=4 を除
いた処理も試してください):
xz --lzma2=preset=6e,pb=0,lc=4 source_code.tar
特定のファイルタイプに対しては、LZMA2 に別のフィルターを加えることで、圧縮処理が改善することがありま
す。たとえば x86-32 や x86-64 の共有ライブラリに対しては x86 BCJ フィルターを使うことがこれにあたります:
xz --x86 --lzma2 libfoo.so
フィルターオプションの並びは重要です。--x86 が --lzma2 の後ろに指定されると xz はエラーを表示します。この
理由は LZMA2 の後ろにフィルターを置くことはできないためであり、さらに x86 BCJ フィルターはチェーン内の最
終フィルターにすることもできないからです。
LZMA2 にデルタフィルターを合わせて利用すると、ビットマップイメージに対しては良好な結果が得られます。この
結果は通常、PNG を上回るはずです。PNG には単純なデルタよりも高度なフィルターがいくつかありますが、実際の
圧縮にあたっては Deflate が用いられています。
イメージデータは非圧縮形式で保存する必要があります。たとえば非圧縮の TIFF データなどです。デルタフィル
ターの距離パラメーターは、イメージ内におけるピクセルあたりのバイト数にマッチするように設定されていま
す。たとえば 24 ビット RGB ビットマップには dist=3 が必要です。また LZMA2 に対しては pb=0 を指定して 3 バ
イト並びに対応させるのが適切です:
xz --delta=dist=3 --lzma2=pb=0 foo.tiff
複数のイメージが 1 つのアーカイブ (たとえば .tar) にまとめられているときは、個々のイメージのピクセルあた
りのバイト数が同一である場合に限って、デルタフィルターは同様に動作します。
関連項目
xzdec(1), xzdiff(1), xzgrep(1), xzless(1), xzmore(1), gzip(1), bzip2(1), 7z(1)
XZ Utils: <https://tukaani.org/xz/>
埋め込み XZ: <https://tukaani.org/xz/embedded.html>
LZMA SDK: <http://7-zip.org/sdk.html>
Tukaani 2020-02-01 XZ(1)