bzip2, bunzip2 - um compressor de arquivos que utiliza ordenação em blocos, v1.0.8
bzcat - descompacta arquivos para a saída padrão
bzip2recover - recupera dados de arquivos bzip2 danificados
SINOPSIS
bzip2 [ -cdfkqstvzVL123456789 ] [ nomes_de_arquivos ... ]
bzip2 [ -h|--help ]
bunzip2 [ -fkvsVL ] [ nomes_de_arquivos ... ]
bunzip2 [ -h|--help ]
bzcat [ -s ] [ nomes_de_arquivos ... ]
bzcat [ -h|--help ]
bzip2recover nome_do_arquivo
DESCRIÇÃO
bzip2 comprime arquivos usando o algoritmo de compressão de texto de ordenação em blocos de Burrows-Wheeler e a codificação de Huffman. A compressão é geralmente consideravelmente melhor do que a obtida por compressores baseados em LZ77/LZ78 mais convencionais e se aproxima do desempenho da família de compressores estatísticos PPM.
As opções da linha de comando são deliberadamente muito semelhantes às do GNU gzip, mas não são idênticas.
bzip2 espera uma lista de nomes de arquivos para acompanhar as flags da linha de comando. Cada arquivo é substituído por uma versão comprimida de si mesmo, com o nome "nome_original.bz2". Cada arquivo comprimido tem a mesma data de modificação, permissões e, quando possível, propriedade do arquivo original correspondente, para que essas propriedades possam ser corretamente restauradas no momento da descompressão. O tratamento dos nomes dos arquivos é ingênuo, no sentido de que não há mecanismo para preservar os nomes dos arquivos originais, permissões, propriedades ou datas em sistemas de arquivos que não possuem esses conceitos ou têm restrições significativas no tamanho dos nomes dos arquivos, como o MS-DOS.
bzip2 e bunzip2, por padrão, não sobrescreverão arquivos existentes. Se você deseja que isso aconteça, especifique a flag -f.
Se nenhum nome de arquivo for especificado, bzip2 compacta da entrada padrão para a saída padrão. Neste caso, bzip2 não escreverá a saída compactada em um terminal, pois isso seria totalmente incompreensível e, portanto, inútil.
bunzip2 (ou bzip2 -d) descompacta todos os arquivos especificados. Arquivos que não foram criados por bzip2 serão detectados e ignorados, e um aviso será emitido. bzip2 tenta adivinhar o nome do arquivo para o arquivo descompactado a partir do nome do arquivo compactado da seguinte forma:
nome_do_arquivo.bz2 torna-se nome_do_arquivo
nome_do_arquivo.bz torna-se nome_do_arquivo
nome_do_arquivo.tbz2 torna-se nome_do_arquivo.tar
nome_do_arquivo.tbz torna-se nome_do_arquivo.tar
qualquer_outro_nome torna-se qualquer_outro_nome.out
Se o arquivo não terminar com um dos finais reconhecidos, .bz2, .bz, .tbz2 ou .tbz, bzip2 reclama que não consegue adivinhar o nome do arquivo original e usa o nome original com .out anexado.
Assim como na compressão, fornecer nenhum nome de arquivo faz com que a descompressão ocorra da entrada padrão para a saída padrão.
bunzip2 irá descomprimir corretamente um arquivo que é a concatenação de dois ou mais arquivos comprimidos. O resultado é a concatenação dos arquivos descomprimidos correspondentes. O teste de integridade (-t) de arquivos comprimidos concatenados também é suportado.
Você também pode comprimir ou descomprimir arquivos para a saída padrão usando a flag -c. Vários arquivos podem ser comprimidos e descomprimidos desta forma. As saídas resultantes são enviadas sequencialmente para stdout. A compressão de vários arquivos desta maneira gera um fluxo contendo várias representações de arquivos comprimidos. Esse fluxo pode ser descomprimido corretamente apenas pela versão 0.9.0 ou posterior do bzip2. Versões anteriores do bzip2 pararão após descomprimir o primeiro arquivo no fluxo.
bzcat (ou bzip2 -dc) descomprime todos os arquivos especificados para a saída padrão.
bzip2 lerá os argumentos das variáveis de ambiente BZIP2 e BZIP, nessa ordem, e os processará antes de qualquer argumento lido da linha de comando. Isso oferece uma maneira conveniente de fornecer argumentos padrão.
A compressão é sempre realizada, mesmo que o arquivo comprimido seja ligeiramente maior que o original. Arquivos com menos de cerca de cem bytes tendem a aumentar, pois o mecanismo de compressão tem uma sobrecarga constante na região de 50 bytes. Dados aleatórios (incluindo a saída da maioria dos programas de compressão de arquivos) são codificados a cerca de 8,05 bits por byte, o que resulta em uma expansão de cerca de 0,5%.
Como uma auto-verificação para sua proteção, bzip2 usa CRCs de 32 bits para garantir que a versão descomprimida de um arquivo seja idêntica ao original. Isso protege contra corrupção dos dados comprimidos e contra bugs não detectados no bzip2 (esperançosamente, muito improváveis). A chance de corrupção de dados passar despercebida é microscópica, cerca de uma em quatro bilhões para cada arquivo processado. Esteja ciente, no entanto, de que a verificação ocorre durante a descompressão, portanto, só pode dizer que algo está errado. Não pode ajudá-lo a recuperar os dados originais não comprimidos. Você pode usar bzip2recover para tentar recuperar dados de arquivos danificados.
Valores de retorno: 0 para uma saída normal, 1 para problemas ambientais (arquivo não encontrado, flags inválidas, erros de E/S, etc.), 2 para indicar um arquivo comprimido corrompido, 3 para um erro de consistência interna (por exemplo, bug) que fez com que o bzip2 entrasse em pânico.
OPÇÕES
-c --stdout
Comprime ou descomprime para a saída padrão.
-d --decompress
Força a descompressão. bzip2, bunzip2 e bzcat são realmente o mesmo programa, e a decisão sobre quais ações tomar é feita com base em qual nome é usado. Esta flag anula esse mecanismo e força o bzip2 a descomprimir.
-z --compress
O complemento de -d: força a compressão, independentemente do nome de invocação.
-t --test
Verifica a integridade dos arquivos especificados, mas não os descomprime. Isso realmente realiza uma descompressão de teste e descarta o resultado.
-f --force
Força a sobrescrita de arquivos de saída. Normalmente, o bzip2 não sobrescreve arquivos de saída existentes. Também força o bzip2 a quebrar links simbólicos para arquivos, o que ele não faria normalmente.
O bzip2 normalmente se recusa a descompactar arquivos que não possuem o cabeçalho mágico correto. Se for forçado (-f), ele passará esses arquivos inalterados. É assim que o GNU gzip se comporta.
-k --keep
Mantém (não exclui) os arquivos de entrada durante a compactação ou descompactação.
-s --small
Reduz o uso de memória para compactação, descompactação e teste. Os arquivos são descompactados e testados usando um algoritmo modificado que requer apenas 2,5 bytes por byte de bloco. Isso significa que qualquer arquivo pode ser descompactado em 2300 KB de memória, embora com cerca de metade da velocidade normal.
Durante a compactação, -s seleciona um tamanho de bloco de 200 KB, o que limita o uso de memória para cerca da mesma quantidade, às custas da taxa de compactação. Em resumo, se sua máquina tiver pouca memória (8 MB ou menos), use -s para tudo. Veja GERENCIAMENTO DE MEMÓRIA abaixo.
-q --quiet
Suprime mensagens de aviso não essenciais. As mensagens relacionadas a erros de E/S e outros eventos críticos não serão suprimidas.
-v --verbose
Modo detalhado – exibe a taxa de compactação para cada arquivo processado. Mais -v aumentam o nível de detalhamento, exibindo muitas informações que são principalmente de interesse para fins de diagnóstico.
-h --help
Imprime uma mensagem de ajuda e sai.
-L --license -V --version
Exibe a versão do software, os termos e condições da licença.
-1 (ou --fast) a -9 (ou --best)
Define o tamanho do bloco para 100 KB, 200 KB ... 900 KB durante a compactação. Não tem efeito durante a descompactação. Veja GERENCIAMENTO DE MEMÓRIA abaixo. Os aliases --fast e --best são principalmente para compatibilidade com o GNU gzip. Em particular, --fast não torna as coisas significativamente mais rápidas. E --best simplesmente seleciona o comportamento padrão.
--
Trata todos os argumentos subsequentes como nomes de arquivo, mesmo que comecem com um hífen. Isso permite lidar com arquivos com nomes que começam com um hífen, por exemplo: bzip2 -- -myfilename.
--repetitive-fast --repetitive-best
Essas flags são redundantes nas versões 0.9.5 e superiores. Elas forneciam algum controle aproximado sobre o comportamento do algoritmo de ordenação em versões anteriores, o que às vezes era útil. As versões 0.9.5 e superiores têm um algoritmo aprimorado que torna essas flags irrelevantes.
GERENCIAMENTO DE MEMÓRIA
O bzip2 compacta arquivos grandes em blocos. O tamanho do bloco afeta tanto a taxa de compactação alcançada quanto a quantidade de memória necessária para compactação e descompactação. As flags -1 a -9 especificam o tamanho do bloco para 100.000 bytes a 900.000 bytes (o padrão), respectivamente. No momento da descompactação, o tamanho do bloco usado para compactação é lido do cabeçalho do arquivo compactado, e o bunzip2 aloca apenas memória suficiente para descompactar o arquivo. Como os tamanhos de bloco são armazenados em arquivos compactados, segue-se que as flags -1 a -9 são irrelevantes para e, portanto, ignoradas durante a descompactação.
Os requisitos de compressão e descompressão, em bytes, podem ser estimados como:
Compressão: 400 k + (8 x tamanho do bloco)
Descompressão: 100 k + (4 x tamanho do bloco), ou
100 k + (2,5 x tamanho do bloco)
Tamanhos de bloco maiores proporcionam retornos marginais rapidamente decrescentes. A maior parte da compressão vem dos primeiros dois ou três centenas de k do tamanho do bloco, um fato que vale a pena ter em mente ao usar o bzip2 em máquinas pequenas. Também é importante entender que o requisito de memória para descompressão é definido no momento da compressão, pela escolha do tamanho do bloco.
Para arquivos compactados com o tamanho de bloco padrão de 900 k, o bunzip2 exigirá cerca de 3700 kbytes para descompactar. Para suportar a descompactação de qualquer arquivo em uma máquina de 4 megabytes, o bunzip2 possui uma opção para descompactar usando aproximadamente metade dessa quantidade de memória, cerca de 2300 kbytes. A velocidade de descompactação também é reduzida pela metade, portanto, você deve usar esta opção apenas quando necessário. O sinalizador relevante é -s.
Em geral, tente usar o maior tamanho de bloco que as restrições de memória permitirem, pois isso maximiza a compressão alcançada. A velocidade de compressão e descompressão é virtualmente inafetada pelo tamanho do bloco.
Outro ponto significativo se aplica a arquivos que cabem em um único bloco – o que significa a maioria dos arquivos que você encontraria ao usar um tamanho de bloco grande. A quantidade de memória real utilizada é proporcional ao tamanho do arquivo, pois o arquivo é menor que um bloco. Por exemplo, compactar um arquivo de 20000 bytes com o sinalizador -9 fará com que o compressor aloque cerca de 7600 k de memória, mas apenas utilize 400 k + 20000 * 8 = 560 kbytes. Da mesma forma, o descompactador alocará 3700 k, mas apenas utilizará 100 k + 20000 * 4 = 180 kbytes.
Aqui está uma tabela que resume o uso máximo de memória para diferentes tamanhos de bloco. Também é registrado o tamanho total compactado para 14 arquivos do Calgary Text Compression Corpus, totalizando 3.141.622 bytes. Esta coluna oferece uma ideia de como a compressão varia com o tamanho do bloco. Esses números tendem a subestimar a vantagem de tamanhos de bloco maiores para arquivos maiores, pois o Corpus é dominado por arquivos menores.
Compactar Descompactar Descompactar Tamanho Sinalizador uso uso -s uso do Corpus
-1 1200k 500k 350k 914704
-2 2000k 900k 600k 877703
-3 2800k 1300k 850k 860338
-4 3600k 1700k 1100k 846899
-5 4400k 2100k 1350k 845160
-6 5200k 2500k 1600k 838626
-7 6100k 2900k 1850k 834096
-8 6800k 3300k 2100k 828642
-9 7600k 3700k 2350k 828642
RECUPERANDO DADOS DE ARQUIVOS DANIFICADOS
O bzip2 compacta arquivos em blocos, geralmente com 900 kbytes de comprimento. Cada bloco é tratado independentemente.
Se um erro de mídia ou transmissão causar danos a um arquivo .bz2 de vários blocos, pode ser possível recuperar dados dos blocos não danificados do arquivo.
A representação comprimida de cada bloco é delimitada por um padrão de 48 bits, o que torna possível encontrar os limites dos blocos com uma precisão razoável. Cada bloco também carrega seu próprio CRC de 32 bits, para que os blocos danificados possam ser distinguidos dos blocos não danificados.
^ zip2recover é um programa simples cujo objetivo é procurar blocos em arquivos .bz2 e gravar cada bloco em seu próprio arquivo .bz2. Você pode então usar bzip2 -t para testar a integridade dos arquivos resultantes e descomprimir aqueles que não estiverem danificados.
^ zip2recover recebe um único argumento, o nome do arquivo danificado, e grava vários arquivos "rec00001file.bz2", "rec00002file.bz2", etc., contendo os blocos extraídos. Os nomes dos arquivos de saída são projetados de forma que o uso de curingas no processamento subsequente — por exemplo, "bzip2 -dc rec*file.bz2 > recovered_data" — processe os arquivos na ordem correta.
^ zip2recover deve ser mais útil para lidar com arquivos .bz2 grandes, pois estes conterão muitos blocos. É obviamente inútil usá-lo em arquivos de bloco único danificados, pois um bloco danificado não pode ser recuperado. Se você deseja minimizar qualquer perda potencial de dados devido a erros de mídia ou transmissão, pode considerar a compressão com um tamanho de bloco menor.
NOTAS DE DESEMPENHO
A fase de classificação da compressão reúne strings semelhantes no arquivo. Por causa disso, arquivos que contêm sequências muito longas de símbolos repetidos, como "aabaabaabaab..." (repetido várias centenas de vezes), podem ser comprimidos mais lentamente do que o normal. As versões 0.9.5 e superiores têm um desempenho muito melhor do que as versões anteriores nesse aspecto. A relação entre o pior caso e o caso médio do tempo de compressão está na faixa de 10:1. Para versões anteriores, essa taxa era mais como 100:1. Você pode usar a opção -vvvv para monitorar o progresso em grande detalhe, se quiser.
A velocidade de descompressão não é afetada por esses fenômenos.
O bzip2 geralmente aloca vários megabytes de memória para operar e, em seguida, percorre toda essa memória de forma bastante aleatória. Isso significa que o desempenho, tanto para compressão quanto para descompressão, é amplamente determinado pela velocidade com que sua máquina pode atender às falhas de cache. Devido a isso, pequenas alterações no código para reduzir a taxa de falhas demonstraram gerar melhorias de desempenho desproporcionalmente grandes. Imagino que o bzip2 terá o melhor desempenho em máquinas com caches muito grandes.
RESSALVAS
As mensagens de erro de E/S não são tão úteis quanto poderiam ser. O bzip2 tenta detectar erros de E/S e sair de forma limpa, mas os detalhes sobre o que é o problema às vezes parecem bastante enganosos.
Esta página de manual se refere à versão 1.0.8 do bzip2. Os dados compactados criados por esta versão são totalmente compatíveis com as versões anteriores publicadas, versões 0.1pl2, 9.0, 0.9.5, 1.0.0, 1.0.1, 1.0.2 e superiores, mas com a seguinte exceção: 0.9.0 e versões superiores podem corrigir corretamente a descompressão de vários arquivos compactados concatenados. 0.1pl2 não pode fazer isso; ele para após descomprimir apenas o primeiro arquivo na sequência.
As versões do bzip2recover anteriores à 1.0.2 usavam inteiros de 32 bits para representar as posições de bits nos arquivos compactados, portanto, não podiam lidar com arquivos compactados com mais de 512 megabytes. As versões 0.2 e posteriores usam inteiros de 64 bits em algumas plataformas que os suportam (alvos suportados pelo GNU e Windows). Para determinar se o bzip2recover foi compilado com essa limitação, execute-o sem argumentos. De qualquer forma, você pode criar uma versão ilimitada se puder recompilá-lo com MaybeUInt64 definido como um inteiro de 64 bits sem sinal.
AUTOR
Julian Seward, _.
https://sourceware.org/bzip2/
As ideias incorporadas no bzip2 são devidas a (pelo menos) as seguintes pessoas: Michael Burrows e David Wheeler (pela transformação de ordenação de blocos), David Wheeler (novamente, pelo codificador Huffman), Peter Fenwick (pelo modelo de codificação estruturada no bzip original e muitos aprimoramentos) e Alistair Moffat, Radford Neal e Ian Witten (pelo codificador aritmético no bzip original). Estou muito em dívida por sua ajuda, apoio e conselhos. Consulte o manual na distribuição da fonte para obter ponteiros para fontes de documentação. Christian von Roques me incentivou a procurar algoritmos de ordenação mais rápidos, a fim de acelerar a compressão. Bela Lubkin me incentivou a melhorar o desempenho de compressão no pior cenário. Donna Robinson transformou a documentação em XML. Os scripts bz* são derivados dos scripts do GNU gzip. Muitas pessoas enviaram patches, ajudaram com problemas de portabilidade, emprestaram máquinas, deram conselhos e foram geralmente úteis.