XZ(1)

NAMN
xz, unxz, xzcat, lzma, unlzma, lzcat — Komprimera eller dekomprimera .xz- och .lzma-filer

SYNOPSIS
xz [flagga…] [fil…]

KOMMANDOALIAS
unxz är ekvivalent med xz --decompress.
xzcat är ekvivalent med xz --decompress --stdout.
lzma är ekvivalent med xz --format=lzma.
unlzma är ekvivalent med xz --format=lzma --decompress.
lzcat är ekvivalent med xz --format=lzma --decompress --stdout.

När man skriver skript som behöver dekomprimera filer rekommenderas det att altid använda namnet xz mäd lämpliga argument (xz -d eller xz -dc) istället för namnen unxz och xzcat.

BESKRIVNING
xz är ett datakomprimeringsverktyg för allmänt bruk med en kommandoradssyntax som liknar gzip(1) och bzip2(1). Det egna filformatet är formatet .xz, men det föråldrade formatet .lzma som anändes av LZMA-verktyg och råa komprimerade strömmar utan huvuden för behållarformatet stödjs också. Dessutom stödjs dekomprimering av formatet .lz som används av lzip.

xz komprimerar och dekomprimerar varje fil i enlighet med det valda arbetsläget. Om inga filer anges eller fil är - läser xz från standard in och skriver den behandade datan på standard ut. xz kommer vägra (visa ett felmeddelande och hoppa över filen) att skriva komprimerad data direkt till standard ut om det är en terminal. På samma sätt kommer xz vägra att läsa komprimerade data från standard in om det är en terminal.

Om inte --stdout anges skrivs andra filer än - till en ny fil vars namn härleds från källfilens namn:

•   Vid kompringering läggs suffixet till på målfilsformatet (.xz eller .lzma) på slutet av källfilnamnet för att få målfilnamnet.

•   Vid dekomprimering tas suffixet .xz, .lzma eller .lz bort från filnamnet för att få målfilnamnet. xz känner även igen suffixen .txz och .tlz, och ersätter dem med suffixet .tar.

Om målfilen redan finns visas ett felmeddelande och filen hoppas över.

Utom när den skriver till standard ut kommer xz visa en varning och hoppa över filen om något av följande inträffar:

•   Fil är inte en vanlig fil. Symboliska länkar följs inte, och därför anses de inte vara vanliga filer.

•   Fil har mer än en hård länk.

•   Fil har biten setuid, setgid eller sticky satt.

•   Arbetsläget är satt till att komprimera och filen har redan ett suffix enligt målfilformatet (.xz eller .txz vid komprimering till formatet .xz, och .lzma eller .tlz vid komprimering till formatet .lzma).

•   Arbetsläget är satt till att dekomprimera och filen har inte ett suffix enligt något av de stödda filformaten (.xz, .txz, .lzma, .tlz eller .lz).

Efter att ha kunnat komprimera eller dekomprimera filen kopierar xz ägaren, gruppen, rättigheterna, åtkomsttiden och ändringstiden från källfilen till målfilen. Om kopieringen av grupp misslyckas ändras rättigheterna så att målfilen inte blir åtkomlig för användare som inte har rättigheter att komma åt källfilen. xz stödjer inte kopiering av annan metadata såsom åtkomststyrhingslistor eller utökade attribut ännu.

När målfilen har stängts framgångsrikt tas källfilen bort såvida inte --keep angavs. Källfilen tas aldrig bort om utdata skrevs till standard ut eller om något fel inträffade.

Att skicka SIGINFO eller SIGUSR1 till xz-processen får den att skriva ut förloppsinformation till standard fel. Detta är bara av begränsat värde eftersom när standard fel går till en terminal så kommer användning av --verbose att skriva ut en automatiskt uppdaterande förloppsindikator.

  Minnesanvändning
xz:s minnesanvändning varierar från några få hundra kilobyte till flera gigabyte beroende på komprimeringsinställningarna. Inställningen som användes när en fil komprimerades avgör minnesbehovet hos dekomprimeraren. Typiskt behöver dekomprimeraren 5 % till 20 % av minnesbehovet som komprimeraren behöver när en fil skapas. Till exempel, att dekomprimera en fil skapad med xz -9 kräver för närvarande 65 MiB minne. Ändå är det möjligt att ha .xz-filer som behöver flera gigabyte minne för att dekomprimeras.

Särskilt användare av äldre system kan finna möjligheten av väldigt stor minnesanvändning störande. För att förhindra obehagliga överraskningar har xz en inbyggd minnesanvändningsbegränsare, vilken är avaktiverad som standard. Även om vissa operativsystem kan tillhandahålla möjligheter att begränsa minnesanvändningen hos processer bedömdes det inte som flexibelt nog att lita på det (till exempel, att använda ulimit(1) för att begränsa det virtuella minnet tenderar att hämma mmap(2).

Minnesanvändningsbegränsaren kan aktiveras med kommandoradsflaggan --memlimit=gräns. Ofta är det bekvämare att aktivera begränsaren som standard genom att sätta miljövariabeln XZ_DEFAULTS, till exempel, XZ_DEFAULTS=--memlimit=150MiB. Det är möjligt att sätta gränser separat för komprimering och dekomprimering genom att använda --memlimit-compress=limit och --memlimit-decompress=limit. Att använda dessa två flaggor utanför XZ_DEFAULTS är sällan meningsfullt eftersom en enskild körning av xz inte kan göra både komprimering och dekomprimering och and --memlimit=gräns (eller -M gräns) är kortare att skriva på kommandoraden.

Om den angivna minnesanvändningsgränsen överskrid vid dekomprimering kommer xz visa ett fel och dekomprimeringen av filen misslyckas. Om gröensen överskrids vid komprimering kommer xz försöka skala ner inställningen så att gränsen inte längre överskrids (utom när --format=raw eller --no-adjust används). På detta sätt kommer åtgärden inte misslyckas om inte gränsen är väldigt liten. Skalningen av inställningen görs i steg som inte matchar de förinställda komprimeringsnivåerna, till exempel, om gränsen endast är något mindre än den mängd som behövs till xz -9 kommer inställningen bara skalas ner lite, inte hela vägen ner till xz -8.

  Konkatenering och utfyllnad av .xz-filer
Det är möjligt att konkatenera .xz-filer som de är. xz kommer dekomprimera sådana filer som om de vore en enda .xz-fil.

Det är möjligt att infoga utfyllnad mellan de konkatenerade delarna eller efter den sista delen. Utfyllnaden måste bestå av null-bytear och storleken på utfyllnaden måste vara en multipel av fyra byte. Detta kan vara användbart, till exempel, om .xz-filen lagras på ett medium som mäter filstorlekar i 512-byteblock.

Konkaternering och utfyllnad är inte tillåtet med .lzma-filer eller råa strömmar.

FLAGGOR

  Heltalssuffix och speciella värden
På de flesta platser där ett heltalsargument förväntas stödjs ett frivilligt suffix för att enkelt indikera stora heltal. Det får inte finnas något mellanrumm mellan heltalet och suffixet.

KiB Multiplicera heltalet med 1 024 (2¹⁰). Ki, k, kB, K och KB är tillåtna som synomymer till KiB.

MiB Multiplicera heltalet med 1 048 576 (2²⁰). Mi, m, M och MB är tillåtna som synomymer till MiB.

GiB Multiplicera heltalet med 1 073 741 824 (2³⁰). Gi, g, G och GB är tillåtna som synonymer till GiB.

Specialvärdet max kan användas för att indikera det maximala heltalet som stödjs av flaggan.

  Arbetsläge
Om flera arbetslägesflaggor ges gäller den sista.

-z, --compress
    Komprimera. Detta är standardarbetsläget när ingen arbetslägesflagga anges och inget annat arbetsläge impliceras från kommandonamnet (till exempel implicerar unxz --decompress).

    Efter lyckad komprimering källfilen bort såvida man inte skriver till standard ut eller --keep angavs.

-d, --decompress, --uncompress
    Dekomprimera. Efter lyckad dekomprimering tas källfilen bort såvida man inte skriver till standard ut eller --keep angavs.

-t, --test
    Testa integriteten hos komprimerade filer. Denna flagga är ekvivalent med --decompress --stdout förutom att den dekomprimerade datan slängs istället för att skrivas på standard ut. Inga filer skapas eller tas bort.

-l, --list
    Skriv information om komprimerade filer. Inge dekomprimeringsutdata skapas, och inga filer skapas eller tas bort. I listläge kan programmet inte läsa komprimerad data från standard in eller från andra källor där man inte kan söka.

    Standardlistningen visar grundläggande information om filer, en fil per rad. För att få mer detaljerad information, använd även flaggan --verbose. För ännu mer information, använd --verbose två gånger, men observera att detta kan vara långsamt, eftersom det behövs många sökningar får att samla all den extra informationen. Bredden av utförlig utdata överskrider 80 tecken, så att skicka utdata i ett rör till, till exempel, less -S kan vara bekvämt om terminalen inte är bred nog.

    Den exakta utdatan kan variera mellan versioner av xz och olika lokaler. För maskinläsbar utdata bör --robot --list användas.

  Arbetsmodifierare

-k, --keep
    Ta inte bort indatafilerna.

    Från xz 5.2.6 gör denna flagga även att xz komprimerar eller dekomprimerar även om indatan är en symbolisk länk till en normal fil, har mer än en hård länk eller har biten setuid, setgid eller sticky satt. Bitarna setuid, setgid och sticky kopieras inte till målfilen. I tidigare versioner gjordes detta bara med --force.

-f, --force
    Denna flagga har flera funktioner:

    •   Om målfilen redan finns, radera den före komprimering eller dekomprimering.

    •   Komprimera eller dekomprimera även om indatan är en symbolisk länk till en normal fil, har mer än en hård länk eller har biten setuid, setgid eller sticky satt. Bitarna setuid, setgid och sticky kopieras inte till målfilen.

    •   När den används med --decompress --stdout och xz inte känner igen typen på källfilen, kopiera källfilen som den är till standard ut. Detta gör att xzcat --force kan användas som cat(1) för filer som inte har komprimerats med xz. Observera att i framtiden kan xz komma att stödja nya komprimeringsfilformat, vilket kan få xz att dekomprimera fler typer av filer istället för att kopiera dem till standard ut. --format=format kan användas för att begränsa xz till att dekomprimera endast ett enda filformat.

-c, --stdout, --to-stdout
    Skriv den komprimerade eller dekomprimerade datan till standard ut istället för en fil. Detta implicerar --keep.

--single-stream
    Dekomprimera endast den första .xz-strömmen, och ignorera tys eventuella återstående indata som följer efter strömmen. Normalt får sådant avslutande skräp xz att visa ett fel.

    xz dekomprimerar aldrig mer än en ström från .lzma-filer eller råa strömmar, men denna flagga gör ändå att xz ignorerar den möjliga efterföljande datan efter .lzma-filen eller den råa strömmen.

    Denna flagga har ingen effekt om arbetsläget inte är --decompress eller --test.

    Sedan xz 5.7.1alpha, implicerar --single-stream --keep.

--no-sparse
    Avaktivera att glesa filer skapas. Som standard, om den dekomprimerar till en normal fil, försöker xz att göra filen gles om den dekomprimerade datan innehåller långa sekvenser av binära nollor. Det fungerar även när den skriver till standard ut så länga standard ut är kopplad till en normal fil och vissa ytterligare villkor möts för att göra det säkert. Att skapa glesa filer kan spara diskutrymme och snabba upp dekomprimeringen genom att begränsa mängden disk-I/O.

-S .suf, --suffix=.suf
    Vid komprimering, använd .suf som suffixet för målfilen istället för .xz eller .lzma. Om den inte skriver till standard ut och källfilen redan har suffixet .suf visas en varning och filen hoppas över.

    Vid dekomprimering, känn igen filer med suffixet .suf utöver filer medsuffixen .xz, .txz, .lzma, .tlz eller .lz. Om källfilen har suffixet .suf tas suffixet bort för att få målfilnamnet.

    Vid komprimering eller dekomprimering av råa strömmar (--format=raw) måste alltid suffixet anges om den inte skriver till standard ut, eftersom det inte finns något standardsuffix för råa strömmar.

--files[=fil]
    Läs filnamnen att arbeta på från fil; om fil utelämnas läses filnamn från standard in. Filnamn måste avslutas med nyradstecknet. Ett bindestreck (-) tas som ett vanligt filnamn; det betyder inte standard in. Om filnamn även anges som kommandoradsargument, bearbetas de före filnamnen som läses från fil.

--files0[=fil]
    Detta är identiskt med --files[=fil] förjutom att varje filnamn måste avslutas med ett nulltecken.

  Grundläggande flaggor för filformat och komprimering

-F format, --format=format
    Angi filens format att komprimera eller dekomprimera:

    auto
        Detta är standard. Vid komprimering är auto ekvivalent med xz. Vid dekomprimering detekteras automatiskt formatet på indatafilen. Observera att råa strömmar (skapade med --format=raw inte kan detekteras automatiskt.

    xz  Komprimera till filformatet .xz, eller acceptera endast .xz-filer vid dekomprimering.

    lzma, alone
        Komprimera till det föråldrade filformatet .lzma, eller acceptera endast .lzma-filer fid dekomprimering. Det alternativa namnet alone tillhandahålls för bakåtkompatibilitet med LZMA Utils.

    lzip
        Acceptera endast .lz-filer vid dekomprimering. Komprimering stödjs inte.

        .lz-formatet version 0 och 1 stödjs. Version 0-filer producerades av lzip 1.3 och tidigare. Sådana filer är inte vanliga men kan hittas från filarkiv eftersom några källpaket släpptes i detta format. Folk kan ha även ha gamla personliga filer i detta format. Dekomprimeringsstöd för format version 0 togs bort i lzip 1.18. lzip 1.4 och senare kan skapa filer i formatversion 1.

    raw Komprimera eller dekomprimera en rå ström (inga huvuden). Detta är endast avsett för avancerade användare. För att avkoda råa strömmar behöver man använda --format=raw och explicit angi filterkedjan, vilken normalt skulle ha lagrats i behållarens huvuden.

-C kontroll, --check=kontroll
    Ange typen av integritetskontroll. Kontrollen beräknas från den dekomprimerade datan och lagras i .xz-filen. Denna flagga har endast någon inverkan när man komprimerar till formatet .xz; formatet .lzma stödjer inte integritetskontroller. Integritetskontrollen (om någon) verifieras när .xz-filen dekomprimeras.

    Kontrolltyper som stödjs:

    none
        Beräkna inte någon integritetskontroll alls. Detta är normalt en dålig idé. Det kan vara användbart när datans integritet ändå verifieras på andra sätt.

    crc32
        Beräkna CRC32 med polynomet från IEEE-802.3 (Ethernet).

    crc64
        Beräkna CRC64 med polynomet från ECMA-182. Detta är standard, eftersom det är något bättre än CRC32 på att upptäcka skadade filer och hastighetsskillnaden är försumbar.

    sha256
        Beräkna SHA-256. Detta är något långsammare än CRC32 och CRC64.

    Integriteten hos .xz-huvuden verifieras alltid med CRC32. Det är inte möjligt att ändra eller avaktivera det.

--ignore-check
    Verifiera inte integritetskontrollen av den komprimerade datan vid dekomprimering. CRC32-värden i .xz-huvudena kommer fortfarande verifieras normalt

    Använd inte denna flagga om du inte vet vad du gör. Möjliga anledningar till att använda denna flagga:

    •   Försöka återvinna data från en trasig .xz-fil.

    •   Snabba upp dekomprimering. Detta har störst betydelse med SHA-256 eller med filer som har komprimerats extremt mycket. Det rekommenderas att inte använda denna flagga för detta ändamål om inte filintegriteten verifieras externt på något annat sätt.

-0 … -9
    Välj en förinställningsnivå för komprimering. Standard är -6. Om flera förinställningsnivåer anges gäller den sist angivna. Om en anpassad fileterkedja redan angivits gör en inställning av en förinställningsnivå för komprimering att den anpassade filterkedjan töms.

    Skillnaden mellan förinställningarna har större betydelse än med gzip(1) och bzip2(1). Den valda komprimeringsinställningen avgör minneskraven för dekomprimeraren, att använda en för hög förinställningsnivå kan alltså göra det plågsamt att dekomprimera filer på ett gammalt system med lite RAM. Specifikt är det inte en bra ide att blint använda -9 för allt liksom det ofta är med gzip(1) och bzip2(1).

    -0 … -3
        Dessa är ganska snabba förinställningar. -0 är ibland snabbare än gzip -9 samtidigt som komprimeringen är mycket bättre. De högre har ofta hastighet jämförbar med bzip2(1) med jämförbar eller bättre komprimeringsförhållande, även om resultatet mycket beror på typen av data som komprimeras.

    -4 … -6
        Bra för väldigt god komprimering samtidigt som dekomprimerarens minnesanvändning hålls rimlig även på gamla system. -6 är standardvärdet, vilket vanligen är ett bra val för att distribuera filer so behöver dekomprimeras även på ssytem med endast 16 MiB RAM. (-5e eller -6e kan också vara värda att överväga. Se --extreme.)

    -7 … -9
        Dessa liknar -6 med med högre krav på minne till komprimerare och dekomprimerare. Dessa är bara användbara vid komprimering av filer större än 8 MiB, 16 MiB respektive 32 MiB.

    På samma hårdvara är dekomprimeringshastigheten ungefär ett konstant antal byt av komprimerad data per sekund. Med andra ord, ju bättre komprimering, desto snabbare kommer dekomprimeringen vanligen vara. Detta betyder även att mängden av okomprimerad utdata skapad per sekund kan variera mycket.

    Följande tabell sammanfattar funktionerna hos förinställningarna:

        Förinställning | LexStrl | KompCPU | KompMin | DekMin
        -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

    Kolumnbeskrivningar:

    •   LexStrl är storleken på LZMA2:s lexikon. Det är slöseri med minne att använda ett större lexikon än storleken på den okomprimerade filen. Detta är anledningen till att det är bra att undvika förinställningarna -7 … -9 när det inte finns något verkligt behov av dem. På -6 och lägre är mängden bortslösat minne vanligen litet nog att inte ha någon betydelse.

    •   KompCPU är en förenklad representation av LZMA2-inställningar som påverkar komprimeringshastigheten. Lexikonstorleken påverkar också hastigheten, så medan KompCPU är samma för nivåerna -6 … -9 tenderar fortfarande högre nivåer att vara lite långsmmare. För ännu långsammare och möjligen bättre komprimering, se --extreme.

    •   KompMem innehåller komprimerarens minneskrav i enkeltrådat läge. Det kan variera något mellan versioner av xz.

    •   DekMin innehåller dekomprimerarens minneskrav. Det vill säga, komprimerarens inställningar avgör minneskravet för dekomprimeraren. Den exakta minnesanvändningen hos dekomprimeraren är något mer än LZMA2-lexikonstorleken, men värdena i tabellen har avrundats upp till nästa nästa hela MiB.

    Minneskravet för det multitrådade läget är signifikant högre än det för enkeltrådat läge. Med standardvärdet på --block-size behöver varje tråd 3·3·LexStrl plus KompMin eller DekMin. Till exempel, fyra trådar med förinställningen behöver 660–670 MiB minne.

-e, --extreme
    Använd en långsammare variant av den valda förinställningsnivån för komprimering (-0 … -9) för att förhoppningsvis få lite bättre komprimeringsförhållande, men med otur kan detta även göra det sämre. Dekomprimerarens minnesanvändning påverkas inte, men komprimerarens minnesanvändning ökar lite vid förinställningsnivåerna -0 … -3.

    Eftersom det finns två förinställningar med lexikonstorlekar 4 MiB och 8 MiB använder förinställningarna -3e och -5e något snabbare inställningar (lägre KompCPU) än -4e respektive -6e. På det sättet är inte två förinställningar identiska.

        Förinställning | LexStrl | KompCPU | KompMin | DekMin
        -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

    Till exempel finns det totalt fyra förinställningar som använder 8 MiB lexikon, vars ordning från den snabbaste till den långsammaste är -5, -6, -5e och -6e.

--fast
--best
    Dessa är något missledande alias för -0 respektive -9. Dessa finns endast för bakåtkompatibilitet med LZMA-verktyg. Undvik att använda dessa flaggor.

--block-size=storlek
    Vid komprimering till formatet .xz, dela indatai block med storlek bytes. Blocken komprimeras oberoende av varandra, vilket hjälper till vid multitrådning och gör begränsad random-access-dekomprimering möjlig. Denna flagga används typiskt för att åsidosätta blockstorleken i multitrådat läge, men denna flagga kan användas även i enkeltrådat läge.

    I multitrådat läge kommer ungefär tre gånger storlek byte att allokeras i varje tråd för buffring av indata och utdata. Standardvärdet på storlek är det större av tre gånger LZMA2-lexikonstorleken eller 1 MiB. Typiskt är ett bra värde 2–4 gånger storleken på LZMA2-lexikonet eller åtminstone 1 MiB. Att använda en storlek mindre än LZMA2-lexikonstorleken utgör slöseri med RAM eftersom LZMA2-lexikonbufferten då aldrig kommer användas helt. I multitrådat läge lagras storlekarna på plocken i blockhuvudena. Denna storleksinformation krävs för multitrådad dekomprimering.

    I singletrådat läge görs som standard ingen uppdelning i block. Att göra denna inställning påverark inte minnesanvändningen. Ingen storleksinformation lagras i blockhuvuden, därmed kommer filer som skapas i enkeltrådat läge inte att vara identiska med filer skapade i multitrådat läge. Avsaknaden av sotrleksinformation betyder också att xz inte kommer kunna dekomprimera filerna i multitrådat läge.

--block-list=poster
    Vid komprimering till formatet .xz, börja ett nytt block med en möjlig anpassad filterkedja efter de angivna intervallen med okomprimerade data.

    Posterna är en kommaseparerad lista. Varje post består av ett möjligt filterkedjenummer mellan 0 och 9 följt av ett kolon (:) och en obligatorisk storlek för okomprimerade data. Att utelämna en post (två på varandra följande komman) är en kortform för att använda storleken och filtren från föregående post.

    Om indatafiler är större än summan av storlekarna i poster repeteras den sista posten fram till slutet på filen. Ett speciellt värde 0 kan användas som den sista storleken för att indikera att resten av filen skall kodas som ett enda block.

    En alternativ filterkedja för varje block kan anges i kombinaton med flaggorna --filters1=filter … --filters9=filter. Dessa flaggor definierar filterkedjor med en identifierare mellan 1–9. Filterkedja 0 kan användas för att referera till standardfilterkedjan, vilket är samma sak som att inte ange någon filterkedja. Filterkedjeidentifierare kan användas före den okomprimerade sotrleken, följt av ett kolon (:). Till exempel, om man anger --block-list=1:2MiB,3:2MiB,2:4MiB,,2MiB,0:4MiB kommer block skapas med:

    •   Filterkedjan angiven av --filters1 och 2 MiB indata

    •   Filterkedjan angiven av --filters3 och 2 MiB indata

    •   Filterkedjan angiven av --filters2 och 4 MiB indata

    •   Filterkedjan angiven av --filters2 och 4 MiB indata

    •   Standardfilterkedjan och 2 MiB indata

    •   Standardfilterkedjan och 4 MiB indata för varje block till slutet av indata.

    Om man anger en storlek som överskrider kodarens blockstorlek (antingen standardvärdet i trådat läge eller värdet som anges med --block-size=storlek) kommer kodaren skapa ytterligare block med hänsyn taget till gränserna som anges i poster. Till exempel, om man anger --block-size=10MiB --block-list=5MiB,10MiB,8MiB,12MiB,24MiB och indatafilen är 80 MiB kommer man få 11 block: 5, 10, 8, 10, 2, 10, 10, 4, 10, 10 och 1 MiB.

    I multitrådat läge lagras storleken på blocken i blockhuvudena. Detta görs inte i enkeltrådat läge, så den kodade utdatan kommer inte vara identisk med den från det multitrådade läget.

--flush-timeout=tidsgräns
    Vid komprimering, om mer än tidsgräns millisekunder (ett positivt heltal) har gått sedan den föregånde tömningen och en läsning av mer indata skulle blockera töms all väntande indata från kodaren och görs tillgänglig i utdataströmmen. Detta kan vara användbart om xz används för att komprimera data som strömmas över ett nätverk. Små värden på tidsgräns gör data tillgänglig vid den mottagande änden med en liten fördröjning, men större värden på tidsgräns ger bättre komprimeringsförhållande.

    Denna funktion är avaktiverad som standard. Om denna flagga anges mer än en gång gäller den sista. Dett speciella värdet 0 på tidsgräns kan användas för att uttryckligen avaktivera denna funktion.

    Denna funktion är inte tillgänglig på icke-POSIX-system.

    Denna funktion är fortfarande experimentell. För närvarande är xz olämplig för dekomprimering av strömmen i realtid på grund av hur xz buffrar.

--no-sync
    Synkronisera inte målfilen och dess katalog med lagringsenheten före källfilen tas bort. Detta kan förbättra prestanda vid komprimering eller dekomprimering av många små filer. Dock, om systemet kraschar snart efter raderingen är det möjligt att målfilen inte skrevs till lagringsenheten men att raderingen gjordes det. I det fallet är varken originalkällfilen eller målfilen tillgänglig.

    Denna flagga har bara någon effekt när xz kommer att ta bort källfilen. I andra fall görs aldrig någon synkronisering.

    Synkroniseringen och --no-sync lades till i xz 5.7.1alpha.

--memlimit-compress=gräns
    Sätt en gräns på minnesanvändningen för komprimeringen. Om denna flaggan anges flera gånger gäller den sista.

    Om komprimeringsinställnigarna överskrider gränsen kommer xz försöka justera inställningarna neråt så att gränsen inte längre överskrids och visa en notis om att en automatisk justering gjorts. Justeringen görs i denna ordning: reducera antalet trådar, byta till enkeltrådat läge om även en tråd i multitrådat läge överskrider gränsen och slutligen reducera LZMA2-lexikonstorleken.

    Vid komprimering med --format=raw eller om --no-adjust har angetts kan endast antalet trådar reduceras eftersom det kan göras utan att påverka den komprimerade utdatan.

    Om gränsen inte kan uppfyllas ens med justeringarna som beskrivs ovan visas ett felmeddelande och xz kommer avsluta med slutstatus 1.

    Gränsen kan anges på flera sätt:

    •   Gränsen kan vara ett absolut värde i byte. Att använda ett heltalssuffix som MiB kan vara praktiskt. Exempel: --memlimit-compress=80MiB

    •   Gränsen kan anges som en procentsats av det totala fysiska minnet (RAM). Detta kan vara användbart särskilt när man sätter miljövariabeln XZ_DEFAULTS i ett skalinitieringsskript som delas mellan olika datorer. På det sättet är gränsen automatiskt större på system med mer minne. Exempel: --memlimit-compress=70%

    •   Gränsen kan återställas tillbaka till sitt standardvärde genom att sätta den till 0. Detta är för närvarande ekvivalent med att sätta gränsen till max (ingen gräns på minnesanvändning).

    För 32-bitars xz finns det ett specialfall: om gränsen skulle vara över 4020 MiB sätts gränsen till 4020 MiB. På MIPS32 används 2000 MiB istället. (Värdena 0 och max påverkas inte av detta. En liknande funktion finns inte för dekomprimering.) Detta kan hjälpa till när ett 32-bitarsprogram har tillgång till 4 GiB adressrymd (2 GiB på MIPS32) förhoppningsvis utan att göra någon skada i andra situationer.

    Se även avsnittet Minnesanvändning.

--memlimit-decompress=gräns
    Sätt en gräns för minnesanvnändningen vid dekomprimering. Detta påverkar även läget --list. Om åtgärden inte är möjlig utan att överskrida gränsen kommer xz visa ett felmeddelande och dekomprimeringen av filen kommer misslyckas. Se --memlimit-compress=gräns för möjliga sätt att ange gränsen.

--memlimit-mt-decompress=gräns
    Sätt en gräns för minnesanvändningen för multitrådad dekomprimering. Detta kan endast påverka antalet trådar; det kommer aldrig att få xz att vägra att dekomprimera en fil. Om gränsen är för låg för att tillåta någon multitrådning ignoreras gränsen och xz kommer gå vidare i enkeltrådat läge. Observera att om även --memlimit-decompress används kommer det alltid att gälla både enkeltrådat och multitrådat läge, och därmed kommer den gällande gränsen för multitrådning aldrig vara högre än gränsen som sätts med --memlimit-decompress.

    Till skillnad mot de andra flaggorna för gränser för minnesanvändning har --memlimit-mt-decompress=gräns en systemspecifik standardgräns. xz --info-memory kan användas för att se det aktuella värdet.

    Denna flagga och dess standardvärde finns för att utan någon gräns skulle den trådade dekomprimeraren kunna allokera en vansinnig mängd minne med några indatafiler. Om standardgränsen är för låg på ditt system, öka då gärna gränsen men sätt den aldrig till ett större värde än mängden användbart RAM eftersom att med passande indatafiler kommer xz försöka använda den mängden av minne även med ett lågt antal trådar. Att få slut på minne ller växling kommer inte förbättra dekomprimeringsprestandan.

    Se --memlimit-compress=gräns för möjliga sätt att ange gränsen. Att sätta gräns till 0 återställer gränsen till sdet systemspecifika standardvärdet.

-M gräns, --memlimit=gräns, --memory=gräns
    Detta är ekvivalent med att ange --memlimit-compress=gräns --memlimit-decompress=gräns --memlimit-mt-decompress=gräns.

--no-adjust
    Visa ett fel och avsluta om gränsen för minnesanvändning inte kan mötas utan att justera inställnigar som påverkar den komprimerade utdatan. Det vill säga, detta förhindrar att xz byter kodaren från multitrådat läge till enkeltrådat läge och från att den reducerar LZMA2-lexikonets storlek. Även när denna flagga används kan antalet trådar reduceras för att möta gränsen för minnesanvändning eftersom det inte kommer påverka den komprimerade utdatan.

    Automatisk justering är alltid avaktiverat när råa strömmar skapas (--format=raw).

-T trådar, --threads=trådar
    Ange antalet arbetstrådar som skall användas. Att sätta trådar till ett specialvärde 0 gör att xz använder så många trådar som processorerna på systemet stödjer. Det aktuella antalet trådar kan vara färre än trådar om indatafilen inte är stor nog för trådning med de givna inställningarna eller om användning av fler trådar skulle överkrida gränsen för minnesanvändning.

    De enkeltrådade och multitrådade komprimerarna producerar olika utdata. Den enkeltrådade komprimeraren kommer ge den minsta filstorleken men endast utdata från den multitrådade komprimeraren kan dekomprimeras med flera trådar. Att sätta trådar till 1 kommer använda enkeltrådat läge. Att sätta trådar till något annat värde, inklusive 0, kommer använda den multitrådade komprimeraren även om systemet endast stödjer en hårdvarutråd. (xz 5.2.x använde enkeltrådat läge i denna situation.)

    För att använda multitrådat läge med endast en tråd, sätt trådar till +1. Prefixet + har ingen påvrekan för andra värden än 1. En gräns för minnesanvändning kan fortfarande göra att xz byter till enkeltrådat läge såvida inte --no-adjust används. Stöd för prefixet + lades till i xz 5.4.0.

    Om ett automatiskt antal trådar har begärts och ingen gräns för minnesanvändning har angivits, då kommer en systemspecifik mjuk standardgräns användas för att möjligen begränsa antalet trådar. Det är en mjuk gräns i den meningen att den ignoreras om antalet trådar blir en, alltså kommer en mjuk gräns aldrig hindra xz från att komprimera eller dekomprimera. Denna mjuka standardgräns kommer inte göra att xz byter från multitrådat läge till enkeltrådat läge. De aktiva gränserna kan ses med xz --info-memory.

    För närvarande är den enda trådningsmetoden att dela indata i block och komprimera dem oberoende av varandra. Standardstorleken på block beror på komprimeringsnivån och kan åsidosättas med flaggan --block-size=storlek.

    Trådad dekomprimering fungerar bara på filer som innehåller flera block med storleksinformation i blockhuvuden. Alla tillräckligt stora filer komprimeras i multitrådat läge för att uppfylla detta villkor, men filer komprimerade i enkeltrådat läge gör det inte ens om --block-size=storlek har använts.

    Standardvärdet på trådar är 0. I xz 5.4.x och tidigare är standardvärdet 1.

  Anpassade komprimerarfilterkedjor
Med en anpassad filterkedja kan man specificera kompressionsinställningarna i detalj istället för att lita på inställningarna som hör till förinställningarna. När en anpassad filterkedja anges glöms förinställningsflaggor (-0 … -9 och --extreme) tidigare på kommandoraden. Om en förinställningsflagga anges efter en eller flera flaggor för anpassade filterkedjor gäller den nya förinställningen och de flaggor för anpassade filterkedjor som angivits tidigare glöms.

En filterkedja är jämförbar med att skapa rör på kommando. Vid komprimering skickas den okomprimerade indatan till det första filtret, vars utdata skickas till nästa filter (om något). Utdatan från det sista filtret blir skrivet till den komprimerade filen. Det maximala antalet filter i kedjan är fyra, men typiskt har en filterkedja bara ett ellet två filter.

Många filter har begränsningar på var de kan finnas i filterkedjan: några filter kan bara fungera som det sista filtret i kedjan, några bara om de inte är det sista filtret, och några fungerar i godtycklig position i kedjan. Beroende på filtret är denna begränsning antingen en egenskap hos filterdesignen eller finns för att förhindra säkerhetsproblem.

En anpassad filterkedja kan anges på två olika sätt. Med flaggorna --filters=filter och --filters1=filter … --filters9=filter kan man ange en hel filterkedja med en flagga genom att använda syntaxen för liblzma-filtersträngar. Alternativt kan en filterkedja anges genom att använda en eller flera individuella filterflaggor i den ordning de önskas i filterkedjan. Det vill säga, ordningen på de individuella filterflaggorna är signifikant! Vid avkodning av råa strömmar (--format=raw) måste filterkedjan anges i samma ordning som den specificerades vid komprimeringen. Eventuella individuella filter- eller förinstiällningsflaggor angivna före den fullständiga filterkedjeflaggan (--filters=filter) kommer glömmas. Individuella filter som anges efter den flaggan för en full kedja kommer återställa filterkedjan.

Både den fullständiga och de individuella filterflaggorna tar filterspecifika flaggor som en kommaseparerad lista. Extra komman flaggor ignoreras. Varje flagga har ett standardvärde, så ange dem du vill ändra.

För att se hela filterkedjan och flaggor, använd xz -vv (det vill säga, använd --verbose två gånger). Detta fungerar även för att se flaggorna för filterkedjor som används av förinställningar.

--filters=filter
    Ange den fullständiga filterkedan eller en förinställning en en enda flagga. Varje filter kan separeras med blanktecken eller två bindestreck (--). filter kan behöva citeras på skalets kommandorad så att det tolkas som en enda flagga. För att beteckna flaggor, använd : eller =. En förinställning kan föregås med ett - och följas av noll eller flera flaggor. Den enda flaggan som stödjs är e för att tillämpa samma flaggor som --extreme.

--filters1=filter … --filters9=filter
    Ange upp till nio ytterligare filterkedjor som kan användas med --block-list.

    Till exempel, vid komprimering av ett arkiv med körbara filer följt av textfiler skulle den körbara delen kunna använda en filterkedja med ett BCJ-filter och endast textdelen med LZMA2-filtret.

--filters-help
    Visa ett hjälpmeddelande som beskriver hur man anger förinställningar och anpassade filterkedjor i flaggorna --filters och --filters1=filter … --filters9=filter, och avsluta rent.

--lzma1[=flaggor]
--lzma2[=flaggor]
    Lägg till LZMA1- eller LZMA2-filter till filterkedjan. Dessa filter kan endast användas som det sista filtret i kedjan.

    LZMA1 är ett föråldrat filter, vilket stödjs nästan enbart på grund av det föråldrade filformatet .lzma, vilket bara stödjer LZMA1. LZMA2 är en uppdaterad version av LZMA1 för att lösa några praktiska problem med LZMA1. Formatet .xz använder LZMA2 och stödjer inte LZMA1 alls. Komprimeringshastigheten och förhållandena för LZMA1 är LZMA2 är praktiskt taget desamma.

    LZMA1 och LZMA2 delar samma uppättning flaggor:

    preset=förinställning
        Återställ alla LZMA1- eller LZMA2-flaggor till förinställning. Förinställning består av ett heltal, vilket kan följas av enskilda bokstäver som modifierar förinställningen. Heltalet kan vara från 0 till 9, motsvarande kommandoradsflaggorna -0 … -9. Den enda modifierare som stödjs för närvarande är e, vilket motsvarar --extreme. Om ingen preset anges tas standardvärden på LZMA1- eller LZMA2-flaggor från förinställningen 6.

    dict=storlek
        Ett lexikons (historiebufferts) storlek indikerar hur många byte med nyligen bearbetad okomprimerad data som hålls i minnet. Algoritmen försöker hitta återkommande bytesekvenser (matchningar) i den okomprimerade datan, och ersätta dem med referenser till datan som för närvarande finns i lexikonet. Ju större lexikon, desto högre är sannolikheten att hitta en matchning. Att öka lexikonets storlek förbättrar alltså vanligen komprimeringsförhållandet, men ett lexikon som är större än den okomprimerade filen är ett slöseri med minne.

        En typisk storlek på lexikon är från 64 KiB till 64 MiB. Minimum är 4 KiB. Det maximala för komprimering är för närvarande 1,5 GiB (1536 MiB). Dekomprimeraren stödjer redan lexikon upp till en byte mindre än 4 GiB, vilket är det maximala för strömformaten LZMA1 och LZMA2.

        Lexikonstorlek och matchhittaren (mf) avgör tillsammans minnesanvändningen för LZMA1- eller LZMA2-kodaren. Ett lika stort (eller större) lexikon behövs för dekomprimering som det som användes vid komprimeringen, minnesanvändningen för avkodaren avgörs alltså av lexikonstorleken vid komprimering. Huvudena i .xz innehåller lexikonets storlek antingen som 2^n eller 2^n + 2^(n-1), så dessa storlekar är lite att föredra för komprimering. Andra storlekar kommer avrundas uppåt när de lagras i huvuden i .xz.

    lc=lk
        Ange antalet literala kontextbitar. Minimum är 0 och maximum är 4; standardvärdet är 3. Dessutom får inte summan av lk och lp överskrida 4.

        Alla byte som inte kan kodas som matchningar kodas som literaler. Det vill säga, literaler är helt enkelt 8-bits byte som kodas en åt gången.

        Den literala kodningen gör antagandet att de högsta lk bitarna av den föregående okomprimerade byten korrelerar med nästa byte. Till exempel, i typisk engelsk text följs ofta en versal bokstav av en gemen bokstav, och en gemen bokstav följs vanligen av en annan gemen bokstav. I teckenuppsättningen US-ASCII är de högsta tre bitarna 010 för versala bokstäver och 011 för gemena bokstäver. När lk är åtminstone 3 kan den literala kodningen dra nytta av denna egenskap i den okomprimerade datan.

        Standardvärdet (3) är normalt bra. Om man vill ha maximal komprimering, prova lc=4. Ibland hjälper det lite, och ibland gör det komprimeringen sämre. Om det gör den sämre, testa också lc=2.

    lp=lp
        Ange antalet literala positionsbitar. Minimum är 0 och maximum är 4; standardvärdet är 0.

        Lp påverkar vilken sorts justering i den okomprimerade datan som antas vid kodning av literaler. Se pb nedan för mer information om justering.

    pb=pb
        Ange antalet positionsbitar. Minimum är 0 och maximum är 4; standardvärdet är 2.

        Pb påverkar vilken sort justering i den okomprimerade datan som antas i allmänhet. Standardvärdet betyder fyrbytejustering (2^pb=2^2=4), vilket ofta är ett bra val när det inte finns någon bättre gissning.

        När justeringen är känd kan en inställning av pb därefter reducera filstorleken något. Till exempel, med textfiler som har en-byte-justering (US-ASCII, ISO-8859-*, UTF-8) kan att sätta pb=0 förbättra komprimeringen något. För UTF-16-text är pb=1 ett bra val. Om justeringen är ett udda tal som 3 byte kan pb=0 vara det bästa valet.

        Även om den antagna justeringen kan anpassas med pb och lp föredrar LZMA1 och LZMA2 ändå något 16-byte-justering. Det kan vara värt att ta med i beräkningen vid design av filformat som sannolikt ofta kan komma att komprimeras med LZMA1 eller LZMA2.

    mf=ms
        Matchsökaren har en stor poverkan på kodarens hastighet, minnesanvändning och komprimeringsförhållande. Vanligen är Hashkedje-matchsökare snabbare än Binärträdsmatchsökare. Standardvärdet beror på föinställningen: 0 använder hc3, 1–3 använder hc4, och resten använder bt4.

        Följande matchsökare stödjs. Formlerna för minnesanvändning nedan är grova uppskattningar, vilka är närmast sanningen när dict är en tvåpotens.

        hc3 Hashkedja med 2- och 3-bytehashning
            Minsta värde på nice: 3
            Minnesanvändning:
            dict · 7.5 (om dict ≤ 16 MiB);
            dict · 5,5 + 64 MiB (om dict > 16 MiB)

        hc4 Hashkedja med 2-, 3- och 4-bytehashning
            Minsta värde på nice: 4
            Minnesanvändning:
            dict · 7,5 (om dict ≤ 32 MiB);
            dict · 6,5 (om dict > 32 MiB)

        bt2 Binärträd med 2-bytehashning
            Minsta värde på nice: 2
            Minnesanvändning: dict · 9,5

        bt3 Binärträd med 2- och 3-bytehashning
            Minsta värde på nice: 3
            Minnesanvändning:
            dict · 11,5 (om dict ≤ 16 MiB);
            dict · 9,5 + 64 MiB (om dict > 16 MiB)

        bt4 Binärträd med 2-, 3- och 4-bytehashning
            Minsta värde på nice: 4
            Minnesanvändning:
            dict · 11,5 (om dict ≤ 32 MiB);
            dict · 10,5 (om dict > 32 MiB)

    mode=läge
        Komprimeringsläget anger metoden som används för att analysera data skapade av matchsökaren. De lägen som stödjs är fast och normal. Standardvärdet är fast för förinställningarna 0–3 och normal för förinställningarna 4–9

        Vanligen används fast med Hashkedjematchsökare och normal med Binärträdsmatchsökare. Detta är även vad förinställningarna gör.

    nice=lagom
        Ange vad som anses vara en lagom längt på en matchning. När en matchning på åtminstone lagom byte hittats slutar algoritmen söka efter möjliga bättre matchningar.

        Lagom kan vara 2–273 byte. Högre värden tenderar att ge bättre komprimeringsförhållande på bekostnad av tid. Standardvärdet beror på förinställningen.

    depth=djup
        Ange det maximala sökdjupet i matchsökaren. Standardvärdet är specialvärdet 0, vilket får komprimeraren att avgöra ett lämpligt djup från mf och nice.

        Lämpligt djup för Hashkedjor är 4–100 och 16–1000 för Binärträd. Att använda väldigt höga värden på djup kan göra kodaren extremt långsam för vissa filer. Undvik att sätta djup över 1000 såvida du inte är beredd att avbryta komprimeringen om den tar för lång tid.

    Vid avkodning av råa strömmar (--format=raw) behöver LZMA2 endast lexikonets storlek. LZMA1 behöver även lc, lp och pb.

--x86[=flaggor]
--arm[=flaggor]
--armthumb[=flaggor]
--arm64[=flaggor]
--powerpc[=flaggor]
--ia64[=flaggor]
--sparc[=flaggor]
--riscv[=flaggor]
    Lägg till gren/anrop/hopp-filter (branch/call/jump, BCJ) till filterkedjan. Dessa filter kan inte användas som det sista filtret i filterkedjan.

    Ett BCJ-filter konverterar relativa adresser i maskinkod till deras absoluta motsvarigheter. Detta ändrar inte storleken på datan men det ökar redundansen, vilket kan hjälpa LZMA2 att skapa 0–15 % mindre .xz-filer. BCJ-filtren är alltid reversibla, så att använda ett BCJ-filter för fel sorts data orsakar inte någon dataförlust, men det kan göra komprimeringsförhållandet något sämre. BCJ-filtren är mycket snabba och använder en obetydling mängd minne.

    Dessa BCJ-filter har kända problem kopplade till komprimeringsförhållandet:

    •   Någr sortes filer som innehåller körbar kod (till exempel, objektfiler, statiska bibliotek och Linux kärnmoduler) har adresserna i instruktionerna fyllda med utfyllnadsvärden. Dessa BCJ-filter kommer ändå göra adresskonverteringen, vilket kommer göra komprimeringen sämre för dessa filer.

    •   Om ett BCJ-filter används på ett arkiv är det möjligt att det gör komprimeringsförhållandet sämre än att inte använda något BCJ-filter. Till exempel, om det finns liknande eller till och med identiska körbara kommer filtreringen sannolikt göra filerna mindre lika och därmed blir kompressionen sämre. Innehållet i icke körbara filer i samma arkiv kan också spela en roll. I praktiken måste man prova med och utan ett BCJ-filter för att se vilket som är det bästa i varje situation.

    Olika instruktionsuppsättningar har olika justering: den körbara filen måste vara justerad till en multipel av detta värde i indata för att filtret skall fungera.

        Filter | Justering | Kommentarer
        x86 | 1 | 32-bitars eller 64-bitars x86
        ARM | 4 |
        ARM-Thumb | 2 |
        ARM64 | 4 | 4096-bytesjustering är bäst
        PowerPC | 4 | Endast rak byteordning
        IA-64 | 16 | Itanium
        SPARC | 4 |
        RISC-V | 2 |

    Eftersom BCJ-filtrerad data vanligen komprimeras med LZMA2 kan komprimeringsförhållandet förbättras något om LZMA2-flaggorna sätts till att matcha justeringen hos det valda BCJ-filtret. Exempel:

    •   IA-64-filter har 16-bytejustering så pb=4,lp=4,lc=0 är bra med LZMA2 (2⁴=16).

    •   RISC-V-kod har 2-byte- eller 4-bytejustering beroende på huruvida filen innehåller 16-bitars komprimerade instruktioner (utvidgningen C). När 16-bitarsinstruktioner används är pb=2,lp=1,lc=3 eller pb=1,lp=1,lc=3 bra. När det inte finns några 16-bitsinstruktioner är pb=2,lp=2,lc=2 bäst. readelf -h kan användas för att kontrollera om ”RVC” förekommer på raden ”Flaggor”.

    •   ARM64 är alltid 4-bytejusterad så pb=2,lp=2,lc=2 är bäst.

    •   Filtret x86 är ett undantag. Det är normalt bra att hålla sig till LZMA2:s standardvärden (pb=2,lp=0,lc=3) när körbar x86 komprimeras.

    Alla BCJ-filter stödjer samma flaggor:

    start=avstånd
        Ange startavståndet som används vid konvertering mellan relativa och absoluta adresser. Avståndet måste vara en multipel av filtrets justering (se tabellen ovan). Standardvärdet är noll. I praktiken är standardvärdet bra; det är nästan aldrig användbart att ange ett anpassat avstånd.

--delta[=flaggor]
    Lägg till Deltafiltret till filterkedjan. Deltafiltret kan inte användas som det sista filtret i filterkedjan.

    För närvarande stödjs bara enkel byte-vis deltaberäkning. Det kan vara användbart vid komprimering, till exempel av okomprimerade bitavbildningsbilder eller okomprimerad PCM-audio. Dock kan algoritmer för särskilda ändamål ge betydligt bättre resultat än Delta + LZMA2. Detta är särskilt sant med audio, vilket komprimerar snabbare och bättre med till exempel flac(1).

    Stödda flaggor:

    dist=avstånd
        Ange avståndet för deltaberäkningen i byte. Avstånd måste varea 1–256. Standardvärdet är 1.

        Till exempel, med dist=2 och åtta byte indata A1 B1 A2 B3 A3 B5 A4 B7, kommer utdata vara A1 B1 01 02 01 02 01 02.

  Andra flaggor

-q, --quiet
    Utelämna varningar och noteringar. Ange detta två gånger för att även utelämna felmeddelandet. Denna flagga har ingen påverkan på slutstatusen. Det vill säga, även om en varning utelämnades kommer slutstatusen fortfarandeindikera att en varning gavs.

-v, --verbose
    Var utförlig. Om standard fel är kopplat till en terminal kommer xz visa en förloppsmätare. Att ange --verbose två gånger kommer ge än mer utförlig utmatning.

    Förloppsmätaren visar följande information:

    •   Procent färdigt visas om storleken på indatafilen är känd. Det vill säga, procentsatsen kan inte visas i rör.

    •   Mängd komprimerad data som producerats (komprimering) eller konsumerats (dekomprimering).

    •   Mängd okomprimerad data som konsumerats (komprimering) eller producerats (dekomprimering).

    •   Komprimeringsförhållande, vilket beräknas genom att dividera mängden komprimerad data bearbetad så lång med mängde okomprimerad data bearbetad så långt.

    •   Kompressions eller dekompressionshastighet. Detta mäts som mängden okomprimerad data konsumerad (komprimering) eller producerad (dekomprimering) per sekund. Det visas efter att några sekunder har gåt efter att xz började bearbeta filen.

    •   Förfluten tid på formatet MM:SS eller H:MM:SS.

    •   Beräknad återstående tid visas endast när storleken på indatafilen är känd och några sekunder redan gått efter att xz började bearbeta filen. Tiden visas i ett mindre precist format vilket aldrig har några kolon, till exempel, 2 min 30 s.

    När standard fel inte är en terminal kommer --verbose göra att xz skriver filnamnet, komprimerad storlek, okomprimerad storlek, komprimeringsförhållande och möjligen även hastigheten och den förlupna tiden på en enda rad till standard fel efter att ha komprimerat eller dekomprimerat filen. Hastigheten och den förlupna tiden inkluderas endast när åtgärden tog åtminstone några sekunder. Om åtgärden inte slutfördes, till exempel för att användaren avbröt, skrivs även den fullbordade procentsatsen om storleken på indatafilen är känd.

-Q, --no-warn
    Sätt inte slutstatus till 2 även om ett tillstånd som är värt en varning upptäcktes. Denna flagga påverkar inte utförlighetsnivån, allts måste både --quiet och --no-warn användas för att inte visa varningar och för att inte ändra slutstatusen.

--robot
    Skriv meddelanden i maskinläsbart form. Detta är avsett att förenkla att skriva framändar som vill använda xz istället för liblzma, vilken kan vara fallet i olika skript. Utdatan med denna flagga aktiverad är avsedd att vara stabil mellan utgåvor av xz. Se avsnitett ROBOTLÄGE för detaljer.

--info-memory
    Visa, på mänskligt läsbar form, hur mycket fysiskt minne (RAM) och hur många processortrådar xz tror att systemet har och gränserna för minnesanvändning vid komprimering och dekomprimering, och avsluta.

-h, --help
    Visa ett hjälpmeddelande som beskriver de vanligast använda flaggorna, och avsluta.

-H, --long-help
    Visa ett hjälpmeddelande som beskriver alla funktioner i xz, och avsluta

-V, --version
    Visa versionsnumret för xz och liblzma i mänskligt läsbar form. För att få maskinläsbar utdata, ange --robot före --version.

ROBOTLÄGE
Robotläget aktiveras med flaggan --robot. Det gör att utdata från xz är enklare att tolka av andra program. För närvarande stödjs --robot endast tillsammans med --list, --filters-help, --info-memory och --version. Den kommer att stödjas för komprimering och dekomprimering i framtiden.

  Listläge
xz --robot --list använder tab-separerad utmatning. Första kolumnen av varje rad har en sträng som indikerar typen av informationen som finns på den raden:

name
    Detta är alltid första raden när en fil börjar listas. Den andra kolumen på raden är filnamnet.

file
    Denna rad innehåller övergripande information om .xz-filen. Denna rad skrivs alltid efter raden name.

stream
    Denna radtyp används endast när --verbose angetts. Det finns lika många stream-rader som det finns strömmar i .xz-filen.

block
    Denna radtyp används bara när --verbose angetts. Det finns lika många block-rader som det finns block i .xz-filen. block-rader visas efter alla stream-raderna; olika radtyper blandas inte.

summary
    Denna radtyp används bara när --verbose angetts två gånger. Denna rad skrivs eefter alla block-rader. Liksom raden file inenhåller raden summary övergripande information om .xz-filen.

totals
    Denna rad är alltid den allra sista raden i listutmatningen. Den visar det totala antalen och storlekarna.

Kolumnerna på file-raderna:
    2.  Antalet strömmar i filen
    3.  Totalt antal block i strömmarna
    4.  Komprimerad storlek på filen
    5.  Okomprimerad storlek på filen
    6.  Komprimeringsförhållande, till exempel 0.123. Om förhållandet är över 9.999 visas tre bindestreck (---) istället för förhållandet.
    7.  Kommaseparerad lista med integritetskontrollnamn. Följande strängar används för de kända kontrolltyperna: None, CRC32, CRC64 och SHA-256. För okända kontrolltyper används Unknown-N, där N är kontroll-ID:t som ett decimalt nummer (en eller två siffror).
    8.  Total storlek på strömutfyllnad i filen

Kolumnerna på stream-raderna:
    2.  Strömnummer (den första strömmen är 1)
    3.  Antal block i strömmen
    4.  Komprimerat startavstånd
    5.  Okomprimerat startavstånd
    6.  Komprimerad storlek (inkluderar inte strömutfyllnad)
    7.  Okomprimerad storlek
    8.  Komprimeringsförhållande
    9.  Namnet på integritetskontrollen
    10. Storleken på strömutfyllnad

Kolumnerna på block-raderna:
    2.  Numret på strömmen som innehåller detta block
    3.  Blocknummer relativt början på strömmen (det första blocket är 1)
    4.  Blocknummer relativt början på filen
    5.  Komprimerat startavstånd relativt början av filen
    6.  Okomprimerat startavstånd relativt början av filen
    7.  Total komprimerad storlek på blocket (inkluderar huvuden)
    8.  Okomprimerad storlek
    9.  Komprimeringsförhållande
    10. Namnet på integritetskontrollen

Om --verbose angavs två gånger inkluderas ytterligare kolumner på block-raderna. Dessa visas inte med bara ett --verbose, eftersom det för att få fram denna information krävs många sökningar och kan därmed vara långsamt:
    11. Värdet på integritetskontrollen hexadecimalt
    12. Blockhuvudstorlek
    13. Blockflaggor: c indikerar att komprimerad storlek finns, och u indikerar att okomprimerad storlek finns. Om flaggan inte är satt visas ett bindestreck (-) istället för att hålla stränglängden fast. Nya flaggor kan läggas till i slutet av strängen i frmtiden.
    14. Storlek på den faktiska komprimerade datan i blocket (detta utelämnar blockhuvud, blockutfyllnad och kontrollfält)
    15. Mängd minne (i byte) som behövs för att dekomprimera detta block med denna version av xz
    16. Filterkedja. Observera att de flesta av flaggorna som användes vid komprimeringstillfället inte kan vara kända, eftersom endat de flaggor som behövs för dekomprimering lagras i .xz-huvudet.

Kolumnerna på summary-raderna:
    2.  Mängd minne (i byte) som behövs för att dekomprimera denna fil med denna version av xz
    3.  yes eller no som indikerar om alla blockhuvuden både har komprimerad storlek och okomprimerad storlek i sig
    Från xz 5.1.2alpha:
    4.  Minsta version av xz som krävs för att dekomprimera filen

Kolumnerna på totals-raden:
    2.  Antal strömmar
    3.  Antal block
    4.  Komprimerad storlek
    5.  Okomprimerad storlek
    6.  Genomsnittligt komprimeringsförhållande
    7.  Kommaseparerad lista med integritetskontrollnamn som fanns i filerna
    8.  Strömutfyllnadsstorlek
    9.  Antal filer. Denna finns här för att hålla ordningen av de tidigare kolumnerna desamma som på file-rader.

Om --verbose angavs två gånger inkluderas ytterligare kolumner på totals-raden:
    10. Maximal mängd minne (i byte) som behövs för att dekomprimera filerna med denna version av xz
    11. yes eller no som indikerar om alla blockhuvuden både har komprimerad storlek och okomprimerad storlek i sig
    Från xz 5.1.2alpha:
    12. Minsta version av xz som krävs för att dekomprimera filen

Framtida versioner kan lägga till fler radtyper och fler kolumner kan läggas til på de befintliga radtyperna, men de befintliga kolumnerna kommmer inte ändras.

  Filterhjälp
xz --robot --filters-help skriver ut de filter som stödjs i följande format:

filter:flagga=<värde>,flagga=<värde>…

filter
    Namn på filtret

flagga
    Namn på en filterspecifik flagga

värde
    Numeriska värdeintervall ser ut som <min-max>. Strängvärdes val visas inom < > och separerade med ett |-tecken.

Varje filter skrivs på en egen rad.

  Minnesgränsinformation
xz --robot --info-memory skriver en rad med flera tab-separerade kolumner:

1.  Total mängd med fysiskt minne (RAM) i byte.

2.  Minnesanvändningsgräns för komprimering i byte (--memlimit-compress). Ett specialvärde 0 indikerar standardinställningen vilken för enkeltrådat läge är detsamma som ingen gräns.

3.  Minnesanvändningsgräns för dekomprimering i byte (--memlimit-decompress). Ett specialvärde 0 indikerar standdartinställningen vilken för enkeltrådat läge är detsamma som ingen gräns.

4.  Från xz 5.3.4alpha: Minnesanvändningen för multitrådad dekomprimering i byte (--memlimit-mt-decompress). Detta är aldrig noll eftersom ett systemspecifikt standardvärde som visas i kolumn 5 används om ingen gräns har angivits uttryckligen. Detta är heller aldrig större än värdet i kolumn 3 även om ett större värde har angivits med --memlimit-mt-decompress.

5.  Från xz 5.3.4alpha: Ett systemspecifikt standardgräns för minnesanvändning som används för att begränsa antalet trådar vid komprimering med ett automatiskt antal trådar (--threads=0) och ingen gräns för minnesanvändning har angivits (--memlimit-compress). Detta används även som standardvärdet på --memlimit-mt-decompress.

6.  Från xz 5.3.4alpha: antal tillgängliga processortrådar.

I framtiden kan utdata från xz --robot --info-memory ha fler kolumner, men aldrig mer än en rad.

  Version
xz --robot --version skriver versionsnumret på xz och liblzma i följande format:

XZ_VERSION=XYYYZZZS
LIBLZMA_VERSION=XYYYZZZS

X   Huvudversion.

YYY Underversion. Jämna nummer är stabila. Udda nummer är alfa- eller betaversioner.

ZZZ Rättningsnivå för stabila utgåvor eller bara en räknare för utvecklingsutgåvor.

S   Stabilitet. 0 är alfa, 1 beta beta och 2 är stabil. S skall alltid vara 2 när YYY är jämnt.

XYYYZZZS är samma på båda raderna om xz och liblzma kommer från samma utgåva av XZ Utils.

Exempel: 4.999.9beta är 49990091 och 5.0.0 är 50000002.

SLUTSTATUS

0   Allt är bra.

1   Ett fel uppstod.

2   Något värt en varning uppstod, men inga faktiska fel uppstod.

Noteringar (inte varningar eller fel) som skrivs på standard fel påverkar inte slutstatusen.

MILJÖ
xz tolkar mellanrumsseparerade listor av flaggor från miljövariablerna XZ_DEFAULTS och XZ_OPT, i den ordningen, före flaggorna på kommandoraden. Observera att endast flaggor tolkas från miljövariablerna; alla andra argument än flaggor ignoreras tyst. Tolkningen görs med getopt_long(3) vilket även används för kommandoradsargumenten.

Varning: genom att sätta dessa miljövariabler ändrar man i praktiken program och skript som kör xz. för det mesta är set säkert att sätta begränsningar på minnesanvändning, antal trådar och komprimeringsflaggor via miljövariablerna. Några flaggor kan dock göra att skript går sönder. Ett uppenbart exempel är --help vilket gör att xz visar en hjälptext istället för att komprimera eller dekomprimera en fil. Mer subtila exempel är --quiet och --verbose. I många fall fungerar det bra att aktivera en förloppsindikator med --verbose, men i några fall skapar de extra meddelandena problem. Utförlighetsnivån påverkar även beteendet hos --list.

XZ_DEFAULTS
    Användarspecifika eller systemspecifika standardflaggor. Typiskt sätts detta i ett initieringsskript för skal för att aktivera xz:s begränsning av minnesanvändning som standard eller att ställa in ett standardantal trådar. Med undantag för skalinitieringsskript och liknande specialfall skall skript aldrig sätta eller ta bort XZ_DEFAULTS.

XZ_OPT
    Detta är för att skicka flaggor till xz när det inte är möjligt att sätta flaggorna direkt på kommandoraden för xz. Detta är fallet när xz körs av ett skript eller verktyg, till exempel, GNU tar(1):

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

    Skript kan använda XZ_OPT, till exempel, för att sätta skriptspecifika standardflaggor för komprimering. Det rekommenderas fortfarande att tillåta användaren att åsidosätta XZ_OPT om det är rimligt. Till exempel, i sh(1)-skript kan man använda något i still med detta:

        XZ_OPT=${XZ_OPT-"-7e"}
        export XZ_OPT

KOMPATIBILITET MED LZMA UTILS
Kommandoradssyntaxen för xz är praktiskt taget en utökning av lzma, unlzma och lzcat så som de kommer från LZMA Utils 4.32.x. I de flesta fall, är det möjligt att ersätta LZMA Utils med XZ Utils utan att göra sönder befintliga skript. Det finns dock några inkompatibiliteter, vilka ibland kan orsaka problem.

  Komprimeringens förinställda nivåer
Numreringen av förinställda nivåer för komprimering är inte identiska i xz och LZMA Utils. Den viktigaste skillnade är hur lexikonstorlekar avbildas till olika förinställningar. Lexikonstorleken är i stort sett lika med dekomprimerarens minnesanvändning.

    Nivå | xz | LZMA Utils
    -0 | 256 KiB | N/A
    -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

Lexikonstorlekens skillnader påverkar komprimerarens minnesanvändning också, men det finns några andra skillnader mellan LZMA Utils och XZ Utils, vilket gör skillnaden ännu större:

    Nivå | xz | LZMA Utils 4.32.x
    -0 | 3 MiB | N/A
    -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

Standardförinställningsninvån i LZMA Utils är -7 medan i XZ Utils är den -6, så båda använder ett 8 MiB lexikon som standard.

  Strömmade visavi icke strömmade .lzma-filer
Den ikomprimerade storleken på filen kan lagras i huvudet i .lzma. LZMA Utils gör det när den komprimerar normala filer. Alternativet är att markera att den okomprimerade storleken är okänd och använda en markör för lastslut för att indikera var dekomprimeraren skall stanna. LZMA Utils använder denna metod när den okomprimerade storleken inte är känd, vilket är fallet, till exempel, i rör.

xz stödjer dekomprimering av .lzma-filer med eller utan markör för lastslut, men alla .lzma filer som skapas av xz kommer använda markör för lastslut och ha den okomprimerade storleken markerad som okänd i .lzma-huvudet. Detta kan bli ett problem i några ovanliga fall. Till exempel kan en .lzma-dekomprimerare i en inbäddad enhet fungera endast med filer som har en känd okomprimerad storlek. Om man stöter på detta problem behöver man använda LZMA Utils eller LZMA SDK för att skapa .lzma-filer med känd okomprimerad storlek.

  Ej stödda .lzma-filer
Formatet .lzma tillåter värden på lc upp till 8, och värden på lp upp till 4. LZMA Utils kan dekomprimera filer med godtyckliga lc och lp, men skapar alltid filer med lc=3 och lp=0. Att skapa filer med andra lc och lp är möjligt med xz och med LZMA SDK.

Implementationen av LZMA1-filtret i liblzma kräver att summan av lc och lp inte överstiger 4. Alltså, .lzma-filer, vilka överstiger denna gräns, kan inte dekomprimeras med xz.

LZMA Utils skapar endast .lzma-filer som har en lexikonstorlek på 2^n (en potens av 2) men godtar filer med godtycklig lexikonstorlek. liblzma godtar endast .lzma-filer som har en lexikonstorlek på 2^n eller 2^n + 2^(n-1). Detta är för att minska falska positiva vid detektering av .lzma-filer.

Dessa begränsningar bör inte vara ett problem i praktiken, eftersom praktiskt taget alla .lzma-filer har komprimerats med inställningar som liblzma kommer godta.

  Avslutande skräp
Vid dekomprimering ignorerar LZMA Utils tyst allting efter den första .lzma-strömmen. I de flesta situationer är detta fel. Detta betyder även att LZMA Utils inte stödjer dekomprimering av konkatenerade .lzma-filer.

Om det finns data kvar efter den första .lzma-strömmen betraktar xz filen som trasig om inte --single-stream användes. Detta kan göra sönder obskyra skript vilka har antagit att avslutande skräp ignoreras.

NOTERINGAR

  Den komprimerade utdatan kan variera
Den exakta komprimerade utdatan som produceras från samma okomprimerade indatafil kan variera mellan versioner av XZ Utils även om komprimeringsflaggorna är identiska. Detta beror på att kodaren kan förbättras (snabbare eller bättre komprimering) utan att påverka filformatet. Utdatan kan variera även mellan olika byggen av samma version av XZ Utils, om olika byggflaggor används.

Ovanstående betyder att när väl --rsyncable har implementerats kommer inte nödvändigtvis de resulterande filerna vara rsync-bara om inte både gamla och nya filer har komprimerats med samma version av xz. Detta problem kan lösas om en del av kodarimplementeringen fryses för att hålla rsync-bar utdata stabil mellan xz-versioner.

  Inbäddade .xz-dekomprimerare
Inbäddade implementationer av .xz-dekomprimerare som XZ Embedded stödjer inte nödvändigtvis filer som skapas med andra typer av integritetskontroll än none och crc32. Eftersom standardvärdet är --check=crc64 måste man använda --check=none eller --check=crc32 när filer skapas för inbäddade system.

Utanför inbäddade system stödjer alla dekomprimerare av .xz-format alla typerna av kontroller, eller åtminstone kan de dekomprimera filern utan att verifiera integritetskontrollen om den specifika kontrollen inte stödjs.

XZ Embedded stödjer BCJ-filter, men endast med standard startavstånd.

EXEMPEL

  Grundläggande
Komprimera filen apa till apa.xz med standardkomprimeringsnivån (-6), och ta bort apa om komprimeringen lyckas:

    xz apa

Dekomprimera bepa.xz till bepa och ta inte bort bepa.xz även om dekomprimeringen lyckas:

    xz -dk bepa.xz

Skapa cepa.tar.xz med förinställningen -4e (-4 --extreme), vilket är långsammare än standardvärdet -6, men behöver mindre minne till komprimering och dekomprimering (48 MiB respektive 5 MiB):

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

En blandning av komprimerade och okomprimerade filer kan dekomprimeras till standard ut med ett enda kommando:

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

  Parallell komprimering av många filer
På GNU och *BSD kan find(1) och xargs(1) användas för att parallellisera komprimeringen av många filer:

    find . -type f \! -name '*.xz' -print0 \
        | xargs -0r -P4 -n16 xz -T1

Flaggan -P till xargs(1) anger antalet parallella xz-processer. Det bästa värdet till flaggan -n beror på hur många filer det finns som skapp komprimeras. Om det bara finns några stycken filer bör värdet förmodigen vara 1; med tiotusentals filer kan 100 eller mer vara lämpligt för att reducera antalet xz-processer som xargs(1) kommer att skapa.

Flaggan -T1 till xz finns för att tvinga den till enkeltrådsläge, eftersom xargs(1) används för att styra mängden parallellisering.

  Robotläge
Beräkna hur många byt som har sparats totalt efter komprimering av flera filer:

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

Ett skript kan vilja veta att det använder en tillräckligt ny xz. Följande sh(1)-skript kontrollerar att versionsnumret för verktyget xz är åtminstone 5.0.0. Denna metod är kompatibel med gamla betaversioner, vilka inte stödde flaggan --robot:

    if ! eval "$(xz --robot --version 2> /dev/null)" ||
            [ "$XZ_VERSION" -lt 50000002 ]; then
        echo "Din xz är för gammal."
    fi
    unset XZ_VERSION LIBLZMA_VERSION

Ange en gräns för minnesanvändning för dekomprimering med XZ_OPT, men om en gräns redan har satts, öka den inte:

    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

  Anpassade komprimerarfilterkedjor
Den enklaste användningen av anpassade filterkedjor är att anpassa en LZMA2-förinställning. Detta kan vara användbart eftersom förinställningarna endast täcker en delmängd av de potentiellt användbara kombinationerna av komprimeringsinställningar.

Kolumnerna CompCPU i tabellerna från beskrivningen av flaggorna options -0 ... -9 och --extreme är användbara vid anpassning av LZMA2-förinställningar. Här är de relevanta delarna samlade från dessa två tabeller:

    Förinställning | KompCPU
    -0 | 0
    -1 | 1
    -2 | 2
    -3 | 3
    -4 | 4
    -5 | 5
    -6 | 6
    -5e | 7
    -6e | 8

Om man vet att en fil behöver ett rätt stort lexikon (till exempel, 32 MiB) för att komprimeras bra, men man vill komprimera den snabbare än xz -8 skulle gjort kan en förinställning med ett lågt värde på CompCPU (till exempel, 1) ändras till att använda ett större lexikon:

    xz --lzma2=preset=1,dict=32MiB apa.tar

Med vissa filer kan ovanstående kommando vara snabbare än xz -6 samtidigt som det komprimerar betydligt bättre. Dock måste det påpekas att endast några filer drar fördel av ett stort lexikon samtidigt som värdet CompCPU hålls lågt. Den mest uppenbara situationen, är ett stort lexikon kan hälpa till mycket, är ett arkiv som innehåller väldigt snarlika filer på åtmistone några megabyte var. Lexikonstorleken måste vara signifikant större än någon enskild fil för att låta LZMA2 dra full nytta av likheterna mellan på varandra följande filer.

Om det går bra med väldigt hög minnesanvändning i komprimeraren och dekomprimeraren, och filen som komprimeras är åtminstone flera hundra megabyte, kan det vara användbart att använda ännu större lexikon än de 64 MiB som xz -9 skulle använda:

    xz -vv --lzma2=dict=192MiB stor_apa.tar

Att använda -vv (--verbose --verbose) som i exemplet ovan kan vara användbart för att se minnesbehoven för komprimeraren och dekomprimeraren. Kom ihåg att använda ett större lexikon än storleken på den okomprimerade filen är slöseri med minne, så ovanstående kommando är inte användbart för små filer.

Ibland spelar inte dekomprimeringstiden någon roll, men dekomprimerarens minnesanvändning måste hållas låg, till exempel för att göra det möjligt att dekomprimera filen på ett inbäddat system. Följande kommando använder -6e (-6 --extreme) som en bas och sätter lexikonstorleken till bara 64 KiB. Den resulterande filen kan dekomprimeras med XZ Embedded (det är därför det finns --check=crc32) som använder ungerfär 100 KiB minne.

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

Om man vill krama ur så många byte som möjligt kan justering av antalet literala kontextbitar (lc) och antalet positionsbitar (pb) ibland hjälpa. Justering av antalet literala positionsbitar (lp) kan också hjälpa, men vanligen är lc och pb viktigare. Till exempel innehåller ett källkodsarkiv huvudsakligen US-ASCII-text, så något i stil med följande kan ge aningen (som 0.1 %) mindre fil än xz -6e (försök även utan lc=4):

    xz --lzma2=preset=6e,pb=0,lc=4 källkod.tar

Att använda ett annat filter tillsammans med LZMA2 kan förbättra komprimeringen med vissa filtyper. Till exempel, för att komprimera ett delat x86-32- eller x86-64-bibliotek med filtret x86 BCJ:

    xz --x86 --lzma2 libapa.so

Observera att ordningen på filterflaggorna spelar roll. Om --x86 anges efter --lzma2 kommer xz avge ett fel, eftersom det inte kan vara något filter efter LZMA2, och även för att filtret x86 BCJ inte kan användas som det sista filtret i kedjan.

Deltafiltret tillsammans med LZMA2 gan ge bra resultat med bitkartebilder. Det bör vanligen slå PNG, som har några mer avancerade filter än enkla delta men använder Deflat för den faktiska komprimeringen.

Bilden måste sparas i okomprimerat format, till exempel som okomprimerad TIFF. Avståndsparametern i Deltafiltret sätts till att motsvara natalet byte per bildpunkt i bilden. Till exempel, 24-bitars RGB bitkarta behöver dist=3, och det är även bra att skicka pb=0 till LZMA2 för att ge plats för trebytejustering:

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

Om flera bilder har lagts in i ett gemensamt arkiv (till exempel, .tar) kommer Deltafiltret fungera på det också så länge alla bilder har samma antal byte per bildpunkt.

SE ÄVEN
xzdec(1), xzdiff(1), xzgrep(1), xzless(1), xzmore(1), gzip(1), bzip2(1), 7z(1)

XZ Utils: <https://tukaani.org/xz/>
XZ Embedded: <https://tukaani.org/xz/embedded.html>
LZMA SDK: <https://7-zip.org/sdk.html>