NAMN

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.

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:

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

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

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:

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

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:

Kolumnbeskrivningar:

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.

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:

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:

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:

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:

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.

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:

Alla BCJ-filter stödjer samma flaggor:

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

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:

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.

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:

Kolumnerna på stream-raderna:

Kolumnerna på block-raderna:

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:

Kolumnerna på summary-raderna:

Kolumnerna på totals-raden:

Om --verbose angavs två gånger inkluderas ytterligare kolumner på totals-raden:

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.

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.

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:

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.

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.

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:

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.