ZIP o TAR: cuál elegir y por qué importa

La diferencia estructural, en un párrafo

Un archivo TAR es una pila. Para cada miembro escribe una cabecera de 512 bytes —el nombre, los permisos, el propietario, el tamaño en octal, la fecha de modificación, una suma de comprobación, un indicador de tipo— y después los bytes del archivo y un relleno hasta el siguiente bloque entero de 512 bytes. Dos bloques de ceros marcan el final. Sin índice, sin compresión y sin contabilidad ingeniosa: ese es todo el formato, y apenas ha cambiado desde que se diseñó para unidades de cinta, de donde viene el nombre.

Un ZIP es un archivador. Cada miembro se comprime por su cuenta con deflate y se escribe con su propia cabecera local; al final del archivo viene un directorio central que lista cada miembro, su tamaño, su tamaño comprimido y dónde empieza. Un lector abre los últimos kilobytes, lee el directorio y conoce todo el contenido sin tocar un byte de los datos. Ese diseño es la razón de que un cliente de correo pueda enseñarte lo que hay dentro de un adjunto antes de extraerlo.

Todo lo demás de este artículo se deduce de esos dos párrafos. El tamaño, la extracción de un solo archivo, los permisos, los enlaces simbólicos, el comportamiento ante la corrupción: nada de eso es arbitrario, y nada exige memorizar una tabla comparativa en cuanto uno se imagina una pila a un lado y un archivador al otro.

Por qué .tar.gz gana con muchos archivos pequeños y parecidos

Deflate funciona buscando repeticiones dentro de una ventana deslizante y sustituyendo la segunda copia por una referencia corta. En un ZIP esa ventana se reinicia al principio de cada miembro, así que un compresor que mira un archivo JavaScript de 193 bytes casi no tiene con qué trabajar: los imports, el andamiaje y la llave final están en los otros cincuenta y nueve archivos, y nunca los verá. En un .tar.gz se le entrega un flujo continuo de 63.488 bytes en el que esas cincuenta y nueve copias están ahí mismo, a unos cientos de bytes de distancia.

La medición lo hace concreto. Los mismos sesenta archivos: 1.809 bytes en .tar.gz frente a 14.686 en .zip. No es una cuestión de ajuste. Pasar esos sesenta por un escritor ZIP en todos los niveles de compresión del 1 al 9 produjo nueve veces el mismo archivo de 14.490 bytes, byte a byte: el mando no está conectado a nada, porque dentro de un archivo de 193 bytes no hay nada en lo que el nivel máximo pueda esforzarse más. En el nivel 0, que almacena en vez de comprimir, el ZIP ocupaba 18.328 bytes, así que la compresión sí hace algo; simplemente lo hace en el sitio equivocado.

Dale la vuelta al corpus y la ventaja se evapora. Comprime un solo archivo de texto de 92 KB: 33.202 bytes como ZIP de un miembro, 33.110 bytes como gzip; 92 bytes de diferencia, tres por mil. No hay redundancia entre archivos cuando solo hay un archivo. La regla, por tanto, no es «tar.gz es mejor», sino: cuantos más miembros y más pequeños y parecidos sean, mayor es la diferencia; un solo archivo grande, ninguna diferencia.

El coste: sin índice y sin forma de coger un solo archivo

La compresión sólida es justamente la razón de que un .tar.gz no se pueda abrir por el medio. El flujo comprimido es una cadena larga en la que el byte un millón depende de todo lo anterior, así que un programa al que se le pide el último de sesenta archivos tiene que descomprimir los cincuenta y nueve primeros para llegar. Un ZIP hace lo contrario: los archivos construidos para este artículo llevan un registro de directorio central por cada miembro, y un lector salta ahí, encuentra la posición y descomprime 193 bytes.

La misma asimetría decide qué pasa cuando un archivo se daña. Corrompe unos bytes en un ZIP y normalmente pierdes el miembro al que pertenecen; el directorio central sigue listando el resto y una herramienta de reparación suele poder recuperarlo. Corrompe unos bytes cerca del principio de un .tar.gz y todo lo que hay después del daño queda inalcanzable, porque el estado del descompresor se ha perdido. Si escribes en un soporte poco fiable, o transfieres por un enlace que se corta, esa diferencia no tiene nada de académica.

Permisos y enlaces simbólicos: lo que este conversor perdió de verdad

El árbol de prueba no era solo sesenta archivos. También tenía un directorio, un archivo marcado como ejecutable y un enlace simbólico que apunta a otro archivo. Empaquetados por las herramientas del sistema, los dos formatos lo conservaron todo. El .tar llevaba un modo 000755 en el ejecutable y un indicador de tipo 2 en el enlace. El .zip llevaba 62 entradas de directorio central: los sesenta archivos, el directorio como 040755, el ejecutable como 0100755 y latest.js como 0120755, un enlace simbólico de diecisiete bytes, siendo esos bytes la ruta a la que apunta.

Ese último dato merece una pausa, porque la leyenda dice que el ZIP no puede llevar metadatos de Unix. Sí puede. El formato reserva un campo justo para eso, y la herramienta zip estándar de Unix lo rellena. Lo que sí es cierto es que ese campo es opcional, que quien escribe decide si lo rellena, y que muchísimos escritores no lo hacen.

El conversor de esta página es uno de ellos, y ejecutarlo lo hizo visible. Su lector de TAR solo conserva las entradas cuyo indicador de tipo dice «archivo normal», así que el directorio y el enlace simbólico se descartaron sin mensaje alguno: entraron sesenta miembros, salieron sesenta y desaparecieron dos objetos. Su representación interna de un miembro es una ruta y un bloque de bytes, sin campo para los permisos: el 000755 de la cabecera tar no tiene adónde ir. Inspeccionar el ZIP producido lo confirma: 60 entradas, todas declaradas como procedentes de un sistema tipo DOS, cada campo de permisos a cero. Ni directorio, ni enlace, ni bit de ejecución.

Para el trabajo al que sirve esta página —un .tar.gz que alguien te ha enviado y cuyo contenido quieres en una máquina que no lo abre— nada de eso importa. Para reempaquetar una entrega, una copia de seguridad o cualquier cosa con scripts dentro, todo eso importa, y conviene reempaquetar con las herramientas del sistema. Saber en cuál de los dos casos estás es toda la destreza.

Cuál puede abrir quien lo recibe sin instalar nada

Esto suele ser lo que decide, y la respuesta honesta ha cambiado. El ZIP se lee en el Explorador de Windows desde 2001 y en la Utilidad de Archivo de macOS desde el principio; nunca ha habido una máquina en la que enviar un ZIP fuera una mala apuesta. Con TAR era al revés: fuera de Unix hacía falta un programa de terceros, es decir, pedirle a un compañero que instalara software antes de poder leer tu adjunto.

Esa distancia se cerró. Windows 11 añadió la lectura nativa de .tar, .tar.gz, .tgz, .tar.bz2, .tar.xz, .tar.zst, .rar y .7z en el Explorador de archivos, anunciada en 2023 y entregada en las versiones siguientes. Así que en un Windows 11 actual un .tar.gz se abre con doble clic sin instalar nada. La trampa es todo lo que no sea un Windows 11 actual: equipos con Windows 10, imágenes corporativas bloqueadas, la vista previa web de un cliente de correo, un gestor documental, un teléfono. El ZIP funciona en todos ellos.

La regla práctica es, pues, asimétrica, y no dice qué formato es mejor. Si almacenas, despliegas o mueves archivos entre máquinas que controlas: .tar.gz, más pequeño en árboles de código y conserva los metadatos. Si envías a una persona: ZIP, salvo que sepas qué usa. Convertir de uno a otro lleva segundos, y para eso sirve la herramienta de esta página; simplemente haz la conversión en el sentido que no pierda nada que te importe.

Preguntas frecuentes

¿Un .tgz es lo mismo que un .tar.gz?

Sí, byte a byte. .tgz es una contracción que existe porque MS-DOS solo permitía tres caracteres después del punto, y ha sobrevivido a su motivo. Todo lo que lee uno lee el otro. Lo mismo vale para .tbz2 y .tar.bz2, .txz y .tar.xz, .tzst y .tar.zst. El conversor de aquí olfatea los bytes en vez de la extensión, así que acepta cualquiera de esas grafías, y también acepta un archivo cuyo nombre esté mal, que es más a menudo la situación real.

¿Por qué mi .tar es mayor que los archivos que contiene?

Porque TAR no comprime y porque redondea. Cada miembro cuesta una cabecera de 512 bytes más sus propios bytes rellenados hasta un bloque entero de 512, y el archivo termina con 1.024 bytes de ceros. En el árbol de prueba, eso convirtió 11.604 bytes de código en un .tar de 63.488 bytes: cinco veces y media más, porque sesenta archivos de 193 bytes ocupan cada uno un kilobyte completo de cabecera y relleno. No es un defecto: es el aspecto de un formato pensado para escribirse en cinta en bloques fijos. Comprímelo y el relleno, que son ceros, casi desaparece.

¿Convertir un .tar.gz a ZIP lo hará más grande?

A menudo sí, y a veces mucho. El sentido de la conversión deshace justo lo que hacía pequeño al .tar.gz: el archivo se desempaqueta en archivos individuales y luego cada uno se comprime por su cuenta. En el árbol de prueba de sesenta archivos, el ZIP de salida ocupaba 14.490 bytes frente a 1.809 de entrada: ocho veces más para el mismo contenido. Si el archivo contiene unos pocos ficheros grandes ya comprimidos (fotos, vídeo, un volcado de base de datos comprimido antes de entrar), la diferencia será casi nula. Si contiene un árbol de código, espera un salto.

¿Sirve de algo el nivel de compresión de la herramienta?

Entre «ninguna» y las otras dos, sí: almacenar en vez de comprimir daba 18.328 bytes frente a 14.490 en el árbol de prueba. Entre «normal» y «máxima», en ese mismo árbol, no: las dos produjeron archivos idénticos, igual que todos los niveles intermedios. En un único documento de 92 KB, el ajuste máximo ahorró 39 bytes frente al predeterminado. Los niveles de compresión se ganan el sueldo con miembros grandes y llenos de texto; con un montón de pequeños son un mando conectado a nada. Elige «ninguna» cuando el contenido ya esté comprimido y solo quieras un contenedor, y déjalo en normal en los demás casos.

¿Puedo conservar los permisos al convertir TAR a ZIP aquí?

No, y la herramienta no lo dice. Su representación interna de un miembro es una ruta y un bloque de bytes, sin campo para el modo, así que los permisos de las cabeceras tar se leen de largo y nunca se vuelven a escribir; el ZIP producido para este artículo tenía el campo de permisos a cero en sus sesenta miembros. Los enlaces simbólicos y las entradas de directorio se descartan por la misma razón: solo se conservan los miembros marcados como archivos normales. Si eso importa, reempaqueta con tar y zip en la línea de comandos, donde ambos formatos llevan los metadatos de forma nativa. Si solo intentas leer el archivo de alguien en una máquina que no lo abre, nada de esto te afecta.