Tar Vs Zip Vs Gz: diferencia y eficiencia

Al descargar archivos, no es raro ver las extensiones .tar,  .zip o .gz. Pero, ¿conoces la diferencia entre Tar, Zip y Gz? ¿Por qué los usamos y cuál es más eficiente, tar, zip o gz?

Diferencia entre tar, zip y gz

Si tienes prisa o simplemente quieres conseguir algo fácil de recordar, aquí tienes la diferencia entre zip, tar y gz:

.tar == archivo comprimido sin comprimir
.zip == (normalmente) archivo comprimido
.gz == archivo (archivado o no) comprimido usando gzip

Un poco de historia de los archivos comprimidos.

Como muchas cosas sobre Unix y sistemas similares, la historia comienza hace mucho, mucho tiempo, en una galaxia no muy lejana llamada los años setenta. En una fría mañana de enero de 1979, la utilidad tar hizo su aparición como parte del recién lanzado Unix V7.

La utilidad tar se diseñó como una forma de escribir de manera eficiente muchos archivos en cintas. Aunque hoy en día la gran mayoría de los usuarios individuales de Linux desconocen las unidades de cinta, los tarballs (el apodo de los archivos tar) todavía se utilizan comúnmente para empaquetar varios archivos o incluso un directorio completo. árbol (o incluso bosques) en un solo archivo.

Una cosa clave que debe recordar es que un archivo tar es sólo un archivo cuyos datos no están comprimidos. En otras palabras, si tar 100 archivos de 50 kB, terminará con un archivo cuyo tamaño rondará los 5000 kB. La única ganancia que puede esperar usando tar solo sería evitar el espacio desperdiciado por el sistema de archivos, ya que la mayoría asigna espacio con cierta granularidad (por ejemplo, en mi sistema, un archivo de un byte de largo usa 4kB de espacio en disco, 1000 de ellos usarán 4 MB pero el archivo tar correspondiente “sólo” 1 MB).

Crear archivos es bueno. Pero a medida que pasó el tiempo y con la llegada de la era de las computadoras personales, la gente se dio cuenta de que podían ahorrar enormes cantidades de almacenamiento comprimiendo los datos. Entonces, una década después de la introducción de tar,  zip apareció en el mundo MS-DOS como un formato de archivo que admite compresión. El esquema de compresión más común para zip es deflate, que a su vez es una implementación del algoritmo LZ77. Pero al ser desarrollado comercialmente por PKWARE, el formato zipp ha sufrido obstáculos de patentes durante años.

Entonces, en paralelo, se creó gzip para implementar el algoritmo LZ77 en un software libre sin romper ninguna patente de PKWARE.

Un elemento clave de la filosofía Unix es “Haz una cosa y hazla bien”, gzip fue diseñado para sólo comprimir archivos. Entonces, para crear un archivo comprimido, primero debe crear un archivo utilizando la utilidad tar, por ejemplo. Y después de eso, comprimir ese archivo. Este es un archivo .tar.gz (a veces abreviado como .tgz para aumentar nuevamente esa confusión y cumplir con las olvidadas limitaciones de nombres de archivos de MS-DOS 8.3). .

A medida que la informática evolucionó, se diseñaron otros algoritmos de compresión para lograr una relación de compresión más alta. Por ejemplo, el algoritmo Burrows-Wheeler implementado en bzip2 (que conduce a archivos .tar.bz2). O, más recientemente, xz, que es una implementación del algoritmo LZMA similar al utilizado en la utilidad 7zip.

Disponibilidad y limitaciones

Hoy en día puede utilizar libremente cualquier formato de archivo tanto en Linux como en Windows.

Pero como el formato zip es compatible de forma nativa con Windows, éste está especialmente presente en entornos multiplataforma. Incluso puedes encontrar el formato de archivo zip en lugares inesperados. Por ejemplo, Sun conservó ese formato de archivo para los archivos JAR utilizados para distribuir aplicaciones Java compiladas. O para archivos OpenDocument (.odf, .odp …) utilizados por LibreOffice u otras suites ofimáticas. Todos esos formatos de archivos son archivos zip disfrazados. Si tienes curiosidad, no dudes en descomprimir uno de ellos para ver qué hay dentro:

sh$ unzip some-file.odt 
Archive:some-file.odt
extracting: mimetype 
inflating: meta.xml 
inflating: settings.xml 
inflating: content.xm
[...] 
inflating: styles.xml 
inflating: META-INF/manifest.xml

Dicho todo esto, en el mundo tipo Unix, yo todavía favorecería el tipo de archivo tar porque el formato de archivo zip no admite todos los Metadatos del sistema de archivos Unix de forma fiable. Para obtener algunas explicaciones concretas de esa última afirmación, debe saber que el formato de archivo ZIP solo define un pequeño conjunto de atributos de archivo obligatorios para almacenar para cada entrada: nombre de archivo, fecha de modificación, permisos. Más allá de esos atributos básicos, un archivador puede almacenar metadatos adicionales en el llamado campo adicional del encabezado ZIP. Pero, como los campos adicionales están definidos por la implementación, no hay garantías ni siquiera para que los archivadores compatibles almacenen o recuperen el mismo conjunto de metadatos. Comprobemos eso en un archivo de muestra:

sh$ ls -lsn data/team
total 0
0 -rw-r--r-- 1 1000 2000 0 Jan 30 12:29 team

sh$ zip -0r archive.zip data/

sh$ zipinfo -v archive.zip data/team

Central directory entry #5:
---------------------------
  data/team
  [...]
  apparent file type:                             binary
  Unix file attributes (100644 octal):            -rw-r--r--
  MS-DOS file attributes (00 hex):                none

  The central-directory extra field contains:
  - A subfield with ID 0x5455 (universal time) and 5 data bytes.
    The local extra field has UTC/GMT modification/access times.
  - A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
    01 04 e8 03 00 00 04 d0 07 00 00.

Como puede ver, la información de propiedad (UID/GID) es parte del campo adicional; puede que no sea obvio si no sabe hexadecimal ni que los metadatos ZIP se almacenan en formato little-endian, pero para abreviar, "e803" es "03e8" es "1000", el UID del archivo. Y "07d0" es "d007", que es 2000, el archivo GID.

En ese caso particular, la herramienta Info-ZIP zip disponible en mi sistema Debian almacenó algunos metadatos útiles en el campo adicional. Pero no hay garantía de que cada archivador escriba este campo adicional. E incluso si está presente, no hay garantía de que la herramienta utilizada para extraer el archivo lo entienda.

Si bien no podemos rechazar la tradición como motivación para seguir usando tarballs, con este pequeño ejemplo entenderás por qué todavía hay algunos casos (¿rincones?) en los que tar no se puede reemplazar por zip. Esto es especialmente cierto cuando desea conservar todos los metadatos de archivos estándar.

Prueba de eficiencia Tar vs Zip vs Gz

Hablaré aquí sobre la eficiencia del espacio, no de la eficiencia del tiempo, pero como regla general, más potencialmente eficiente es un algoritmo de compresión cuanto más CPU requiere.

Y para darle una idea de la relación de compresión obtenida usando diferentes algoritmos, he reunido en mi disco duro alrededor de 100 MB de archivos de formatos de archivo populares. Aquí está el resultado obtenido en mi sistema Debian Stretch (todos los tamaños según lo informado por du -sh):

Con respecto a .jpg, .mp3 y .mp4 ahora: tal vez sepas que son archivos de datos ya comprimidos. Aún mejor, es posible que hayas oído que utilizan compresión destructiva. Eso significa que no puedes reconstruir exactamente la imagen original después de una compresión JPEG. Y eso es cierto. Pero lo que es poco conocido es que después de la fase de compresión destructiva per se, los datos se comprimen una segunda vez utilizando el algoritmo no destructivo de longitud de palabra variable de Huffman para eliminar la redundancia de datos.

Por todas esas razones, se esperaba que la compresión de imágenes JPEG o archivos MP3/MP4 no generara grandes ganancias. Tenga en cuenta que, como un archivo típico contiene datos altamente comprimidos y algunos metadatos sin comprimir, aún podemos obtener algo allí. Esto explica por qué todavía tengo una ganancia notable para las imágenes JPEG, ya que tenía muchas de ellas, por lo que el tamaño general de los metadatos no era tan insignificante en comparación con el tamaño total del archivo. Una vez más, los sorprendentes resultados al comprimir archivos MP4 usando xz están probablemente relacionados con las grandes similitudes entre los distintos archivos MP4 utilizados durante mis pruebas. ¿O no lo son?

Para eventualmente despejar esas dudas, le recomiendo encarecidamente que haga sus propias comparaciones. ¡Y no dude en compartir sus observaciones con nosotros utilizando la sección de comentarios a continuación!