Convertir GZ a ZIP

La experiencia que trae a la gente hasta aquí es concreta y universalmente irritante. Llega un archivo llamado algo así como `proyecto-2.1.tar.gz`, Windows no sabe qué es, e instalar un descompresor produce un segundo archivo llamado `proyecto-2.1.tar` que Windows tampoco sabe qué hacer con él. Dos pasos después, sigue sin haber nada que mirar.

No hay nada roto. Esa es la forma normal de un paquete de Unix, y solo resulta rara si te criaste con el ZIP, donde comprimir y agrupar ocurren en la misma operación y nadie tiene que pensar en la diferencia. En el mundo Unix siempre han sido dos trabajos hechos por dos programas, y el nombre del archivo registra los dos en el orden en que se aplicaron: leído de derecha a izquierda, `proyecto-2.1.tar.gz` te cuenta la historia entera.

El GZ comprime exactamente un flujo de bytes. En ningún sitio de un archivo gzip hay un campo para una lista de nombres, ni para una carpeta, ni para un permiso: no es un formato de paquete, es un formato de compresión.

El TAR pone todo eso. Es un agrupador sin compresión alguna, de 1979, que escribe un bloque de cabecera por archivo y a continuación su contenido, uno detrás de otro. Juntos, cada uno hace bien una cosa: el TAR sabe cómo se llaman los archivos y dónde están, y el gzip hace pequeño el resultado. El mismo patrón produce `.tar.bz2` y `.tar.xz`, que son exactamente la misma disposición con otro compresor por fuera; reconocer uno es reconocer los tres.

El conversor descomprime el flujo gzip y mira qué ha salido. Si es un único elemento, intenta leerlo forzando el tipo tar y, cuando funciona, usa su contenido como carga real. Solo entonces se escribe el ZIP, desde dentro del directorio extraído, para que tus archivos queden en el nivel superior y no metidos en una carpeta envoltorio.

Que se fuerce el tipo en lugar de fiarse del nombre no es un detalle gratuito: se aprendió con los formatos hermanos. Como la cabecera de gzip puede guardar el nombre original, el archivo intermedio llega con un nombre sensato y una comprobación por nombre parece funcionar; el BZ2 y el XZ no guardan nombre alguno, y esa misma comprobación se saltaba el tar entero. El síntoma era un ZIP con un único bloque opaco dentro en lugar de los archivos.

Muchísimos archivos gzip contienen un solo fichero y ningún tar: un volcado de base de datos como `copia.sql.gz`, un `access.log.gz` rotado, un CSV exportado. Eso es gzip usado exactamente como se diseñó y no es un paquete estropeado.

El conversor lo resuelve replegándose. Cuando el contenido descomprimido no se deja leer como TAR, se trata como el único archivo que es, y el ZIP que recibes contiene ese archivo solo. Por eso esta página vale igual para la copia nocturna de un panel de hosting que para una versión de código fuente, que son cosas muy distintas con la misma extensión, y por eso no necesitas saber cuál de las dos tienes antes de convertir.

La cabecera de un gzip puede llevar el nombre y la fecha de modificación de lo que se comprimió, que es una función pequeña con un efecto visible: al descomprimir suele reaparecer un nombre con sentido en lugar de dejarte adivinando. Es lo único que gzip tiene y sus dos hermanos de Unix no.

Dentro de un paquete eso importa poco, porque el TAR ya lleva todos los nombres. Importa sobre todo en el caso del archivo único, donde el nombre de la cabecera gzip es el único registro de cómo se llamaba antes de que alguien renombrara la descarga. El ZIP que bajas toma el nombre del archivo que soltaste con la última extensión sustituida, y solo la última: `copia.tar.gz` vuelve como `copia.tar.zip`. Ese `.tar` del nombre ya no corresponde a nada de lo que hay dentro, así que conviene quitarlo a mano si el archivo va a circular.

Muy poco, porque los dos formatos comprimen con el mismo algoritmo. DEFLATE es lo que hace gzip y lo que hace el ZIP con cada una de sus entradas, así que sobre los mismos datos acaban en un sitio parecido.

La única diferencia sistemática va en contra del ZIP: el gzip comprime el tar entero como un flujo continuo y puede aprovechar repeticiones que cruzan de un archivo a otro, mientras que el ZIP vuelve a empezar en cada entrada. En un paquete de muchos archivos pequeños y parecidos —un árbol de código, un juego de ficheros de configuración— cuenta con unos pocos puntos porcentuales de más. Con cuatro archivos grandes, la diferencia no es apreciable ni merece planificarse.

El TAR registra modo, propietario y grupo de cada miembro, que es justamente por lo que a las herramientas de Unix les gusta. El ZIP no tiene un equivalente que Windows entienda, así que esos valores no viajan. La regla general de las conversiones de paquetes en este sitio es que los archivos salen byte a byte y lo que corre riesgo es lo que el contenedor sabía sobre ellos: una contraseña y, según el formato, los permisos y las marcas de tiempo originales.

Para quien se descarga un conjunto de datos o un complemento, nada de esto importa. Importa si lo que mueves se va a ejecutar en lugar de leerse: los scripts pierden el bit de ejecución, y un despliegue que lo daba por hecho falla de una forma que no parece tener nada que ver con el paquete. Vuelve a poner los modos en la máquina que los necesita.

Esta conversión se ejecuta en nuestro conversor y no en la página, porque desenvolver y reescribir paquetes requiere programas de verdad. Tu archivo viaja cifrado, se desenvuelve, se vuelve a empaquetar como ZIP y se devuelve. Se guarda con un nombre genérico, de modo que el nombre que tú le pusiste no llega al disco, y cada trabajo tiene su propio directorio temporal que se borra al terminar, también cuando algo falla por el camino. El contenedor que hace el trabajo no tiene salida a internet propia.

Los números: 25 MB por archivo subido, cien conversiones de servidor al día por visitante y un máximo de cinco peticiones por minuto. Un paquete que declare más de 2 GiB de contenido descomprimido se rechaza antes de escribir nada, que con gzip es una precaución real: una descarga modesta puede contener un árbol enorme.

Cualquier proceso que se lance para hacer el trabajo se termina a los sesenta segundos. Es tentador leer eso como «las conversiones caducan al minuto», y en este par sería falso: quitar dos capas y volver a empaquetar significa lanzar varios programas en secuencia, cada uno con su propio contador.

Así que una petición puede tardar legítimamente más de un minuto sin que nada haya ido mal. Lo que se mata al minuto es un paso concreto, normalmente porque el paquete es mucho más grande por dentro de lo que aparentaba. Si una conversión se corta, el diagnóstico útil es mirar cuánto declara descomprimido el archivo, no cuánto pesa en el disco.

Si en tu carpeta de descargas caen `.tar.gz` con regularidad, el arreglo duradero es un descompresor local y no esta página. 7-Zip y Keka quitan las dos capas en una sola acción, no cuestan nada, funcionan sin conexión y no tienen techo de tamaño. Y las versiones recientes de Windows traen ya un comando `tar` que hace lo mismo desde una terminal sin instalar absolutamente nada.

Usa el conversor cuando no puedes instalar software en el equipo que tienes delante —el portátil del trabajo, un ordenador prestado, un aula—, cuando el archivo es puntual, o cuando lo que necesitas de verdad es un ZIP para pasárselo a otra persona y no una carpeta para mirar tú. Son necesidades distintas con respuestas distintas, y una página que insistiera en que el conversor siempre es la buena no te estaría contando la verdad sobre tu propia situación.

A veces lo que originó todo esto no es un paquete comprimido sino un único artefacto comprimido: una copia de seguridad de WordPress que es un volcado SQL, una exportación que es un JSON enorme, un registro enviado desde un servidor. La extensión `.gz` es idéntica y no delata nada, que es por lo que tanta gente llega esperando una carpeta y encuentra un archivo.

La conversión lo resuelve igual, y el ZIP contiene lo que hubiera realmente dentro. Si trae un solo archivo con un nombre que no reconoces, no ha fallado nada: ese nombre venía en la cabecera del gzip y el conversor lo ha usado. Ese es el momento de mirar la extensión de debajo y no el paquete: un `.sql` quiere una herramienta de base de datos, un `.json` quiere un editor, y ningún reempaquetado va a convertir ninguno de los dos en una carpeta de documentos.