Convertir BZ2 a GZ

Casi todas las conversiones de archivo comprimido buscan que el resultado ocupe menos. Esta hace lo contrario y a propósito: el GZ será, sobre texto, algo mayor que el BZ2 del que sale. Lo que se compra a cambio es el tiempo de desempaquetado, que en bzip2 es lento de una manera estructural.

Por eso el lector de esta página no es quien guarda un archivo, sino quien lo abre una y otra vez: una tarea de integración continua que descarga la misma muestra en cada ejecución, una tubería de datos que lee un conjunto publicado hace quince años, una imagen de contenedor que arrastra una dependencia congelada.

Los dos formatos se descomprimen de maneras estructuralmente distintas, y la diferencia no es cuestión de la calidad de una implementación. La salida de gzip se construye copiando bytes literales y copiando tramos anteriores desde una ventana corta: el bucle interno es esencialmente movimiento de memoria, y el hardware moderno es extraordinariamente bueno en eso.

Bzip2 tiene que invertir una transformada de Burrows-Wheeler en cada bloque. Eso significa reconstruir el orden original a partir de una permutación ordenada, un recorrido disperso y poco amistoso con la caché sobre el bloque entero antes de que un solo byte de salida sea definitivo, y encima deshacer las capas de move-to-front y Huffman que lo envuelven. Es cálculo, no copia.

Depende por completo del contenido. Bzip2 ve mucho más contexto a la vez que gzip, así que en prosa, registros, CSV, código fuente y XML encuentra repeticiones que gzip no alcanza, y ahí la diferencia es real y visible en la báscula.

Sobre otros contenidos no hay diferencia que medir. Un bzip2 lleno de JPEG, PNG, MP3 o MP4 apenas estaba comprimido: la redundancia se la habían llevado esos formatos antes de empezar a archivar. Recomprimirlo como gzip no cuesta casi nada y se lleva la ventaja de velocidad entera. Si ese es tu caso, no hay nada que sopesar.

Un flujo gzip guarda en su cabecera el nombre del archivo original. Un flujo bzip2 no guarda nada de eso: ni nombre, ni ruta, ni pista de lo que lleva dentro. Es una curiosidad del formato hasta que alguien escribe código que depende de ella.

El repaquetado tiene que desenvolver el TAR que vive dentro del archivo comprimido, y la primera versión decidía si lo había encontrado mirando el nombre. Desde un GZ funcionaba, porque gzip había recordado que aquello era un .tar. Desde un BZ2 el mismo tarball llegaba con un nombre neutro, la comprobación fallaba, y la conversión devolvía un archivo con un único fichero opaco en lugar de los treinta que entraron. Ahora el tipo se fuerza en lugar de deducirse.

La ubicuidad es la otra mitad del argumento y es fácil infravalorarla. DEFLATE es la compresión que hay dentro de la codificación de contenido de HTTP, dentro de un PNG, dentro de un ZIP y dentro de un objeto de Git. Todo lenguaje de uso general lo trae en su biblioteca estándar, sin dependencia que añadir ni licencia que revisar.

Bzip2 es una biblioteca aparte que tiene que estar presente, y en un contenedor mínimo, un entorno de ejecución restringido, un navegador o una función sin servidor a menudo no lo está. Si el archivo lo va a leer código y no una persona delante de una consola, gzip elimina una dependencia además de una espera.

Conviene nombrar lo que se pierde y no solo lo que se gana. Bzip2 comprime cada bloque de forma independiente, así que un daño en uno no destruye automáticamente todo lo que viene detrás, y hay herramientas capaces de recorrer un archivo corrupto y rescatar los bloques intactos. Un flujo gzip no tiene esa estructura.

Cuánto importe depende de dónde viva el archivo. Sobre un sistema de ficheros con sumas de verificación, sobre almacenamiento de objetos que comprueba lo que devuelve, o allí donde hay una segunda copia, importa poco. Sobre un disco viejo con el único ejemplar de algo irremplazable importa más, y entonces la respuesta no es ningún formato de compresión sino una copia de seguridad de verdad.

Si el archivo se guarda en lugar de leerse, gzip es el destino equivocado y XZ el correcto: comprimirá el mismo contenido bastante mejor que bzip2 y aun así se descomprimirá más rápido. El lector de esta página no es esa persona, pero mucha gente que convierte un bzip2 sí lo es.

La prueba es sencilla: cuenta cuántas veces se desempaqueta. A menudo, por máquinas, en un paso que alguien está esperando, gzip. Rara vez, por una persona, desde un almacenamiento que cobra por gigabyte y mes, XZ. El único caso en que bzip2 debería quedarse es una máquina con muy poca memoria, porque desempaquetarlo necesita muy poca.

Ni gzip ni bzip2 saben lo que es una carpeta: comprimen un flujo y solo uno. Por eso lo que en la práctica se llama .tar.bz2 son dos capas, y por eso lo que recibes es un archivo terminado en .gz cuyo contenido es un TAR. Renómbralo a .tar.gz y una sola orden se ocupará de las dos capas.

El repaquetado se hace desenvolviendo la capa comprimida, desenvolviendo el TAR que hay debajo y volviendo a empaquetar desde el contenido. Los ficheros salen byte por byte, porque los dos formatos son sin pérdida. Lo que puede no sobrevivir es lo que el contenedor decía sobre ellos y no dentro de ellos: una contraseña y, según el formato de origen, los permisos y las marcas de tiempo.

En nuestro servidor, no en tu equipo. La mayor parte del sitio convierte localmente y lo dice; los archivos comprimidos son una de las excepciones, porque el trabajo necesita 7-Zip y gzip como programas reales. El archivo viaja por una conexión cifrada hasta un contenedor que no tiene salida a internet propia.

Cada trabajo recibe un directorio temporal recién creado, el archivo se guarda dentro con un nombre neutro —tu nombre de fichero no llega a escribirse— y el directorio entero se borra al terminar, también cuando el trabajo falla. Cada proceso lanzado se mata a los sesenta segundos; como una conversión de archivo comprimido encadena varios, la petición completa puede legítimamente pasar de ese minuto.

El primero son 25 MB por archivo subido en el plan gratuito. Es la mitad del asunto: un bzip2 comprime el texto con fuerza, así que 25 MB de archivo pueden ser muchísimo contenido, y es fácil quedarse fuera con algo que parecía pequeño.

El segundo es un límite de expansión declarada: antes de extraer nada se le pregunta al archivo a cuánto dice que se despliega, y cualquier cosa que declare más de 2 GiB se rechaza sin abrirla. No es infalible —un archivo puede mentir a la baja— pero detiene a la mayoría honesta, y un bzip2 de texto bien comprimido puede hacer esa declaración con toda naturalidad.

Merece la pena tener clara la mecánica, porque explica todo lo que puede moverse. El archivo se descomprime a un directorio de trabajo, el TAR interior se desenvuelve, y desde el contenido resultante se construye un tarball nuevo que después se comprime con gzip. En ningún momento se reetiqueta el flujo original.

De ahí que los ficheros salgan idénticos byte a byte y que el envoltorio sea otro. Y de ahí también el aviso: lo que el contenedor guardaba sobre cada fichero, y no dentro de él —los permisos y las fechas—, depende de lo que conservara cada capa por el camino. Ni bzip2 ni gzip saben de contraseñas, así que ahí no hay nada que perder; en un ZIP o un 7Z de origen sí lo habría.

Esta conversión solo merece la pena si los números lo dicen, y obtenerlos es cosa de dos minutos: cronometra la extracción del bzip2, cronometra la del gzip resultante y pon los dos tamaños al lado. Si el archivo es pequeño o la tubería lo desempaqueta una vez al mes, el ahorro es ruido y el cambio no compensa el trasiego de actualizar lo que apunta al fichero.

Conserva el original hasta que algo haya consumido el nuevo con éxito. No porque la conversión pierda datos —no los pierde—, sino porque el tarball se reconstruye en lugar de atravesar el proceso intacto, así que el orden de los miembros, las fechas y los bits de permiso pueden moverse, y una compilación que dependiera de uno de ellos falla de una forma que no se parece en nada a un problema de archivo comprimido.