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>