foo 파일을 기본 압축 수준 (-6) 으로 foo.xz 파일에 압축해 넣고, 압축 과정이 무사히 끝나면 foo를 삭제합니다:
bar.xz를 bar 에 압축을 해제한 후 압축 해제가 무사히 끝나도 bar.xz를 삭제하지 않습니다:
기본 사전 설정 -6 보다는 느리지만, 압축 및 압축 해제시 메모리를 적게 차지(각각 48 Mib, 5B)는 -4e 사전 설정(-4 --extreme)을 활용하여 baz.tar.xz 파일을 만듭니다:
tar cf - baz | xz -4e > baz.tar.xz
압축 및 비압축 파일을 단일 명령으로 표준 출력에 압축해제할 수 있습니다:
xz -dcf a.txt b.txt.xz c.txt d.txt.lzma > abcd.txt
여러 파일을 압축한 후 저장할 바이트 용량을 계산합니다:
xz --robot --list *.xz | awk '/^totals/{print $5-$4}' 이 스크립트에서는 충분히 최신의 xz 명령을 사용하는지 알아보려 합니다. 다음 sh(1)EN 스크립트에서는 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 옵션의 설명에서 테이블의 CompCPU 컬럼과 --extreme 옵션은 LZMA2 사전 설정을 개별적으로 맞췄을 때 쓸만할 수도 있습니다. 여기 관련내용을 테이블 둘로 정리해서 모아보았습니다.
| Preset | CompCPU |
| -0 | 0 |
| -1 | 1 |
| -2 | 2 |
| -3 | 3 |
| -4 | 4 |
| -5 | 5 |
| -6 | 6 |
| -5e | 7 |
| -6e | 8 |
어떤 파일을 압축할 때 상당히 큰 딕셔너리(예: 32MiB)가 필요 하다는걸 알아채셨지만, xz -8 명령이 압축할 때보다 더 빠른 속도로 압축하려 한다면, 더 큰 딕셔너리 사용을 위해 더 낮은 CompCPU 사전 설정 값(예: 1)으로 수정할 수 있습니다:
xz --lzma2=preset=1,dict=32MiB foo.tar
각 파일에 대해, 위 명령은 압축율이 더 좋아지면서도 xz -6보다 더 빨라집니다. 그러나, CompCPU 값을 낮게 유지하는 대신 큰 딕셔너리에서 일부 파일을 강조해야 합니다. 큰 딕셔너리가 대부분의 도움을 주는 매우 명백한 상황에서는 최소한 몇 메가바이트의 매우 유사한 각 파일이 아카이브에 들어갑니다. 딕셔너리 크기는 LZMA2가 연속으로 존재하는 각 파일의 유사성으로부터 얻는 장점을 취할 수 있을 때 일부 개별 파일보다 훨씬 더 커집니다.
압축 프로그램과 압축 해제 프로그램에서 메모리를 엄청 많이 사용해도 상관 없고, 파일을 수백 메가 바이트 메모리 용량을 활용하여 압축한다면, xz -9 명령에 64MiB 용량을 초과하는 딕셔너리를 사용할 수 있게 하는 방법도 쓸만할 지도 모릅니다:
xz -vv --lzma2=dict=192MiB big_foo.tar
위 예제에서와 같이 -vv (--verbose --verbose) 옵션을 사용하면 압축 및 압축 해제 과정에서 필요한 메모리 용량을 살펴보는데 요긴할 수 있습니다. 압축 해제한 파일 크기보다 더 큰 딕셔너리를 사용하면 불필요한 메모리 소모량이 발생하여 위 명령이 작은 파일에는 쓸모 없음을 기억하십시오.
때로는 압축 시간이 딱히 상관이 없을 수도 있습니다만, 압축 해제시 메모리 사용량을 적게 유지해야 할 수도 있습니다. 예를 들면, 임베디드 시스템에서 파일 압축을 해제할 수도 있습니다. 다음 명령의 경우 -6e (-6 --extreme) 옵션을 기반 옵션을 사용하며 딕셔너리 크기를 64KiB만 사용하도록 제한합니다. 결과 파일은 XZ 임베디드(이게 --check=crc32 옵션이 있는 이유)로 100KiB 메모리 용량을 활용하여 풀어낼 수 있습니다.
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을 --lzma 이전에 지정하면 xz에서 오류가 나는데, LZMA2 다음에는 어떤 필터든 설정할 수 없고, 옵션 체인상 마지막 필터로 x86 BCJ 필터를 사용할 수 없기 때문입니다.
LZMA2와 델타 필터는 비트맵 그림에 최적의 결과를 가져다줄 수 있습니다. PNG에 보통 안성맞춥인데, PNG에는 단순 델타 필터보단 약간 더 고급진 필터를 사용하지만, 실제 압축을 진행할 때는 Deflate를 사용하기 때문입니다.
예를 들어 이미지를 압축하지 않은 비압축 TIFF로 저장해야 하는 경우가 있습니다. 델타 필터의 거리 매개변수는 그림에서 픽셀당 바이트 수에 일치하도록 설정합니다. 예를 들면, 24비트 RGB 비트맵의 경우 dist=3 거리 매개변수 값을 설정해야 하며, LZMA2 압축시 3바이트 정렬을 따르도록 pb=0 값을 전달하는 방법도 바람직합니다.
xz --delta=dist=3 --lzma2=pb=0 foo.tiff
여러 이미지를 단일 아카이브로 넣고 싶다면(예: .tar), 모든 이미지에 대해 동일한 픽셀당 바이트 수가 들어가는 경우에도 델타 필터가 동작합니다.