bzip2 , bunzip2 - un compressore di file con ordinamento a blocchi, v1.0.8
bzcat - decomprime i file in stdout
bzip2recover - recupera i dati dai file bzip2 danneggiati
bzip2 [ -cdfkqstvzVL123456789 ] [ filenames ... ]
bunzip2 [ -fkvsVL ] [ filenames ... ]
bzcat [ -s ] [ filenames ... ]
bzip2recover filename
bzip2 comprime i file utilizzando l'algoritmo di compressione del testo di ordinamento dei blocchi di Burrows-Wheeler e la codifica di Huffman. La compressione è generalmente notevolmente migliore di quella ottenuta dai compressori più convenzionali basati su LZ77/LZ78 e si avvicina alle prestazioni della famiglia PPM di compressori statistici.
Le opzioni della riga di comando sono volutamente molto simili a quelle di GNU gzip, ma non sono identiche.
bzip2 prevede che un elenco di nomi di file accompagni i flag della riga di comando. Ogni file è sostituito da una versione compressa di se stesso, con il nome "nome_originale.bz2". Ogni file compresso ha la stessa data di modifica, permessi e, quando possibile, proprietà dell'originale corrispondente, in modo che queste proprietà possano essere correttamente ripristinate al momento della decompressione. La gestione dei nomi dei file è ingenua nel senso che non esiste alcun meccanismo per preservare i nomi dei file, i permessi, le proprietà o le date originali nei filesystem che mancano di questi concetti o hanno gravi restrizioni sulla lunghezza dei nomi dei file, come MS-DOS.
bzip2 e bunzip2 per impostazione predefinita non sovrascriveranno i file esistenti. Se vuoi che ciò accada, specifica il flag -f.
Se non vengono specificati nomi di file, bzip2 esegue la compressione dallo standard input allo standard output. In questo caso, bzip2 rifiuterà di scrivere l'output compresso su un terminale, poiché ciò sarebbe del tutto incomprensibile e quindi inutile.
bunzip2 (o bzip2 -d) decomprime tutti i file specificati. I file che non sono stati creati da bzip2 verranno rilevati e ignorati e verrà emesso un avviso. bzip2 tenta di indovinare il nome del file decompresso da quello del file compresso come segue:
nomefile.bz2 diventa nomefile nomefile.bz diventa nomefile nomefile.tbz2 diventa nomefile.tar nomefile.tbz diventa nomefile.tar anyothername diventa anyothername.out
Se il file non termina con una delle terminazioni riconosciute, .bz2, .bz, .tbz2 o .tbz, bzip2 si lamenta di non poter indovinare il nome del file originale e usa il nome originale con .out aggiunto.
Come per la compressione, l'assenza di nomi di file causa la decompressione dallo standard input allo standard output.
bunzip2 decomprime correttamente un file che è la concatenazione di due o più file compressi. Il risultato è la concatenazione dei corrispondenti file non compressi. È supportato anche il test di integrità (-t) di file compressi concatenati.
Puoi anche comprimere o decomprimere i file nello standard output dando il flag -c. Più file possono essere compressi e decompressi in questo modo. Gli output risultanti vengono inviati in sequenza a stdout. La compressione di più file in questo modo genera un flusso contenente più rappresentazioni di file compressi. Tale flusso può essere decompresso correttamente solo da bzip2 versione 0.9.0 o successiva. Le versioni precedenti di bzip2 si interromperanno dopo aver decompresso il primo file nello stream.
bzcat (o bzip2 -dc) decomprime tutti i file specificati nello standard output.
bzip2 leggerà gli argomenti dalle variabili d'ambiente BZIP2 e BZIP, in questo ordine e li elaborerà prima di qualsiasi argomento letto dalla riga di comando. Questo fornisce un modo conveniente per fornire argomenti predefiniti.
La compressione viene sempre eseguita, anche se il file compresso è leggermente più grande dell'originale. I file di meno di un centinaio di byte tendono a diventare più grandi, poiché il meccanismo di compressione ha un sovraccarico costante nella regione di 50 byte. I dati casuali (incluso l'output della maggior parte dei compressori di file) sono codificati a circa 8,05 bit per byte, con un'espansione di circa lo 0,5%.
Come autocontrollo per la tua protezione, bzip2 utilizza CRC a 32 bit per assicurarsi che la versione decompressa di un file sia identica all'originale. Questo protegge dalla corruzione dei dati compressi e da bug non rilevati in bzip2 (si spera molto improbabile). Le possibilità che la corruzione dei dati non venga rilevata è microscopica, circa una possibilità su quattro miliardi per ogni file elaborato. Tieni presente, tuttavia, che il controllo si verifica durante la decompressione, quindi può solo dirti che qualcosa non va. Non può aiutarti a recuperare i dati originali non compressi. Puoi usare bzip2recover per provare a recuperare i dati dai file danneggiati.
Valori restituiti: 0 per un'uscita normale, 1 per problemi ambientali (file non trovato, flag non validi, errori I/O, &c), 2 per indicare un file compresso corrotto, 3 per un errore di consistenza interno (es. bug) che ha causato bzip2 al panico.
Comprimere o decomprimere in output standard.
Decompressione forzata. bzip2, bunzip2 e bzcat sono in realtà lo stesso programma e la decisione su quali azioni intraprendere viene presa sulla base del nome utilizzato . Questo flag sovrascrive tale meccanismo e forza la decompressione di bzip2.
Il complemento a -d: forza la compressione, indipendentemente dal nome dell'invocazione.
Controlla l'integrità dei file specificati, ma non decomprimerli. Questo esegue davvero una decompressione di prova e butta via il risultato.
Forza la sovrascrittura dei file di output. Normalmente, bzip2 non sovrascrive i file di output esistenti. Forza anche bzip2 a interrompere gli hard link ai file, cosa che altrimenti non farebbe.
bzip2 normalmente rifiuta di decomprimere i file che non hanno i magic header byte corretti. Se forzato (-f), tuttavia, passerà tali file senza modifiche. Ecco come si comporta GNU gzip.
Mantieni (non eliminare) i file di input durante la compressione o la decompressione.
Ridurre l'utilizzo della memoria, per compressione, decompressione e test. I file vengono decompressi e testati utilizzando un algoritmo modificato che richiede solo 2,5 byte per byte di blocco. Ciò significa che qualsiasi file può essere decompresso in 2300k di memoria, anche se a circa la metà della velocità normale.
Durante la compressione, -s seleziona una dimensione del blocco di 200k, che limita l'utilizzo della memoria a circa la stessa cifra, a scapito del rapporto di compressione. In breve, se la tua macchina ha poca memoria (8 megabyte o meno), usa -s per tutto. Vedere GESTIONE DELLA MEMORIA di seguito.
Elimina i messaggi di avviso non essenziali. I messaggi relativi agli errori di I/O e altri eventi critici non verranno soppressi.
Modalità dettagliata: mostra il rapporto di compressione per ogni file elaborato. Ulteriori -v aumentano il livello di verbosità, emettendo molte informazioni che sono principalmente di interesse per scopi diagnostici.
Visualizza la versione del software, i termini e le condizioni della licenza.
Impostare la dimensione del blocco su 100 k, 200 k .. 900 k durante la compressione. Non ha effetto durante la decompressione. Vedere GESTIONE DELLA MEMORIA di seguito. Gli alias --fast e --best sono principalmente per la compatibilità GNU gzip. In particolare, --fast non rende le cose significativamente più veloci. E --best seleziona semplicemente il comportamento predefinito.
Tratta tutti gli argomenti successivi come nomi di file, anche se iniziano con un trattino. In questo modo è possibile gestire file con nomi che iniziano con un trattino, ad esempio: bzip2 -- -myfilename.
Questi flag sono ridondanti nelle versioni 0.9.5 e successive. Fornivano un controllo grossolano sul comportamento dell'algoritmo di ordinamento nelle versioni precedenti, che a volte era utile. 0.9.5 e versioni successive hanno un algoritmo migliorato che rende questi flag irrilevanti.
bzip2 comprime file di grandi dimensioni in blocchi. La dimensione del blocco influisce sia sul rapporto di compressione raggiunto, sia sulla quantità di memoria necessaria per la compressione e la decompressione. I flag da -1 a -9 specificano la dimensione del blocco rispettivamente da 100.000 a 900.000 byte (impostazione predefinita). Al momento della decompressione, la dimensione del blocco usata per la compressione viene letta dall'intestazione del file compresso, e bunzip2 si alloca memoria appena sufficiente per decomprimere il file. Poiché le dimensioni dei blocchi sono memorizzate in file compressi, ne consegue che i flag da -1 a -9 sono irrilevanti e quindi ignorati durante la decompressione.
I requisiti di compressione e decompressione, in byte, possono essere stimati come:
Compressione: 400k + (8 x dimensione del blocco)
Decompressione: 100k + (4 x dimensione del blocco) o 100k + (2,5 x dimensione del blocco)
Le dimensioni dei blocchi più grandi danno rendimenti marginali in rapida diminuzione. La maggior parte della compressione proviene dai primi due o trecento k di dimensione del blocco, un fatto che vale la pena tenere a mente quando si usa bzip2 su macchine piccole. È anche importante apprezzare che il requisito di memoria di decompressione è impostato al tempo di compressione dalla scelta della dimensione del blocco.
Per i file compressi con la dimensione di blocco predefinita di 900k, bunzip2 richiederà circa 3700 kbyte per la decompressione. Per supportare la decompressione di qualsiasi file su una macchina da 4 megabyte, bunzip2 ha un'opzione per decomprimere utilizzando circa la metà di questa quantità di memoria, circa 2300 kbyte. Anche la velocità di decompressione è dimezzata, quindi dovresti usare questa opzione solo dove necessario. Il flag rilevante è -s.
In generale, prova a utilizzare la dimensione del blocco più grande consentita dai vincoli di memoria, poiché ciò massimizza la compressione ottenuta. La velocità di compressione e decompressione non è praticamente influenzata dalla dimensione del blocco.
Un altro punto significativo si applica ai file che si adattano a un singolo blocco, il che significa che la maggior parte dei file che potresti incontrare utilizza blocchi di grandi dimensioni. La quantità di memoria reale toccata è proporzionale alla dimensione del file, poiché il file è più piccolo di un blocco. Ad esempio, la compressione di un file lungo 20.000 byte con il flag -9 farà sì che il compressore allochi circa 7600k di memoria, ma ne tocchi solo 400k + 20000 * 8=560 kbyte. Allo stesso modo, il decompressore allocherà 3700k ma toccherà solo 100k + 20000 * 4=180 kbyte.
Ecco una tabella che riassume l'utilizzo massimo della memoria per diverse dimensioni di blocco. Viene registrata anche la dimensione totale compressa per 14 file del Calgary Text Compression Corpus per un totale di 3.141.622 byte. Questa colonna dà un'idea di come la compressione varia con la dimensione del blocco. Queste cifre tendono a sottovalutare il vantaggio di blocchi di dimensioni maggiori per file più grandi, poiché il Corpus è dominato da file più piccoli.
Comprimi Decomprimi Decomprimi Corpus Flag usage usage -s usage Size
-1 1200k 500k 350k 914704 -2 2000k 900k 600k 877703 -3 2800k 1300k 850k 860338 -4 3600k 1700k 1100k 846899 -5 4400k 2100k 1350 k 845160 -6 5200k 2500k 1600k 838626 -7 6100k 2900k 1850k 834096 -8 6800k 3300k 2100k 828642 -9 7600k 3700k 2350k 828642
bzip2 comprime i file in blocchi, solitamente lunghi 900kbyte. Ogni blocco viene gestito in modo indipendente. Se un errore di supporto o di trasmissione causa il danneggiamento di un file .bz2 a più blocchi, potrebbe essere possibile recuperare i dati dai blocchi non danneggiati nel file.
La rappresentazione compressa di ciascun blocco è delimitata da un modello a 48 bit, che consente di trovare i limiti del blocco con ragionevole certezza. Ogni blocco porta anche il proprio CRC a 32 bit, quindi i blocchi danneggiati possono essere distinti da quelli non danneggiati.
bzip2recover è un semplice programma il cui scopo è cercare blocchi nei file .bz2 e scrivere ogni blocco nel proprio file .bz2. È quindi possibile utilizzare bzip2 -t per testare l'integrità dei file risultanti e decomprimere quelli non danneggiati.
bzip2recover accetta un singolo argomento, il nome del file danneggiato, e scrive un numero di file "rec00001file.bz2", "rec00002file.bz2", ecc., contenenti i blocchi estratti. I nomi dei file di output sono progettati in modo che l'uso di caratteri jolly nell'elaborazione successiva, ad esempio "bzip2 -dc rec*file.bz2 > recuperato_dati", elabori i file nell'ordine corretto.
bzip2recover dovrebbe essere più utile quando si tratta di file .bz2 di grandi dimensioni, poiché questi conterranno molti blocchi. È chiaramente inutile utilizzarlo su file a blocco singolo danneggiati, poiché un blocco danneggiato non può essere recuperato. Se desideri ridurre al minimo qualsiasi potenziale perdita di dati a causa di errori multimediali o di trasmissione, potresti prendere in considerazione la compressione con una dimensione di blocco inferiore.
La fase di ordinamento della compressione raccoglie stringhe simili nel file. Per questo motivo, i file contenenti sequenze molto lunghe di simboli ripetuti, come "aabaabaabaab ..." (ripetuto diverse centinaia di volte) possono comprimersi più lentamente del normale. Le versioni 0.9.5 e successive si comportano molto meglio delle versioni precedenti in questo senso. Il rapporto tra il tempo di compressione nel caso peggiore e quello medio è nell'ordine di 10:1. Per le versioni precedenti, questa cifra era più simile a 100:1. È possibile utilizzare l'opzione -vvvv per monitorare i progressi in modo molto dettagliato, se lo si desidera.
La velocità di decompressione non è influenzata da questi fenomeni.
bzip2 di solito alloca diversi megabyte di memoria in cui operare, e quindi si carica dappertutto in modo abbastanza casuale. Ciò significa che le prestazioni, sia per la compressione che per la decompressione, sono in gran parte determinate dalla velocità con cui la tua macchina può riparare i cache miss. Per questo motivo, è stato osservato che piccole modifiche al codice per ridurre il tasso di errori forniscono miglioramenti delle prestazioni sproporzionatamente grandi. Immagino che bzip2 funzionerà al meglio su macchine con cache molto grandi.
I messaggi di errore I/O non sono così utili come potrebbero essere. bzip2 si sforza di rilevare gli errori di I/O e di uscire in modo pulito, ma i dettagli di quale sia il problema a volte sembrano piuttosto fuorvianti.
Questa pagina di manuale riguarda la versione 1.0.8 di bzip2. I dati compressi creati da questa versione sono completamente compatibili avanti e indietro con le versioni pubbliche precedenti, versioni 0.1pl2, 0.9.0, 0.9.5, 1.0 .0, 1.0.1, 1.0.2 e versioni successive, ma con la seguente eccezione: 0.9.0 e versioni successive possono decomprimere correttamente più file compressi concatenati. 0.1pl2 non può farlo; si fermerà dopo aver decompresso solo il primo file nello stream.
Le versioni di bzip2recover precedenti alla 1.0.2 utilizzavano numeri interi a 32 bit per rappresentare le posizioni dei bit nei file compressi, quindi non potevano gestire file compressi più lunghi di 512 megabyte. Le versioni 1.0.2 e successive utilizzano int a 64 bit su alcune piattaforme che le supportano (target supportati da GNU e Windows). Per stabilire se bzip2recover è stato compilato o meno con tale limitazione, eseguilo senza argomenti. In ogni caso puoi crearti una versione illimitata se puoi ricompilarla con MaybeUInt64 impostato su un numero intero a 64 bit senza segno.
Julian Seward, jseward@acm.org.
https://sourceware.org/bzip2/
Le idee incorporate in bzip2 sono dovute (almeno) alle seguenti persone: Michael Burrows e David Wheeler (per la trasformazione dell'ordinamento dei blocchi), David Wheeler (di nuovo, per il programmatore di Huffman), Peter Fenwick ( per il modello di codifica strutturata nell'originale bzip, e molti perfezionamenti), e Alistair Moffat, Radford Neal e Ian Witten (per il codificatore aritmetico nell'originale bzip). I sono molto grato per il loro aiuto, sostegno e consiglio. Vedere il manuale nella distribuzione dei sorgenti per i riferimenti alle fonti della documentazione. Christian von Roques mi ha incoraggiato a cercare algoritmi di ordinamento più veloci, in modo da velocizzare la compressione. Bela Lubkin mi ha incoraggiato a migliorare le prestazioni di compressione nel caso peggiore. Donna Robinson ha XMLizzato la documentazione. Gli script bz* derivano da quelli di GNU gzip. Molte persone hanno inviato patch, aiutato con problemi di portabilità, prestato macchine, dato consigli e sono state generalmente utili.