Tecnología · GUÍA PRÁCTICA
¿El tar.gz descargado no tiene formato gzip? Revisa la decodificación HTTP y los bytes
Una descarga correcta puede guardar HTML, un tar ya decodificado o un archivo gzip. Conserva la respuesta y verifica su capa y su contenido antes de cambiar opciones de extracción.
El nombre .tar.gz no revela qué guardó curl. Puede ser una página de acceso, un tar normal tras decodificar HTTP, un archivo comprimido o datos dañados. El mensaje de gzip indica que el formato no encaja en ese paso; no determina cuál de esas causas corresponde.
Separa tres preguntas: ¿terminó la petición, está íntegro el flujo comprimido guardado y están los archivos necesarios? El estado HTTP, Content-Encoding, un prefijo conocido y el aparente éxito del extractor solo responden partes de la investigación.
1. Conserva una respuesta antes de cambiar de extractor
Anota URL exacta, versión de curl y opciones originales, especialmente --compressed, -i, redirecciones y tuberías. Haz la comparación en un directorio nuevo y vacío que controles. Sustituye la URL de ejemplo, guarda las cabeceras aparte y espera el estado final de curl. -q en primera posición ignora su configuración predeterminada; esta comparación omite --compressed deliberadamente. Son órdenes de shell de Linux, no sintaxis de PowerShell. ```sh url='https://publisher.example/exact-asset' curl -q -fLsS -D headers.txt -o download.bin \ -w 'http=%{http_code}\nurl=%{url_effective}\n' "$url" curl_status=$? printf 'curl_exit=%s\n' "$curl_status" file download.bin od -An -tx1 -N16 download.bin ```
Examina la respuesta final de la cadena, no solo el primer bloque de cabeceras. -f ayuda a rechazar fallos HTTP, pero una página de acceso o error puede devolver 200. Content-Type también es una pista. No mezcles cabeceras y cuerpo con -i, sobrescribas la muestra original, publiques cabeceras privadas ni envíes bytes de formato incierto directamente a un instalador.
2. Identifica qué capa gzip queda
--compressed procesa la codificación de contenido HTTP. El archivo .gz puede ser además la carga útil: según lo enviado, la decodificación puede dejar un tar normal u otra capa gzip. Lo decisivo es que las cabeceras guardadas con -D permanecen iguales después. Ver Content-Encoding: gzip no demuestra que el archivo local todavía necesite gunzip.
Contrasta la identificación de file con los primeros bytes. RFC 1952 especifica 1f 8b para un miembro gzip, pero ese prefijo no valida todo el flujo. Si una muestra confiable se identifica como gzip, ejecuta gzip -t download.bin y observa el resultado final. HTML requiere corregir la ruta autorizada de descarga; un tar normal verificado requiere un lector tar. Renombrar, forzar opciones o cambiar -o por -O no convierte bytes equivocados en el archivo esperado.
3. Interpreta la evidencia con los controles
Servimos siete respuestas locales y probamos nueve combinaciones de respuesta y opciones con curl 8.5.0, gzip 1.12 y GNU tar 1.35 en Linux. Todas devolvieron HTTP 200 y salida 0 de curl. Un gzip de 128 bytes con report.txt superó su prueba. Los mismos bytes con Content-Encoding: gzip y --compressed produjeron un tar normal de 10.240 bytes: gzip lo rechazó, pero tar enumeró report.txt. Una envoltura HTTP gzip adicional se decodificó al archivo original de 128 bytes, con SHA-256 idéntico.
Los controles negativos importan. HTML falló gzip pese a HTTP 200. Un CRC modificado y un tráiler ausente conservaron el prefijo gzip, pero fallaron la integridad; tar imprimió report.txt antes de terminar con error. Un gzip válido de texto normal pasó gzip y falló tar. La envoltura doble de 140 bytes sin decodificar incluso dio una lista tar vacía con salida 0 en esta versión instalada. Por eso 0 no certifica el contenido esperado; no es una afirmación sobre todas las versiones de tar.
4. Verifica el archivo previsto y elige la reparación
Compara cualquier suma o firma del editor con el archivo y la capa exactos que describe. El tar decodificado y su paquete gzip tienen hashes distintos aunque representen los mismos archivos. Un hash local solo registra identidad de bytes; no acredita a un editor confiable. Si no está claro qué capa describe la suma esperada, conserva respuesta y opciones en vez de recomprimir hasta obtener una coincidencia aparente.
Para un candidato confiable, examina tar -tf download.bin, espera su salida final y contrasta la lista con los nombres necesarios, la versión y la arquitectura previstas. Rechaza una lista vacía si esperabas archivos, y nombres parciales seguidos de un error. Obtén una copia completa autorizada para HTML o datos dañados; elige el lector adecuado para la capa tar o gzip verificada. Solo después extrae a un destino nuevo y prueba los archivos necesarios. Ese directorio protege resultados anteriores, pero no aísla un archivo de origen no confiable.
