テクノロジー · 実用ガイド
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で、ローカルの7種類のHTTP応答に対し9通りを試験しました。すべて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で空リストになりました。ゼロだけでは意図した内容の証明になりません。この挙動を全tar版へ一般化はできません。
4. 意図した成果物を検証してから修復
発行元がチェックサムや署名を提供するなら、その対象となる正確な成果物とバイト層に照合します。同じファイル群でも通常のtarとgzip包装ではハッシュが異なります。自分で計算したハッシュはバイトの同一性を記録するだけで、発行元の信頼性は証明しません。対象層が不明なら応答とオプションを残し、見かけ上一致するまで再圧縮することは避けます。
信頼できる候補でtar -tf download.binを調べ、最終終了を待ち、必要なファイル名、版、アーキテクチャと照合します。ファイルが必要なのに空リストなら不合格です。一部の名前を表示後にエラーになる場合も同様です。HTMLや破損データは正規経路から完全なコピーを取り直し、確認済みのtar・gzip層には適切なリーダーを選びます。その後に新しい場所へ展開して必要なファイルを試験します。新規ディレクトリは既存出力を守りますが、信頼できないアーカイブ用のサンドボックスではありません。
