bzip2 , bunzip2 - kompresor plików sortujący bloki, wersja 1.0.8
bzcat - dekompresuje pliki do stdout
bzip2recover - odzyskuje dane z uszkodzonych plików bzip2
bzip2 [ -cdfkqstvzVL123456789 ] [ filenames ... ]
bunzip2 [ -fkvsVL ] [ filenames ... ]
bzcat [ -s ] [ filenames ... ]
bzip2recover filename
bzip2 kompresuje pliki przy użyciu algorytmu kompresji tekstu sortującego bloki Burrowsa-Wheelera i kodowania Huffmana. Kompresja jest ogólnie znacznie lepsza niż uzyskiwana przez bardziej konwencjonalne kompresory oparte na LZ77/LZ78 i zbliża się do wydajności rodziny kompresorów statystycznych PPM.
Opcje wiersza poleceń celowo są bardzo podobne do opcji GNU gzip, ale nie są identyczne.
bzip2 oczekuje, że flagom wiersza poleceń będzie towarzyszyć lista nazw plików. Każdy plik jest zastępowany jego skompresowaną wersją o nazwie „nazwa_oryginalna.bz2”. Każdy skompresowany plik ma tę samą datę modyfikacji, uprawnienia i, jeśli to możliwe, własność, co odpowiadający mu oryginał, dzięki czemu właściwości te mogą zostać poprawnie przywrócone w czasie dekompresji. Obsługa nazw plików jest naiwna w tym sensie, że nie ma mechanizmu zachowania oryginalnych nazw plików, uprawnień, własności lub dat w systemach plików, które nie mają tych koncepcji lub mają poważne ograniczenia długości nazw plików, takie jak MS-DOS.
bzip2 i bunzip2 domyślnie nie nadpisują istniejących plików. Jeśli chcesz, aby tak się stało, podaj flagę -f.
Jeśli nie podano nazw plików, bzip2 kompresuje ze standardowego wejścia na standardowe wyjście. W takim przypadku bzip2 odmówi zapisania skompresowanego wyjścia do terminala, ponieważ byłoby to całkowicie niezrozumiałe, a zatem bezcelowe.
bunzip2 (lub bzip2 -d) dekompresuje wszystkie określone pliki. Pliki, które nie zostały utworzone przez bzip2, zostaną wykryte i zignorowane oraz zostanie wyświetlone ostrzeżenie. bzip2 próbuje odgadnąć nazwę pliku rozpakowanego na podstawie nazwy pliku skompresowanego w następujący sposób:
nazwa_pliku.bz2 staje się nazwą pliku nazwa_pliku.bz zmienia się w nazwę pliku nazwa_pliku.tbz2 zmienia się w nazwę pliku.tar nazwa_pliku.tbz zmienia się w nazwa_pliku.tar dowolna inna nazwa staje się dowolna innanazwa.out
Jeśli plik nie kończy się na jednym z rozpoznawanych rozszerzeń, .bz2, .bz, .tbz2 lub .tbz, bzip2 narzeka, że nie może odgadnąć nazwy oryginalnego pliku i używa oryginalnej nazwy z dołączonym .out.
Podobnie jak w przypadku kompresji, brak podania nazw plików powoduje dekompresję ze standardowego wejścia na standardowe wyjście.
bunzip2 poprawnie zdekompresuje plik będący połączeniem dwóch lub więcej skompresowanych plików. Rezultatem jest konkatenacja odpowiednich nieskompresowanych plików. Obsługiwane jest również testowanie integralności (-t) połączonych skompresowanych plików.
Możesz także kompresować lub dekompresować pliki na standardowe wyjście, podając opcję -c. W ten sposób można skompresować i zdekompresować wiele plików. Wynikowe wyjścia są podawane sekwencyjnie na stdout. Kompresja wielu plików w ten sposób generuje strumień zawierający reprezentacje wielu skompresowanych plików. Taki strumień może być poprawnie zdekompresowany tylko przez bzip2 w wersji 0.9.0 lub nowszej. Wcześniejsze wersje bzip2 zatrzymają się po dekompresji pierwszego pliku w strumieniu.
bzcat (lub bzip2 -dc) dekompresuje wszystkie określone pliki do standardowego wyjścia.
bzip2 odczyta argumenty ze zmiennych środowiskowych BZIP2 i BZIP w tej kolejności i przetworzy je przed odczytaniem jakichkolwiek argumentów z wiersza poleceń. Daje to wygodny sposób dostarczania domyślnych argumentów.
Kompresja jest wykonywana zawsze, nawet jeśli skompresowany plik jest nieco większy niż oryginał. Pliki mniejsze niż około stu bajtów mają tendencję do powiększania się, ponieważ mechanizm kompresji ma stały narzut w obszarze 50 bajtów. Losowe dane (w tym dane wyjściowe większości kompresorów plików) są kodowane z szybkością około 8,05 bitów na bajt, co daje rozszerzenie o około 0,5%.
Jako samokontrolę dla Twojej ochrony, bzip2 używa 32-bitowych CRC, aby upewnić się, że zdekompresowana wersja pliku jest identyczna z oryginałem. Chroni to przed uszkodzeniem skompresowanych danych i przed niewykrytymi błędami w bzip2 (mam nadzieję, że jest to bardzo mało prawdopodobne). Szanse niewykrycia uszkodzenia danych są mikroskopijne, mniej więcej jedna szansa na cztery miliardy na każdy przetworzony plik. Należy jednak pamiętać, że kontrola następuje podczas dekompresji, więc może jedynie powiedzieć, że coś jest nie tak. Nie może pomóc w odzyskaniu oryginalnych nieskompresowanych danych. Możesz użyć bzip2recover, aby spróbować odzyskać dane z uszkodzonych plików.
Zwracane wartości: 0 dla normalnego wyjścia, 1 dla problemów środowiskowych (nie znaleziono pliku, nieprawidłowe flagi, błędy wejścia/wyjścia itd.), 2 dla wskazania uszkodzonego skompresowanego pliku, 3 dla wewnętrznego błędu spójności (np. błędu), który spowodował bzip2 do paniki.
Kompresuj lub dekompresuj do standardowego wyjścia.
Wymuś dekompresję. bzip2, bunzip2 i bzcat to tak naprawdę ten sam program, a decyzja o tym, jakie działania należy podjąć, jest podejmowana na podstawie używanej nazwy . Ta flaga zastępuje ten mechanizm i zmusza bzip2 do dekompresji.
Dopełnienie do -d: wymusza kompresję, niezależnie od nazwy wywołania.
Sprawdź integralność określonych plików, ale nie dekompresuj ich. To naprawdę wykonuje próbną dekompresję i odrzuca wynik.
Wymuś nadpisanie plików wyjściowych. Zwykle bzip2 nie nadpisuje istniejących plików wyjściowych. Zmusza również bzip2 do zerwania twardych linków do plików, czego inaczej by nie zrobił.
bzip2 zwykle odmawia dekompresji plików, które nie mają prawidłowych magicznych bajtów nagłówka. Jeśli jednak zostanie wymuszone (-f), przepuści takie pliki niezmodyfikowane. Tak zachowuje się GNU gzip.
Zachowaj (nie usuwaj) pliki wejściowe podczas kompresji lub dekompresji.
Zmniejsz zużycie pamięci do kompresji, dekompresji i testowania. Pliki są dekompresowane i testowane przy użyciu zmodyfikowanego algorytmu, który wymaga tylko 2,5 bajta na bajt bloku. Oznacza to, że każdy plik można zdekompresować w 2300 KB pamięci, aczkolwiek z około połową normalnej szybkości.
Podczas kompresji -s wybiera rozmiar bloku 200k, co ogranicza użycie pamięci do mniej więcej tej samej liczby, kosztem współczynnika kompresji. Krótko mówiąc, jeśli na komputerze jest mało pamięci (8 megabajtów lub mniej), użyj opcji -s do wszystkiego. Zobacz ZARZĄDZANIE PAMIĘCIĄ poniżej.
Pomiń nieistotne komunikaty ostrzegawcze. Komunikaty dotyczące błędów we/wy i innych zdarzeń krytycznych nie będą pomijane.
Tryb pełny — pokazuje współczynnik kompresji dla każdego przetworzonego pliku. Dalsze -v zwiększają poziom gadatliwości, wypluwając wiele informacji, które są interesujące głównie do celów diagnostycznych.
Wyświetl wersję oprogramowania, warunki licencji.
Ustaw rozmiar bloku na 100 k, 200 k .. 900 k podczas kompresji. Nie działa podczas dekompresji. Zobacz ZARZĄDZANIE PAMIĘCIĄ poniżej. Aliasy --fast i --best służą przede wszystkim kompatybilności z GNU gzip. W szczególności --fast nie przyspiesza znacząco rzeczy. A --best po prostu wybiera zachowanie domyślne.
Traktuje wszystkie kolejne argumenty jako nazwy plików, nawet jeśli zaczynają się od myślnika. Dzięki temu możesz obsługiwać pliki o nazwach zaczynających się od myślnika, na przykład: bzip2 -- -myfilename.
Te flagi są zbędne w wersjach 0.9.5 i nowszych. Zapewniały one pewną zgrubną kontrolę nad zachowaniem algorytmu sortowania we wcześniejszych wersjach, co czasami było przydatne. 0.9.5 i nowsze mają ulepszony algorytm, który czyni te flagi nieistotnymi.
bzip2 kompresuje duże pliki w blokach. Rozmiar bloku wpływa zarówno na osiągany współczynnik kompresji, jak i ilość pamięci potrzebnej do kompresji i dekompresji. Flagi od -1 do -9 określają rozmiar bloku odpowiednio od 100 000 bajtów do 900 000 bajtów (domyślnie). W czasie dekompresji rozmiar bloku użytego do kompresji jest odczytywany z nagłówka skompresowanego pliku, a następnie bunzip2 przydziela sobie tylko tyle pamięci, aby rozpakować plik. Ponieważ rozmiary bloków są przechowywane w skompresowanych plikach, wynika z tego, że flagi od -1 do -9 są nieistotne i dlatego są ignorowane podczas dekompresji.
Wymagania dotyczące kompresji i dekompresji w bajtach można oszacować jako:
Kompresja: 400k + (8 x rozmiar bloku)
Dekompresja: 100k + (4 x rozmiar bloku) lub 100k + (2,5 x rozmiar bloku)
Większe rozmiary bloków dają szybko malejące zyski krańcowe. Większość kompresji pochodzi z pierwszych 200 lub 300 KB rozmiaru bloku, o czym warto pamiętać podczas używania bzip2 na małych komputerach. Należy również zauważyć, że wymagania dotyczące pamięci dekompresyjnej są ustalane w czasie kompresji poprzez wybór rozmiaru bloku.
W przypadku plików skompresowanych z domyślnym rozmiarem bloku 900 KB, bunzip2 będzie wymagać około 3700 KB do dekompresji. Aby wesprzeć dekompresję dowolnego pliku na maszynie 4-megabajtowej, bunzip2 ma opcję dekompresji przy użyciu mniej więcej połowy tej ilości pamięci, czyli około 2300 kbajtów. Szybkość dekompresji jest również zmniejszona o połowę, dlatego należy korzystać z tej opcji tylko w razie potrzeby. Odpowiednią flagą jest -s.
Ogólnie rzecz biorąc, spróbuj użyć największego rozmiaru bloku, na jaki pozwalają ograniczenia pamięci, ponieważ maksymalizuje to osiągniętą kompresję. Szybkość kompresji i dekompresji praktycznie nie zależy od rozmiaru bloku.
Kolejna ważna kwestia dotyczy plików, które mieszczą się w jednym bloku — oznacza to, że większość plików, które można napotkać, używa dużego rozmiaru bloku. Ilość dotkniętej rzeczywistej pamięci jest proporcjonalna do rozmiaru pliku, ponieważ plik jest mniejszy niż blok. Na przykład skompresowanie pliku o długości 20 000 bajtów z flagą -9 spowoduje, że kompresor zaalokuje około 7600 KB pamięci, ale dotknie tylko 400 000 + 20 000 * 8=560 KB. Podobnie dekompresor przydzieli 3700k, ale dotknie tylko 100k + 20000 * 4=180 kbajtów.
Oto tabela podsumowująca maksymalne wykorzystanie pamięci dla różnych rozmiarów bloków. Zarejestrowano również całkowity skompresowany rozmiar 14 plików Calgary Text Compression Corpus, wynoszący łącznie 3 141 622 bajtów. Ta kolumna daje pewne wyobrażenie o tym, jak kompresja zmienia się w zależności od rozmiaru bloku. Liczby te zwykle zaniżają przewagę większych rozmiarów bloków dla większych plików, ponieważ Korpus jest zdominowany przez mniejsze pliki.
Kompresuj Dekompresuj Dekompresuj Corpus Flaga użycia użycia -s użycia Rozmiar
-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 kompresuje pliki w blokach, zwykle o długości 900 KB. Każdy blok jest obsługiwany niezależnie. Jeśli błąd nośnika lub transmisji spowoduje uszkodzenie wieloblokowego pliku .bz2, możliwe może być odzyskanie danych z nieuszkodzonych bloków w pliku.
Skompresowana reprezentacja każdego bloku jest ograniczona 48-bitowym wzorcem, co umożliwia znalezienie granic bloków z rozsądną pewnością. Każdy blok ma również swój własny 32-bitowy CRC, więc uszkodzone bloki można odróżnić od nieuszkodzonych.
bzip2recover to prosty program, którego celem jest wyszukiwanie bloków w plikach .bz2 i zapisywanie każdego bloku do osobnego pliku .bz2. Następnie możesz użyć bzip2 -t, aby przetestować integralność wynikowych plików i rozpakować te, które są nieuszkodzone.
bzip2recover pobiera pojedynczy argument, nazwę uszkodzonego pliku i zapisuje kilka plików „rec00001file.bz2”, „rec00002file.bz2” itp., zawierających wyodrębnione bloki. Nazwy plików wyjściowych są zaprojektowane w taki sposób, aby użycie symboli wieloznacznych w późniejszym przetwarzaniu — na przykład „bzip2 -dc rec*file.bz2 > odzyskane_dane” — przetwarzało pliki we właściwej kolejności.
bzip2recover powinno być najbardziej przydatne w przypadku dużych plików .bz2, ponieważ będą one zawierać wiele bloków. Wyraźnie daremne jest używanie go na uszkodzonych plikach jednoblokowych, ponieważ uszkodzonego bloku nie można odzyskać. Jeśli chcesz zminimalizować potencjalną utratę danych z powodu błędów nośnika lub transmisji, możesz rozważyć kompresję z mniejszym rozmiarem bloku.
Faza sortowania kompresji gromadzi podobne ciągi w pliku. Z tego powodu pliki zawierające bardzo długie ciągi powtarzających się symboli, takie jak „aabaabaabaab…” (powtórzone kilkaset razy), mogą kompresować się wolniej niż zwykle. Wersje 0.9.5 i nowsze wypadają pod tym względem znacznie lepiej niż poprzednie wersje. Stosunek czasu kompresji w najgorszym przypadku do średniego wynosi około 10:1. W przypadku poprzednich wersji liczba ta wynosiła mniej więcej 100:1. Jeśli chcesz, możesz użyć opcji -vvvv, aby bardzo szczegółowo monitorować postęp.
Zjawiska te nie mają wpływu na prędkość dekompresji.
bzip2 zwykle przydziela kilka megabajtów pamięci do działania, a następnie obciąża ją w dość losowy sposób. Oznacza to, że wydajność, zarówno kompresji, jak i dekompresji, zależy w dużej mierze od szybkości, z jaką komputer może obsłużyć braki w pamięci podręcznej. Z tego powodu zaobserwowano, że niewielkie zmiany w kodzie mające na celu zmniejszenie współczynnika chybień dają nieproporcjonalnie duże ulepszenia wydajności. Wyobrażam sobie, że bzip2 będzie działać najlepiej na komputerach z bardzo dużymi pamięciami podręcznymi.
Komunikaty o błędach we/wy nie są tak pomocne, jak mogłyby być. bzip2 usilnie stara się wykryć błędy wejścia/wyjścia i wyjść bezproblemowo, ale szczegóły problemu czasami wydają się raczej mylące.
Ta strona podręcznika odnosi się do wersji 1.0.8 programu bzip2. Skompresowane dane utworzone przez tę wersję są w pełni zgodne w przód iw tył z poprzednimi publicznymi wydaniami, wersjami 0.1pl2, 0.9.0, 0.9.5, 1.0 .0, 1.0.1, 1.0.2 i nowsze, ale z następującym wyjątkiem: 0.9.0 i nowsze mogą poprawnie dekompresować wiele połączonych skompresowanych plików. 0.1pl2 nie może tego zrobić; zatrzyma się po dekompresji tylko pierwszego pliku w strumieniu.
Wersje bzip2recover wcześniejsze niż 1.0.2 używały 32-bitowych liczb całkowitych do reprezentowania pozycji bitów w skompresowanych plikach, więc nie mogły obsłużyć skompresowanych plików dłuższych niż 512 megabajtów. Wersje 1.0.2 i nowsze używają 64-bitowych liczb całkowitych na niektórych platformach, które je obsługują (cele obsługiwane przez GNU i Windows). Aby ustalić, czy bzip2recover został zbudowany z takim ograniczeniem, uruchom go bez argumentów. W każdym razie możesz zbudować sobie nieograniczoną wersję, jeśli możesz ją ponownie skompilować z MaybeUInt64 ustawionym na 64-bitową liczbę całkowitą bez znaku.
Julian Seward, jseward@acm.org.
https://sourceware.org/bzip2/
Pomysły zawarte w bzip2 pochodzą (przynajmniej) od następujących osób: Michael Burrows i David Wheeler (za transformację sortowania bloków), David Wheeler (ponownie za programistę Huffmana), Peter Fenwick ( dla modelu kodowania strukturalnego w oryginalnym bzip i wielu udoskonaleniach) oraz Alistair Moffat, Radford Neal i Ian Witten (dla kodera arytmetycznego w oryginalnym bzip). I jestem bardzo wdzięczny za ich pomoc, wsparcie i rady. Zobacz podręcznik w dystrybucji źródeł, aby uzyskać wskazówki do źródeł dokumentacji. Christian von Roques zachęcił mnie do poszukiwania szybszych algorytmów sortowania, aby przyspieszyć kompresję. Bela Lubkin zachęcił mnie do poprawy wydajności kompresji w najgorszym przypadku. Donna Robinson dokonała XMLizacji dokumentacji. Skrypty bz* wywodzą się ze skryptów GNU gzip. Wiele osób wysyłało łatki, pomagało przy problemach z przenośnością, pożyczało maszyny, udzielało porad i było ogólnie pomocnych.