Cookies de estadística y publicidad
Usamos cookies de estadística y de publicidad, y ambas van a Google. Si rechazas, para ti no cambia nada visible.Ir a la página de privacidad
Aquí puedes convertir GZ a XZ gratis y sin cuenta: suelta el archivo arriba y en un par de segundos tienes el resultado listo para descargar. El archivo viaja cifrado a nuestro servidor, se convierte allí y se borra en cuanto termina el trabajo.
Hasta 100 archivos a la vez. Mezclar formatos no es problema.
Se convierten uno tras otro y vuelven juntos en un ZIP.
GZ a XZ
Nadie recomprime un archivo que va a abrir dentro de un minuto. Quien llega aquí tiene algo que se ha ido acumulando: un año de registros rotados, volcados nocturnos de base de datos guardados por obligación, un conjunto de datos de investigación que hay que mantener disponible y se consulta una vez por trimestre, artefactos de integración continua que nadie ha borrado.
Gzip fue la elección correcta cuando esos archivos se escribieron —es rápido, está en todas partes y ya venía configurado en la rotación— y deja de serlo en la segunda mitad de la vida del archivo. Esa distinción es toda la decisión: gzip optimiza el momento de escribir y de leer, xz optimiza los años intermedios.
La cifra explica el resto. Gzip usa DEFLATE con una ventana de historia de 32 KB: cuando está comprimiendo el byte un millón, puede mirar hacia atrás hasta el byte novecientos sesenta y ocho mil y ni uno más. Todo lo que se repitiera antes de ahí se vuelve a comprimir desde cero, como si nunca lo hubiera visto. Xz, en su preajuste por defecto, trabaja con un diccionario de 8 MB: doscientas cincuenta y seis veces más alcance.
Merece la pena decirlo con precisión, porque es fácil encontrar la cifra equivocada. Los 64 MB que se citan a menudo son el diccionario en el ajuste máximo, no el que se obtiene sin pedir nada. Lo que sí es fijo por el formato son los 32 KB de gzip, y ésa es la mitad de la comparación que no depende de cómo estén configuradas las herramientas.
Un año de líneas de registro repite las mismas cuarenta plantillas de mensaje durante gigabytes, y gzip vuelve a descubrir cada una miles de veces mientras xz la aprende una vez. Un volcado SQL repite los nombres de columna en cada fila. Un árbol de código repite cabeceras de licencia, importaciones y andamiaje en cientos de archivos.
Frente a eso, un GZ que contenga una fotografía, un vídeo o una base de datos ya comprimida no tiene repetición de largo alcance que encontrar, porque la redundancia se la llevó el códec antes de que gzip llegara a verla. El compresor más potente del mundo no puede inventar estructura donde no la hay: en esos archivos el resultado será prácticamente idéntico en tamaño y habrás gastado tiempo de proceso a cambio de nada.
El tiempo de compresión es el coste evidente y el menos importante, porque lo paga una vez una máquina que no está esperándote. Xz es notablemente más lento que gzip en la misma tarea, consecuencia directa de buscar en un diccionario mucho mayor, y en un trabajo que se lanza de madrugada sobre un depósito entero eso sencillamente no es un problema.
El coste que decide de verdad es la memoria al descomprimir, y es el que se pasa por alto. Gzip necesita sus 32 KB de ventana, es decir, nada. Xz necesita un espacio proporcional al diccionario con el que se escribió el archivo. En un portátil o en un servidor no se nota. En un router, en un dispositivo empotrado o en un contenedor con memoria limitada es la diferencia entre que el archivo se abra y que el proceso muera. Mira la máquina que va a desempaquetar, no la que comprime.
Los dos formatos comprimen exactamente un flujo, así que ninguno de los dos sabe qué es una carpeta. En la práctica un `.gz` casi siempre es un `.tar.gz`: un TAR que lleva los nombres y las rutas, con gzip envolviéndolo. La conversión quita las dos capas y vuelve a ponerlas, reuniendo los miembros en un TAR nuevo que después se comprime con xz.
El caso que conviene conocer es el otro. Un `acceso.log.gz` contiene un único archivo corriente, y el reempaquetado le construye igualmente un TAR alrededor, de modo que lo que vuelve es un tarball que contiene `acceso.log` en lugar de un flujo comprimido a secas. Es inofensivo si lo abres con `tar xJf` y desconcertante si echas mano de `unxz` y te encuentras un archivo llamado `output.tar`.
Un flujo gzip tiene un campo de cabecera para el nombre original del archivo, que es la razón por la que descomprimir `volcado.gz` en una máquina Unix puede devolverte `volcado.sql` aunque la extensión no lo dijera. Xz no tiene ese campo: guarda una comprobación de integridad y nada sobre la procedencia de los datos.
Eso provocó un fallo real en este conversor, y está anotado en el código. Como gzip guarda un nombre y xz no, el TAR interior salía llamándose `output.tar` desde un GZ y con un nombre cualquiera desde un XZ, con lo que la comprobación por extensión no lo reconocía y el resultado era un archivo con un único fichero opaco dentro. La solución fue forzar el tipo en lugar de deducirlo del nombre. Para ti la lección es más simple: la extensión que le pongas al XZ descargado es la única etiqueta que ese archivo va a llevar nunca.
Tanto GZ como XZ llevan una comprobación de integridad sobre los datos descomprimidos, y por eso esta conversión se puede lanzar desatendida: una descarga truncada o un bit cambiado producen un error al descomprimir y no un archivo que se lee más corto sin avisar.
Lo que ninguno de los dos puede decirte es qué archivo concreto está dañado, porque a ese nivel no hay archivos. Un ZIP o un 7Z guardan una suma por entrada y pueden informar de que uno de cuarenta miembros está corrupto; un compresor de flujo sólo puede informar de que el flujo lo está. Si lo que necesitas de un archivo comprimido es integridad por miembro para poder rescatar el resto, un compresor de flujo es la forma equivocada por muy bien que comprima.
Esta conversión no ocurre en tu dispositivo. Casi todo en este sitio se queda en local y lo dice; reempaquetar archivos comprimidos es una de las excepciones, porque necesita 7-Zip y xz como programas de verdad. El archivo va por una conexión cifrada a un contenedor que los ejecuta, y ese contenedor no tiene acceso a internet hacia fuera.
Cada trabajo recibe un directorio propio que se borra en cuanto termina, haya salido bien o mal, y el archivo se guarda ahí con un nombre fijo, de modo que el que le pusiste tú no llega a escribirse en disco. Además, cualquier proceso que siga vivo a los sesenta segundos se termina: un archivo mal formado deja a un compresor dando vueltas mucho más a menudo de lo que lo hace fallar.
El límite gratuito es de 25 MB por archivo enviado, que en registros de texto comprimidos es muchísimo texto y en un conjunto de datos es un techo real. Antes de abrir nada se lee cuánto declara ocupar el archivo una vez expandido, y se rechaza si pasa de 2 GiB, que es algo que un archivo de registros comprimido puede alcanzar sin ninguna intención maliciosa.
Esa comprobación mira lo declarado y no lo que ocurre después, así que no es infalible por sí sola: un archivo puede declarar de menos y delatarse sólo al desempaquetarse. Lo que atrapa ese caso es el resto del arreglo —el corte a los sesenta segundos y un contenedor que se tira y se reconstruye— y no ese número.
BZ2 es la otra respuesta clásica a «gzip no me está comprimiendo bastante», y en la mayor parte del texto hoy pierde contra XZ en los dos ejes a la vez: peor ratio y descompresión más lenta. El registro lo marca como formato heredado por eso mismo. Su única ventaja que sigue en pie es la contraria del apartado sobre memoria: bzip2 trabaja en bloques de hasta 900 KB, así que desempaquetarlo nunca exige gran cosa.
Así que la elección no va realmente de ratio. Escoge XZ cuando la máquina que va a desempaquetar sea un ordenador normal, que es lo habitual, y BZ2 sólo cuando no lo sea: un aparato antiguo, un contenedor apretado, un sistema donde xz sencillamente no está instalado y no se puede instalar.
Convierte uno y compara los dos tamaños. Un archivo representativo dice lo que va a hacer el resto de la carpeta mucho mejor que cualquier regla general, porque la respuesta la decide el contenido y no los formatos. Si el primero apenas se mueve, para: acabas de aprender que esos datos no tienen redundancia de largo alcance y ningún compresor va a encontrarla.
Después comprueba el listado y no sólo el tamaño. Ejecuta `tar tJf` sobre el resultado y compara el número de entradas y las rutas con lo que tenía el GZ, sobre todo el primer nivel: un archivo empaquetado desde dentro de un directorio y otro empaquetado desde su padre se diferencian en una carpeta al principio de cada ruta, y esa diferencia rompe guiones mucho tiempo después de que nadie recuerde haber convertido nada.
| GZ | XZ | |
|---|---|---|
| Nombre completo | Archivo Gzip | Archivo XZ |
| Extensión de archivo | .gz, .tgz | .xz |
| Tipo de medio | application/gzip | application/x-xz |
| Compresión | Sin pérdida — no se descarta nada | Sin pérdida — no se descarta nada |
| Publicado por primera vez | 1992 | 2009 |
| Especificación | RFC 1952 | — |
| Licencia | Estándar abierto | Estándar abierto |
| Situación actual | Vigente | Vigente |
| Se abre en el navegador | Ningún navegador | Ningún navegador |
| Considerado en su lugar | BZ2, ZIP | BZ2, 7Z |
No se descarta nada. GZ y XZ guardan su contenido sin pérdida, así que la conversión cambia el envoltorio y no la calidad, y puede repetirse sin que el daño se acumule.
7-Zip y Keka leen tanto GZ como XZ, así que puedes comparar el resultado con el original sin un segundo programa.
XZ trabaja por tramos de 8 MB frente a los 32 KB de GZ: para comprimirse, una repetición tiene que caber entera dentro de uno. De ahí viene la diferencia de compresión y también el tiempo de más.
GZ se publicó en 1992. Está recogido en RFC 1952, y conviene conocerlo si el archivo tiene que sobrevivir a la herramienta que lo escribió.
XZ es de 2009. xz, 7-Zip y Keka lo leen.
GZ se publicó en 1992 y XZ en 2009. El más antiguo suele ser el archivo más seguro para entregar; el más reciente hace lo mismo con menos bytes.
Sí: esta conversión necesita software que no puede funcionar en un navegador. El archivo viaja cifrado a nuestro servidor, se borra en cuanto termina el trabajo y el resultado a los 60 minutos. El trabajo lo hace 7-Zip, el archivador, en su forma de línea de comandos.
Sí, hasta 100 conversiones al día para archivos de hasta 25 MB. Ese único límite existe porque esta conversión se ejecuta en un servidor que pagamos nosotros. Por lo demás aquí no hay nada limitado, y marca de agua no hay en ningún caso. El límite existe porque 7-Zip necesita una máquina nuestra para funcionar.
No. XZ guarda el mismo contenido sin tirar nada: el resultado es idéntico en calidad al original. Los archivos salen byte a byte iguales. Lo que no sobrevive es lo que el contenedor sabía *sobre* ellos y no lo que había *dentro*: una contraseña y, en algunos formatos, los permisos y las marcas de tiempo originales.
No se descarta nada. GZ y XZ guardan su contenido sin pérdida, así que la conversión cambia el envoltorio y no la calidad, y puede repetirse sin que el daño se acumule.