Convertir 7Z a GZ

Un agente de compilación descarga artefactos y los desempaqueta con tar. Un guion de despliegue espera una carga que pueda canalizar. Una caché de paquetes indexa tarballs comprimidos. Un administrador va a ejecutar una orden y no quiere oír hablar de instalar antes un archivador. Ninguno de ellos va a cambiar para adaptarse a tu archivo.

7Z es un formato excelente y toda esa infraestructura da por supuesto que no existe. Convertir no es admitir que sea peor: es reconocer que lo que hay al otro lado se escribió hace años contra gzip, que mucho más depende de ello, y que discutirlo cuesta más que los megabytes. Cuando controlas los dos extremos la cuenta es otra; el motivo habitual de estar en esta página es que controlas exactamente uno.

Un archivo gzip comprime exactamente una secuencia de bytes. No tiene índice, ni nombres, ni rutas, ni permisos: nada de lo que un contenedor guarda sobre los archivos en lugar de dentro de ellos cabe ahí.

7Z es lo contrario en todos los aspectos: un contenedor con su propio directorio de entradas, sus sumas de comprobación por entrada y su cifrado. Pasar de uno a otro necesita por tanto un paso intermedio, y ese paso es TAR. El contenido se dispone como tarball, que lleva todo lo que gzip no puede registrar, y gzip comprime ese tarball como un objeto único. La disposición no es específica de este conversor: es lo que ha significado un .tar.gz desde antes de que se escribiera ninguno de los dos formatos.

LZMA2 dentro de un 7Z codifica una repetición como referencia a algo que pudo aparecer hasta 64 MB antes. DEFLATE dentro de gzip mira los últimos 32 KB. Son dos mil veces menos alcance, y encima con una codificación menos eficiente de lo que sí encuentra.

La capa tar conserva al menos la única ventaja que merecía conservarse: gzip comprime el tarball como flujo continuo, así que la repetición que cruza las fronteras entre archivos sigue siendo visible, igual que lo era para el 7Z. Lo que no puede es alcanzar lo bastante lejos para aprovecharla. El resultado práctico es un archivo claramente mayor, sobre todo en colecciones de textos parecidos, mientras que en un conjunto de fotografías o vídeo los dos quedan cerca porque ninguno de los dos compresores tiene ya nada con que trabajar.

Un flujo gzip se descomprime desde el principio a medida que llegan los bytes, sin necesidad de ver el final del archivo. Eso es lo que hace posible descargar y desempaquetar en la misma orden, y lo que permite a un agente extraer un artefacto mientras todavía se está descargando.

Un 7Z no puede: hay que leer la estructura del archivo para localizar sus miembros, de modo que el fichero tiene que aterrizar completo antes de poder desempaquetar nada. Para una cadena de despliegue esa diferencia vale más que los megabytes que cuesta, y es el argumento entero de este par.

Toda distribución de Linux, toda instalación de macOS y toda imagen de contenedor construida sobre una de ellas trae gzip. De xz no se puede decir lo mismo en una imagen mínima, y de 7-Zip desde luego que no. Los navegadores además negocian gzip como codificación de transferencia y descomprimen las respuestas sin que se note, que es el mismo formato aplicado al cable en lugar de a un archivo en disco.

La excepción hay que comprobarla en lugar de suponerla: una base deliberadamente vacía no lleva ningún binario, ni gzip ni ningún otro, y ahí el desempaquetado tiene que ocurrir fuera de la imagen o en una etapa previa. Cuando el requisito es «tiene que funcionar con lo que haya al otro lado», ese matiz es la única letra pequeña.

La descarga toma el nombre de tu archivo de origen con la extensión de destino, así que un compilacion.7z vuelve como compilacion.gz aunque su contenido sea un tarball comprimido. La mayoría de herramientas de Unix lo deducen de los bytes; algunos guiones y algunos servidores web, no.

Renómbralo a .tar.gz, o a .tgz, que es la misma cosa escrita más corto. No cuesta nada y elimina toda una familia de confusiones aguas abajo, incluida la clásica de alguien que lo descomprime con gunzip, se encuentra un tar dentro y da por hecho que la conversión salió mal.

La compresión sólida es la propiedad que hizo pequeño el 7Z y también la que lo vuelve incómodo de convertir. Como los miembros forman un flujo continuo, llegar a cualquiera de ellos obliga a descomprimir lo que venía antes, así que la conversión desempaqueta el archivo entero antes de empezar a escribir.

De ahí que los límites de tiempo y de expansión pesen más en este par que en uno cuyo origen ya fuera un tar. Un 7Z apretado es una subida pequeña que puede representar una cantidad de trabajo muy grande, y el guardián lee lo que el archivo declara sobre sí mismo —con un tope de 2 GiB de contenido declarado— antes de escribir nada en disco, en lugar de descubrirlo a mitad de camino.

El límite de tiempo se aplica a cada proceso que se lanza, no a la petición completa. Como un reempaquetado de archivo comprimido encadena varios procesos —extraer, empaquetar en tar, comprimir con gzip—, una petición puede superar legítimamente el minuto sin que nada haya fallado.

Merece la pena decirlo con precisión porque la frase habitual, «las conversiones caducan al minuto», es falsa y produce la conclusión equivocada. Lo que se interrumpe al minuto es un paso individual. Si tu archivo se detiene, lo que se ha pasado de tiempo es una etapa concreta, casi siempre la extracción de un 7Z muy comprimido.

Este par no se ejecuta en el navegador. El 7Z sube por una conexión cifrada a nuestra interfaz de conversión, se extrae con 7-Zip, se empaqueta en tar, se comprime con gzip y vuelve. Vale la pena decirlo con claridad porque la mayor parte de este sitio funciona al revés, y una página que dijera «tu archivo no sale de tu ordenador» aquí estaría mintiendo.

Lo que sí podemos afirmar con precisión: el archivo se escribe en un directorio de trabajo recién creado y se guarda con un nombre fijo derivado de la extensión, de modo que el nombre que tú le habías puesto no llega nunca al disco; ese directorio se borra al terminar el trabajo, también cuando el trabajo falla; el contenedor que ejecuta las herramientas no tiene salida a internet; y el resultado se devuelve con la cabecera que impide guardarlo en cachés intermedias. No hay base de datos ni almacén de objetos en el despliegue.

Veinticinco megabytes por archivo, no cien: el tope menor de los dos que tiene el sitio se aplica precisamente porque aquí gastamos capacidad de servidor. Además hay cien conversiones de servidor por visitante y día, con el día contado en horario universal, y un límite de ráfaga de cinco peticiones por minuto.

Conviene tenerlo presente al automatizar. Cinco por minuto basta de sobra para trabajar a mano y se agota enseguida con un bucle; y las cien diarias se reinician a medianoche UTC, no a medianoche local, lo cual en España son las dos de la madrugada en verano. Las conversiones que se ejecutan en tu navegador no cuentan para nada de esto, porque no nos cuestan nada.

Los archivos salen byte a byte: eso está garantizado y es la razón de que este reempaquetado sea seguro. Lo que no sobrevive es lo que el contenedor guardaba sobre ellos y no dentro de ellos: una contraseña, y en algunos formatos los permisos y las marcas de tiempo originales.

La capa tar sí tiene campos para modo, usuario y grupo, y por eso las herramientas de empaquetado quieren tarballs. Lo que no puede es recuperar valores que ya no estaban: esos campos se rellenan a partir de la extracción, no de la máquina donde se crearon los archivos, así que trátalos como no especificados en lugar de como preservados. Para un artefacto de compilación suele dar igual; para algo que se va a ejecutar, no, y un guion que pierde su bit de ejecución falla señalando al guion y no al archivo que lo transportó.

Si el tarball se va a descargar entero y escribir en disco antes de que nada lo toque, la ventaja de flujo de gzip no vale nada y su peor ratio es una pérdida limpia en cada descarga. Convertir el 7Z a XZ mantiene la misma familia LZMA que el archivo ya usaba y produce un archivo mucho más pequeño.

El intercambio va también en la otra dirección y conviene decirlo: xz necesita más memoria para descomprimir, porque el descodificador sostiene el diccionario; no siempre está presente en una imagen de contenedor mínima; y no se puede consumir desde el principio del flujo. Elige gzip para cadenas de proceso y para destinos que no controlas, y xz para descargas y publicaciones que se hacen una vez y se recuperan muchas. Los dos se construyen aquí a partir del mismo tarball, así que la decisión es solo qué envoltorio va por fuera.