Convertir TAR a ZIP

Es la propiedad que explica esta página entera. El formato TAR se limita a escribir, uno detrás de otro, una cabecera y el contenido de cada archivo. No hay ninguna etapa de compresión en su diseño, y por eso en el mundo Unix casi nunca se ve un .tar suelto sino un .tar.gz: primero se agrupa y después se comprime con otra herramienta.

Cuando lo que tienes delante es un .tar a secas, esa segunda mitad no ha ocurrido. Reempaquetarlo como ZIP es entonces la primera vez que algo comprime ese contenido, y con material de texto —código, registros, configuraciones, volcados de datos, documentos— la diferencia de tamaño es grande y no marginal.

La estructura es de una regularidad casi mecánica: bloques fijos de 512 bytes y nada más. Cada miembro cuesta un bloque de cabecera con su nombre, su tamaño, sus permisos y su fecha, más su contenido rellenado hasta el siguiente múltiplo de 512, y el archivo termina con dos bloques de ceros.

Con unos pocos archivos grandes ese sobrecoste es invisible. Con miles de archivos pequeños —una carpeta de dependencias, una copia de un proyecto, un directorio lleno de documentos JSON diminutos— el relleno solo ya puede ser una fracción seria del total. Un ZIP también tiene un coste por entrada, pero es de decenas de bytes en lugar de un redondeo a medio kilobyte, y encima las entradas van comprimidas.

El ZIP escribe al final del archivo un directorio central que enumera cada entrada y dice dónde empieza. Un programa puede leer el contenido de un archivo grande sin descomprimir nada y sacar un fichero suelto sin tocar los demás. Eso es lo que hace que un ZIP se comporte como una carpeta cuando lo abres.

Un TAR no tiene índice ninguno. Listarlo significa leerlo desde el principio y extraer un archivo del medio significa pasar por encima de todo lo anterior. Esa decisión es consecuencia de su edad y de su propósito: se escribió en 1979 para unidades de cinta, donde retroceder no era una posibilidad. Por eso cualquier herramienta pensada para curiosear dentro de un archivo comprimido se lleva mejor con un ZIP.

Casi siempre de una máquina y no de una persona. Un panel de alojamiento que genera una copia de seguridad, una exportación de un servidor, un volcado que una canalización iba a comprimir después y no comprimió, o un compañero que trabaja en Linux y empaquetó una carpeta con el comando que tiene a mano.

Eso adelanta lo que vas a encontrar dentro: muchos archivos, nombres generados por un programa, rutas profundas y ninguna consideración hacia la persona que algún día lo abrirá. Esta conversión es normalmente el momento en que la salida de una máquina se convierte en el archivo de alguien, que es un trabajo distinto de reempaquetar algo que otro humano había montado a propósito.

El aviso que llevan todos los pares de archivos comprimidos de este sitio dice exactamente lo que ocurre: los ficheros salen byte a byte. Lo que no sobrevive es lo que el envase sabía sobre ellos en lugar de guardarlo dentro de ellos: una contraseña y, según el formato, los permisos originales y las marcas de tiempo.

Para un tarball esa es justo la parte a la que hay que prestar atención, porque un TAR guarda modo, propietario y grupo de cada miembro, y esa es una de las razones de que los flujos de despliegue y empaquetado lo usen. Si algo depende de que un guion siga siendo ejecutable después de extraer, vuelve a marcarlo tú en vez de dar por supuesto que el ZIP lo trajo.

La ganancia de tamaño no es automática. Si el tarball contiene fotografías, vídeo, PDF o archivos que ya estaban comprimidos antes de empaquetarse, el algoritmo del ZIP no encuentra casi nada que recortar y el resultado se queda cerca del TAR menos su relleno.

Conviene comprobarlo antes de suponer que la conversión resuelve un problema de transferencia. Un TAR de 25 MB lleno de JPEG no se va a convertir en un ZIP de 6 MB, ni aquí ni en ninguna otra parte: esos bytes se gastaron cuando se codificaron las fotografías. Lo que sí obtienes en cualquier caso es un archivo único que cualquier máquina abre, que muy a menudo es la verdadera razón de convertir.

Este par no se ejecuta en tu navegador. El TAR viaja cifrado hasta nuestro conversor, se guarda en un directorio de trabajo recién creado con un nombre genérico —de modo que el nombre que tú le diste no llega a tocar el disco—, 7-Zip lo extrae y vuelve a empaquetar el contenido como ZIP desde dentro de ese directorio, para que el resultado contenga tus ficheros y no una carpeta envolvente.

Ese directorio se borra en un bloque que se ejecuta tanto si la conversión terminó bien como si falló, y una prueba automática lo sujeta. El contenedor no tiene salida a internet, así que no podría enviar tu archivo a ninguna otra parte, y el resultado vuelve marcado para que no se almacene en ninguna caché.

Existe un tope: si lo que el archivo declara que ocupa al extraerse supera los 2 GiB, la extracción se rechaza antes de escribir nada. Es una defensa contra los archivos deliberadamente construidos para que un servicio que descomprime sin mirar se quede sin disco.

Con un TAR es difícil llegar a eso, precisamente porque no está comprimido: los 25 MB de subida son aproximadamente 25 MB de contenido real y no una fracción de algo mucho mayor. Vale la pena conocer el tope de todos modos si alguna vez conviertes archivos de otros formatos que sí comprimen treinta a uno.

El límite gratuito de este par es de 25 MB por archivo. Y hay una aspereza que preferimos contar: la zona donde sueltas los archivos aplica el límite de las conversiones de navegador —cuatro veces mayor— sin mirar de qué lado se ejecuta el par.

En la práctica eso significa que un TAR de 60 MB parecerá aceptado por la interfaz y será rechazado después por la API con un error de tamaño. Si el tuyo se pasa, divídelo antes en vez de averiguarlo a mitad de camino. Además del límite de tamaño hay un cupo de cien conversiones de servidor por visitante y día, que se reinicia a medianoche en tiempo universal, y un freno de cinco peticiones por minuto.

Cada programa que se lanza para atender la conversión se interrumpe a los sesenta segundos. Como reempaquetar un archivo comprimido implica extraer con un proceso y volver a empaquetar con otro, una misma petición puede pasar legítimamente del minuto sin que nada haya fallado.

Lo decimos así porque la versión cómoda —«las conversiones caducan al minuto»— es falsa y da la impresión equivocada justo cuando un TAR con muchísimos ficheros pequeños tarda algo más de lo normal. Lo cierto es lo otro: ningún paso individual puede quedarse colgado más de un minuto.

El número de entradas y las rutas del ZIP deberían coincidir exactamente con los del tarball, y cualquier programa de archivos comprimidos lista ambos sin extraer nada, así que la comparación es cuestión de medio minuto.

Lo único que merece una mirada deliberada es el primer nivel. Un TAR creado desde el directorio padre lleva una carpeta al principio de todas sus rutas y uno creado desde dentro no la lleva, y el ZIP reproduce fielmente lo que encontró. Si tus archivos aparecen un nivel más abajo de lo que esperabas, eso es la estructura del tarball asomando y no algo que haya introducido la conversión: conviene saberlo antes de que un guion con una ruta fija se ejecute contra el resultado.

Si el destino es un servidor Linux y no el escritorio de una persona, convertir a ZIP resuelve un problema que no tienes. El movimiento natural es conservar el TAR y comprimirlo: pasarlo a GZ produce el .tar.gz que cualquier herramienta Unix desenvuelve con una sola orden, y mantiene los permisos y la propiedad que el tarball llevaba dentro.

Elige ZIP cuando quien tiene que abrir el archivo está delante de un Windows o un macOS, o cuando un formulario de subida lo exige. Elige el tarball comprimido cuando el archivo vuelve a una cadena de herramientas. La diferencia no es de gusto técnico: es de quién está al otro extremo.