기술 · 실용 가이드
tar.gz가 ‘gzip 형식 아님’이라고 하나요? HTTP 디코딩과 저장 바이트 확인
다운로드 성공 후에도 HTML, 디코딩된 tar, gzip 파일이 저장될 수 있습니다. 응답을 보존하고 바이트 계층과 필요한 내용을 확인한 뒤 압축 해제 방식을 고르세요.
.tar.gz라는 이름만으로 curl이 저장한 내용을 알 수는 없습니다. 로그인 페이지, HTTP 디코딩 후의 일반 tar, 압축 파일 또는 손상된 데이터일 수 있습니다. gzip 오류는 해당 단계의 형식 불일치를 보여 줄 뿐 원인을 확정하지 않습니다.
요청 완료, 저장된 압축 스트림의 무결성, 필요한 파일의 존재를 구분하세요. HTTP 상태, Content-Encoding, 익숙한 시작 바이트, 압축 해제 도구의 성공처럼 보이는 결과는 각각 전체 판단의 일부만 제공합니다.
1. 다른 도구를 쓰기 전에 응답 하나 보존
정확한 URL, curl 버전, 원래 옵션을 기록하세요. 특히 --compressed, -i, 리디렉션, 파이프를 확인합니다. 비교 시험은 본인이 소유한 새 빈 디렉터리에서 수행하세요. 예시 URL을 바꾸고 헤더를 따로 저장한 뒤 curl의 최종 상태를 기다립니다. 첫 위치의 -q는 기본 설정 파일을 무시하며 이번 비교에는 의도적으로 --compressed를 넣지 않습니다. 아래는 Linux 셸용이며 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 ```
첫 헤더 블록만 보지 말고 리디렉션 체인의 마지막 응답을 확인하세요. -f는 HTTP 실패를 거르는 데 도움이 되지만 로그인·오류 페이지도 200을 반환할 수 있습니다. Content-Type도 단서일 뿐입니다. -i로 헤더를 본문에 섞거나 원본 표본을 덮어쓰지 마세요. 비공개 헤더를 공개 게시하거나 형식이 불분명한 바이트를 설치 프로그램에 바로 전달하지 마세요.
2. 남아 있는 gzip 계층 판별
curl의 --compressed는 HTTP 콘텐츠 인코딩을 처리합니다. .gz 파일 자체가 페이로드일 수 있으므로 서버가 보낸 내용에 따라 일반 tar가 남거나 다른 gzip 계층이 남을 수 있습니다. 중요한 점은 -D로 저장한 헤더가 디코딩 후에도 그대로라는 것입니다. Content-Encoding: gzip이 보인다고 로컬 파일에 gunzip이 여전히 필요하다고 결론 내릴 수는 없습니다.
file 식별 결과와 시작 바이트를 비교하세요. RFC 1952는 gzip 멤버의 시작을 1f 8b로 규정하지만 이 접두부로 전체 스트림을 검증할 수는 없습니다. 신뢰할 표본이 gzip으로 식별되면 gzip -t download.bin의 최종 결과를 확인합니다. HTML은 허용된 다운로드 경로를 바로잡아야 하고, 검증된 일반 tar는 tar 리더가 필요합니다. 이름 변경, 강제 옵션, -o를 -O로 바꾸는 조치로 잘못된 바이트를 고칠 수 없습니다.
3. 통제 시험으로 증거 해석
Linux에서 curl 8.5.0, gzip 1.12, GNU tar 1.35로 일곱 로컬 HTTP 응답의 아홉 응답·옵션 조합을 시험했습니다. 모두 HTTP 200과 curl 종료 0이었습니다. report.txt를 포함한 128바이트 gzip은 검사를 통과했습니다. 같은 바이트에 Content-Encoding: gzip을 붙이고 --compressed를 쓰면 10,240바이트 일반 tar가 저장됐습니다. gzip은 거부했지만 tar는 report.txt를 나열했습니다. HTTP용 gzip 포장을 추가한 경우 디코딩 후 원래 128바이트와 SHA-256이 일치했습니다.
반례도 중요합니다. HTML은 HTTP 200이어도 gzip 검사에 실패했습니다. CRC 변경과 트레일러 누락은 gzip 접두부를 유지했지만 무결성에 실패했고, tar는 최종 실패 전에 report.txt를 출력했습니다. 일반 텍스트의 유효한 gzip은 gzip 검사를 통과하고 tar에는 실패했습니다. 디코딩하지 않은 140바이트 이중 포장은 이 설치 버전에서 tar 종료 0에 빈 목록까지 냈습니다. 따라서 0만으로 필요한 내용을 증명할 수 없으며 이 결과를 모든 tar 버전에 일반화할 수 없습니다.
4. 필요한 파일을 검증한 뒤 복구 선택
게시자가 체크섬이나 서명을 제공한다면 정확히 어떤 파일과 바이트 계층을 대상으로 하는지 확인해 대조하세요. 같은 파일들을 나타내더라도 일반 tar와 gzip 포장의 해시는 다릅니다. 로컬 해시만으로는 바이트 신원만 기록할 수 있고 게시자 신뢰는 입증하지 못합니다. 대상 계층이 불명확하면 응답과 옵션을 보존하세요. 맞는 것처럼 보일 때까지 재압축하지 마세요.
신뢰할 후보에서 tar -tf download.bin의 목록과 최종 종료 상태를 확인한 뒤 필요한 파일명, 릴리스, 아키텍처와 비교합니다. 파일이 있어야 하는데 빈 목록이면 거부하고, 일부 이름을 출력한 뒤 오류가 나도 거부합니다. HTML이나 손상 데이터는 허용된 경로에서 완전한 사본을 다시 받고, 검증된 tar 또는 gzip 계층에는 맞는 리더를 선택하세요. 그다음 새 위치에 풀고 필요한 파일을 시험합니다. 새 디렉터리는 기존 출력을 보호하지만 신뢰하지 못하는 압축 파일의 샌드박스는 아닙니다.
