Convertir ZIP a XZ

Ahí está entero el argumento de XZ. El tiempo de compresión lo gasta un ordenador, una sola vez, mientras alguien se toma un café. La transferencia la paga cada persona que se baja el archivo, cada vez, y en un depósito medido o detrás de una red de distribución se paga además en dinero. El registro resume el formato como el más fuerte de los compresores habituales de Unix y el estándar de las descargas de código y de paquetes, y esa asimetría es la razón.

También dice cuándo no vale la pena. Un archivo que va a abrir un compañero una vez no tiene ninguna economía que optimizar: los segundos de compresión son los únicos segundos de toda la vida del archivo, y gzip ya habría terminado. XZ se elige cuando el archivo tiene público, réplicas, factura de tráfico o una vida larga por delante, y se deja en paz cuando tiene un solo destinatario.

XZ es un compresor, no un archivador. El registro lo describe como un formato de flujo con un solo miembro y anota la ausencia de estructura de directorios entre sus problemas conocidos: dentro de un .xz no hay ningún sitio donde vivan un nombre, una ruta o un bit de permisos.

Por eso el contenido de tu ZIP se coloca primero en un tar, que sí lleva todo eso, y XZ comprime ese tarball como un único objeto. No es un apaño inventado para este conversor: es exactamente el arreglo que usa el mundo Unix entero, y es la razón de que la extensión que ves en cualquier publicación de código sea .tar.xz y no un .xz a secas. Las dos capas hacen trabajos genuinamente distintos, lo cual también significa que cambiar de compresor más adelante no toca nada del tar de dentro.

La cifra es la historia. DEFLATE, que usan tanto ZIP como gzip, codifica una repetición como una referencia a algo dentro de los últimos 32 KB. LZMA2, que es lo que hay dentro de XZ, mira mucho más atrás: el registro guarda 8 MB para el preajuste por omisión de xz, es decir doscientas cincuenta veces la distancia, y codifica esas referencias con un codificador aritmético que gasta menos bits que los códigos de Huffman de DEFLATE.

Ese número merece una precisión, porque durante un tiempo esta web publicaba 64 MB y era engañoso: 64 MB es el techo de 7-Zip en su ajuste máximo, no lo que obtiene nadie por omisión. Un ajuste concreto se estaba publicando como si fuera una propiedad del formato. Las cifras que hay ahora son las de los preajustes por omisión —32 KB en gzip y ZIP, 8 MB en xz, 16 MB en 7z—, que es la comparación que un lector se encuentra de verdad.

Se nota en cualquier archivo cuya repetición esté repartida: un árbol de código donde la misma cabecera de licencia abre doscientos ficheros, un conjunto de exportaciones CSV parecidas entre sí, una carpeta de documentos hechos todos con la misma plantilla, un volcado de traducciones. Una ventana de 32 KB no llega a ver que el fichero ciento veinte se parece al fichero tres; una de 8 MB sí.

No se nota casi nada en un ZIP de fotografías, de vídeo o de PDF, porque ese contenido ya venía comprimido antes de archivarse y no queda repetición que una ventana más larga pueda encontrar. Si tu ZIP es sobre todo material multimedia, el ahorro de pasar a XZ será pequeño y el tiempo de compresión el mismo, que es una mala relación. Merece la pena saber de qué está hecho el archivo antes de elegir el compresor más caro.

Un diccionario grande no es gratis en el otro extremo. El descompresor tiene que mantener esa ventana en memoria para resolver las referencias que apuntan dentro de ella, así que la memoria necesaria para desempaquetar sigue más o menos al diccionario con el que se empaquetó y no al tamaño del archivo.

En cualquier ordenador o servidor eso es irrelevante. Deja de serlo en hardware pequeño —un router, una placa de las que caben en la mano, un agente de compilación con la memoria recortada—, que es el único sitio donde la modesta ventana de 32 KB de gzip es una ventaja en vez de una limitación. Si sabes que el archivo va a acabar en algo pequeño, esa es una razón para publicar también un .tar.gz al lado.

Comparten familia de compresión y en proporción se parecen bastante, con el registro dando 16 MB de diccionario por omisión al 7z y 8 MB al xz. La diferencia de verdad no está en el compresor sino en lo que lo rodea. 7Z es un contenedor con su propio índice de entradas, su cifrado y sus sumas de comprobación. XZ es un compresor envuelto alrededor de un flujo.

Para distribuir gana el flujo por convención: cualquier máquina Linux o macOS trae tar y xz, y casi ninguna trae 7-Zip instalado de fábrica. Para un archivo que guardas y consultas en lugar de publicar, el 7Z tiene mejor forma, porque puedes listarlo y sacar un solo fichero sin desenvolver dos capas. Misma compresión, ergonomía opuesta.

Un flujo de gzip sí puede anotar el nombre original del fichero que comprimió —hasta el punto de que nuestro propio conversor se apoya en ello al desenvolver una capa—, y un flujo de xz no anota nada parecido. Es compresión con una cabecera que describe la comprobación y los filtros, y ni un hueco donde poner un nombre o una fecha.

Eso deja toda la carga de describir el archivo en cómo lo llames. Las descargas de aquí toman tu nombre original y le ponen la extensión del destino, así que proyecto-1.4.zip vuelve como proyecto-1.4.xz; renombrarlo a proyecto-1.4.tar.xz antes de publicarlo es la diferencia entre una descarga que la gente reconoce y una que tiene que investigar. Es lo más útil que puedes hacerle al archivo después de convertirlo, y cuesta cinco segundos.

Los dos formatos se verifican a sí mismos. Un ZIP guarda una comprobación por entrada, así que un miembro dañado se detecta al extraerlo y los demás se sacan igual. XZ lleva una comprobación sobre su flujo comprimido y se niega a entregar datos que no cuadren.

Lo que cambia es la granularidad. En un ZIP, un fichero malo es un fichero malo. En un .xz el fallo se declara para el archivo entero, y el tar de dentro puede quedar irrecuperable a partir del punto dañado. Para algo que vas a publicar, un fichero de sumas junto a la descarga sigue mereciendo las dos líneas que cuesta, porque es lo único que distingue una descarga interrumpida de un archivo mal generado.

Los proyectos que aciertan en esto publican dos archivos. El .tar.xz es para quien lo va a desempaquetar en una terminal o dentro de un script, donde la descarga más pequeña es ancho de banda real y las herramientas están instaladas desde que se instaló el sistema. El ZIP se queda para todo el que está en Windows y quiere hacer doble clic, mirar dentro y no pensar jamás en algoritmos de compresión.

No es indecisión: son dos públicos con restricciones distintas, y un solo archivo no puede servir a los dos sin penalizar a uno. Si solo puedes publicar uno, publica el que tu gente pueda abrir. Un archivo comprimido maravillosamente que nadie sabe descomprimir es una incidencia de soporte con una excelente relación de compresión, y los bytes ahorrados se devuelven con creces en mensajes preguntando qué es un .tar.xz.

La conversión corre en nuestro conversor y no en tu navegador. El ZIP sube cifrado, se guarda en un directorio de trabajo con el nombre input.zip —de modo que el nombre que tú le habías puesto no toca el disco—, se extrae con 7-Zip, se empaqueta en un tar y se comprime con xz. Ese directorio se borra al terminar el trabajo, también por los caminos de error. El contenedor no tiene salida a internet, el resultado vuelve marcado para no guardarse en caché y en el despliegue no hay base de datos donde pudiera quedar nada.

Los topes que vienen con ese arreglo: 25 MB por archivo subido, cien conversiones de servidor por visitante y día contadas por día UTC, y cinco peticiones por minuto como máximo de ráfaga. Un comprimido que declare más de dos gibibytes de contenido se rechaza antes de extraer nada, y uno con contraseña se detiene de inmediato en lugar de esperar a una petición de clave que no tiene dónde aparecer. El corte de sesenta segundos se aplica por proceso lanzado, y aquí se lanzan varios en cadena, así que una petición puede pasar del minuto legítimamente.

Tres casos en los que este par es la respuesta equivocada. Si el ZIP contiene sobre todo imágenes, vídeo o PDF, porque el ahorro será pequeño y el tiempo de compresión el mismo. Si el archivo tiene un solo destinatario, porque no hay repetición de descargas entre la que repartir el coste. Y si el destinatario está en Windows sin herramientas añadidas, porque le estás mandando algo que no puede abrir.

Si el archivo es genuinamente confidencial, tampoco: xz-utils y 7-Zip hacen esto mismo en tu propia máquina sin que nada suba a ninguna parte, y para un par que corre en servidor esa es la alternativa honrada que hay que nombrar en vez de esconder. Esta página es útil cuando publicas algo que se va a bajar mucha gente y no tienes las herramientas a mano; fuera de ahí, casi siempre hay una respuesta mejor.