SINOPSIS

bzip2 [ -cdfkstvzVL123456789 ] [ ficheros ... ]
bunzip2 [ -fkvsVL ] [ ficheros ... ]
bzcat [ -s ] [ ficheros ... ]
bzip2recover fichero

DESCRIPCIÓN

bzip2 comprime ficheros utilizando el algoritmo de compresión de texto por ordenación de bloques de Burrows-Wheeler. Generalmente, la compresión obtenida es considerablemente mejor que la de compresores más convencionales basados en LZ77/LZ78, y se aproxima al rendimiento de la familia PPM de compresores estadísticos.

Las opciones de la línea de comandos son deliberadamente muy similares a las de GNU Gzip, pero no son idénticas.

bzip2 espera que una lista de nombres acompañe las opciones de la línea de comandos. Cada fichero es reemplazado por una copia comprimida de él mismo, de nombre "nombre_original.bz2". Cada fichero comprimido tiene la misma fecha de modificación y permisos que el original correspondiente, de forma que estas propiedades puedan ser recuperadas correctamente en el momento de la descompresión. El manejo de los nombres de los ficheros es "ingenuo" en el sentido de que no hay forma de preservar los nombres originales, los permisos y las fechas en los sistemas de ficheros que carecen de estos conceptos, o que tienen serias restricciones en el tamaño de los nombres, como por ejemplo MS-DOS.

Por defecto, bzip2 y bunzip2 no sobreescribirán ficheros existentes. Si quieres que esto ocurra, especifica la opción -f.

Si no se especifica el nombre de ningún fichero, bzip2 comprimirá desde la entrada estándar hacia la salida estándar. En este caso, bzip2 se negará a escribir la salida comprimida hacia una terminal, ya que ésta sería totalmente incomprensible y por lo tanto inútil.

bunzip2 (o bzip2 -d) descomprime y recupera todos los ficheros cuyos nombres acaben en ".bz2". Los ficheros sin este sufijo son ignorados. Al igual que antes, si no se especifica el nombre de ningún fichero, la descompresión se realiza desde la entrada estándar hacia la salida estándar.

bunzip2 descomprimirá correctamente un fichero que sea la concatenación de uno o más ficheros comprimidos. El resultado es la concatenación de los correspondientes ficheros descomprimidos. Con (-t) se puede comprobar la integridad de ficheros concatenados comprimidos.

También se pueden comprimir o descomprimir ficheros a la salida estándar utilizando la opción -c. Múltiples ficheros pueden ser comprimidos y descomprimidos de esta forma. Las salidas resultantes van siendo pasadas secuencialmente hacia la salida estándar. La compresión de múltiples ficheros de esta manera genera un flujo que contiene múltiples representaciones de ficheros. Tal flujo solo puede ser descomprimido correctamente por la versión 0.9.0 o superior de bzip2; versiones anteriores de bzip2 pararán tras descomprimir el primer fichero del flujo.

bzcat (o bzip2 -dc ) descomprime todos los ficheros especificados hacia la salida estándar.

La compresión siempre se realiza, incluso aunque el fichero comprimido sea ligeramente mayor que el original. Los ficheros de menos de cien bytes tienden a hacerse más grandes, ya que el mecanismo de compresión tiene una sobrecarga constante de unos 50 bytes. Datos aleatorios (incluyendo la salida de la mayoría de compresores) son codificados a unos 8.05 bits por byte, dando una expansión alrededor del 0.5%.

Como autocomprobación para tu protección, bzip2 utiliza CRCs de 32 bits para asegurarse de que la versión descomprimida de un fichero es idéntica a la original. Esto protege contra la corrupción de los datos comprimidos, y contra fallos sin detectar en bzip2 (afortunadamente es muy poco probable). La posibilidad de que la corrupción de datos pase desapercibida es microscópica, alrededor de una probabilidad entre cuatro billones por cada fichero procesado. Cuidado, sin embargo, con que la comprobación se realiza tras la descompresión, por lo que solo entonces se te informará de si algo está mal. El programa no te puede ayudar a recuperar los datos originales descomprimidos. Puede utilizar bzip2recover para intentar recuperar los datos de ficheros dañados.

CONTROL DE MEMORIA

Bzip2 comprime en bloques los ficheros grandes. El tamaño del bloque afecta tanto al porcentaje de compresión conseguido, como a la cantidad de memoria necesitada para la compresión y la descompresión. Las opciones -1 a -9 especifican que el tamaño de los bloques vaya de 100,000 bytes hasta 900,000 bytes (el utilizado) respectivamente. En el momento de descompresión, el tamaño de bloque utilizado para la compresión es leído de la cabecera del fichero comprimido y entonces bunzip2 se asigna a si mismo la memoria justa para descomprimir el fichero. Puesto que el tamaño de los bloques está guardado en los ficheros comprimidos, se deduce que las opciones -1 hasta -9 son irrelevantes para la descompresión y por tanto son ignoradas. Los requerimientos para la descompresión y la compresión, en bytes, pueden ser calculados de esta forma::

      Compresión:    400k + ( 7 x tamaño de bloque )

      Descompresión: 100k + ( 4 x tamaño de bloque ), o

                     100k + ( 2.5 x tamaño de bloque )

Los tamaños de bloques más grandes producen rápidamente resultados marginales cada vez más pequeños. La mayor parte de la compresión procede de los primeros doscientos o trecientos KBs de tamaño de bloque, un hecho a considerar cuando se utilice bzip2 en máquinas pequeñas. También es importante apreciar que los requerimientos de memoria en la descompresión vienen dados por el tamaño de bloque elegido en la compresión.

Para ficheros comprimidos con el tamaño de bloque por defecto de 900k, bunzip2 requerirá aproximadamente 3700 kbytes para descomprimir. Para soportar la descompresión de cualquier fichero en una máquina de 4MB, bunzip2 tiene una opción para descomprimir utilizando aproximadamente la mitad de esta cantidad de memoria, unos 2300 kbytes. La velocidad de descompresión también se divide por dos, por lo que solo se debe utilizar cuando sea necesario. La opción mencionada es -s.

En general, intenta utilizar el mayor tamaño de bloque que permita la cantidad de memoria de tu sistema, puesto que esto maximiza la compresión conseguida. La velocidad de compresión y descompresión no se ven prácticamente afectadas por el tamaño de bloque.

Otro punto importante tiene que ver con los ficheros que caben en un solo bloque -- eso equivale a la mayoría de ficheros que encontrará usando grandes tamaños de bloque. La cantidad de memoria utilizada es proporcional al tamaño del fichero, ya que el fichero es más pequeño que un bloque. Por ejemplo, comprimir un fichero de 20.000 bytes con la opción -9 hará que el compresor se asigne unos 6700k de memoria, pero solo utilice 400k + 20000 * 7 = 540 kilobytes de ella. De forma similar, el descompresor se asignará 3700k pero solo utilizará 100k + 20000 * 4 = 180 kbytes.

Aquí está una tabla que resume la utilización máxima de memoria para los diferentes tamaños de bloque. También se recoge el tamaño total resultante de compresión de 14 ficheros del "Calgary Text Compression Corpus" que sumaban 3,141,622 bytes. Esta columna da una idea de como varía la compresión en función del tamaño de bloque. Estos datos no llegan a dar una verdadera idea de la ventaja de tamaños de bloque grandes para ficheros grandes, ya que el Corpus está dominado por ficheros pequeños.

            Uso al     Uso al      Descomp.    Tamaño
   Opción   comprimir  descomp.    usando -s   del Corpus

     -1      1100k       500k         350k      914704
     -2      1800k       900k         600k      877703
     -3      2500k      1300k         850k      860338
     -4      3200k      1700k        1100k      846899
     -5      3900k      2100k        1350k      845160
     -6      4600k      2500k        1600k      838626
     -7      5400k      2900k        1850k      834096
     -8      6000k      3300k        2100k      828642
     -9      6700k      3700k        2350k      828642

OPCIONES

-c --stdout

Comprime o descomprime hacia la salida estándar. -c descomprimirá múltiples ficheros hacia la salida estándar, pero solo comprimirá un solo fichero hacia la salida estándar.

-d --decompress

Fuerza la descompresión. bzip2, bunzip2 y bzcat son en realidad el mismo programa, y la decisión sobre la acción a realizar se toma en función del nombre que se utilice. Esta opción ignora este mecanismo y hace que bzip2 descomprima.

-z --compress

El complementario a -d: fuerza la compresión, independientemente del nombre con que se invoque.

-t --test

Comprueba la integridad del fichero(s) especificado, pero no lo descomprime. En realidad se realiza una descompresión de prueba y se lanza el resultado.

-f --force

Fuerza la sobrescritura de los ficheros de salida. Normalmente, bzip2 no sobreescribe ficheros ya existentes.

-k --keep

Mantener (no borrar) los ficheros de entrada durante la compresión o la descompresión.

-s --small

Reduce la utilización de memoria para la compresión, la descompresión y la comprobación. Los ficheros son descomprimidos y comprobados utilizando un algoritmo modificado que solo requiere 2.5 bytes por cada byte del bloque. Esto significa que cualquier fichero puede ser descomprimido en 2300k de memoria, aunque a la mitad de la velocidad normal.

Durante la compresión, -s selecciona un tamaño de bloque de 200k, lo que limita el uso de memoria a aproximadamente el mismo número, a expensas del porcentaje de compresión. En pocas palabras, si su máquina no tiene mucha memoria (8 megabytes o menos), utilice -s para todo. Vea CONTROL DE MEMORIA arriba.

-v --verbose

Modo extenso (muestra el porcentaje de compresión para cada fichero procesado). El uso de más opciones -v incrementa el nivel de extensión, arrojando gran cantidad de información principalmente de interés para usos de diagnóstico.

-L --license -V --version

Muestra la versión del programa, los términos de la licencia y sus condiciones.

-1 a -9

Pone el tamaño de bloque a 100 k, 200 k .. 900 k en la compresión. No afecta a la descompresión. Vea CONTROL DE MEMORIA arriba.

--repetitive-fast

bzip2 introduce algunas variaciones pseudoaleatorias en bloques muy repetitivos, para limitar los casos de peor funcionamiento al comprimir. Si el ordenamiento encuentra dificultades, el bloque es aleatorizado, y el ordenamiento se reinicia. En pocas palabras, bzip2 lo intenta por tres veces antes de pasar a utilizar aleatorización. Esta opción hace que lo deje de intentar mucho antes.

--repetitive-best

Lo contrario de --repetitive-fast. Lo intenta mucho más antes de pasar a la aleatorización.

RESCATANDO DATOS DESDE FICHEROS DAÑADOS

bzip2 comprime los ficheros en bloques, normalmente de 900kbytes. Cada bloque se maneja de manera independiente. Si un error de transmisión o del medio (físico) provoca que un fichero .bz2 multibloque sea dañado, puede que sea posible recuperar los datos de los bloques intactos que queden en el fichero.

La representación comprimida de cada bloque está delimitada por un patrón de 48 bits, lo que hace posible el encontrar los límites de los bloques con cierta certeza. Cada bloque contiene su propio CRC de 32 bit, por lo que los bloques dañados puedes ser distinguidos de los intactos.

bzip2recover es un simple programa cuyo único propósito es la búsqueda de bloques en ficheros .bz2, para su posterior escritura en su propio fichero .bz2. Entonces puede utilizar bzip2 -t para comprobar la integridad de los ficheros resultantes y descomprimir aquellos que estén intactos.

bzip2recover toma un solo argumento, el nombre del fichero dañado, y crea un grupo de ficheros "rec0001fichero.bz2", "rec0002fichero.bz2", etc, conteniendo los bloques extraídos. Los nombres de salida están diseñados de forma que la utilización de comodines en un procesado posterior (por ejemplo, "bzip2 -dc rec*file.bz2 > recovered_data") liste los ficheros en el orden "correcto".

bzip2recover será de mayor provecho cuando trate ficheros .bz2 grandes, ya que estos contendrán muchos bloques. Es inútil utilizarlo en ficheros de un solo bloque dañados, ya que el bloque dañado no podrá ser recuperado. Si desea minimizar cualquier posible perdida de datos debida a un error del medio físico o de la transmisión, puede considerar la utilización de tamaños de bloque menores en la compresión.

NOTAS SOBRE El FUNCIONAMIENTO DEL PROGRAMA

La fase de ordenación del programa recoge y junta todas las cadenas similares del fichero. Debido a esto, los ficheros que contienen series muy largas de símbolos, tales como "aabaabaabaab ..." (repetida varios cientos de veces) puede que se compriman de forma extraordinariamente lenta. Puede utilizar la opción -vvvv para monitorizar en detalle el progreso, si así lo desea. La velocidad de descompresión no se ve afectada.

Estos casos patológicos son raros en la práctica, apareciendo principalmente en ficheros de prueba construidos artificialmente, y en imágenes a bajo nivel de discos. No es recomendable utilizar bzip2 para comprimir estas últimas. Si obtiene un fichero que causa una pronunciada lentitud al comprimir, intente utilizar un tamaño de bloque tan pequeño como sea posible, con la opción -1.

Normalmente bzip2 reserva varios megabytes de memoria para operar en ellos, y entonces los utiliza de una manera bastante aleatoria. Esto significa que el funcionamiento del programa, tanto para comprimir como para descomprimir, se ve en gran parte determinado por la velocidad a la que su máquina sea capaz de servir fallos de caché. Debido a esto, se ha observado que pequeños cambios en el código para reducir la tasa de fallos proporcionan una mejora desproporcionadamente grande en el funcionamiento del programa. Supongo que bzip2 funcionará mejor en máquinas con caches de gran tamaño.

AUTOR

Julian Seward, [email protected].

http://www.muraroa.demon.co.uk

Las ideas incluidas en bzip2 se deben (al menos) a la siguiente gente: Michael Burrows y David Wheeler (por la transformación por ordenación de bloques), David Wheeler (otra vez, por el codificador de Huffman), Peter Fenwick (por el modelo de programación estructurada del bzip, original, y por muchos refinamientos), y Alistair Moffat, Radford Neal y Ian Witten (por el codificador aritmético del bzip original). Estoy en deuda con ellos por su ayuda, su apoyo y sus consejos. Vea el manual en la distribución sin compilar para encontrar apuntes sobre donde hallar fuentes de documentación. Christian von Roques me animó a buscar algoritmos de ordenación más rápidos, para acelerar la compresión. Bela Lubkin me alentó para que mejorara el funcionamiento de la compresión en los casos peores. Mucha gente envío parches, ayudó con los problemas de portabilidad, prestó máquinas, dio consejo y fue de ayuda en general.