科技 · 實用指南
下載的tar.gz顯示「非gzip格式」？先核對HTTP解碼與儲存位元組
下載成功可能存下網頁、已解碼的tar或gzip檔案。保留回應，確認位元組層與預期內容，再調整解壓參數。
.tar.gz檔名不能證明curl實際存了什麼。它可能是登入頁、經HTTP解碼後的一般tar、壓縮檔或損壞資料。gzip錯誤只說明目前步驟遇到格式不符，不能單憑這一句確定原因。
必須分別回答三個問題：請求是否完成、儲存的壓縮串流是否完整、必要檔案是否存在。HTTP狀態、Content-Encoding、熟悉的檔頭與解壓工具看似成功，都只回答其中一部分。
1. 先保留一次回應，再換解壓工具
記錄準確URL、curl版本和原始選項，尤其是--compressed、-i、重新導向及管線。對照測試請在自己擁有的新建空目錄執行，先替換範例URL，標頭另存，並等候curl最終狀態。首位-q忽略預設curl設定檔；本次刻意不加--compressed。下列為Linux shell命令，並非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、清單空白。因此零結束碼不能單獨證明內容正確；這不代表所有tar版本的行為。
4. 驗證預期檔案，再決定修復方式
發布者提供校驗和或簽章時，須針對它所描述的準確檔案及位元組層驗證。一般tar及其gzip包裝即使表示相同檔案，雜湊也不同。自行計算雜湊只能記錄位元組身分，不能證明發布者可信。若不清楚預期校驗和對應哪一層，應保留回應與選項，而非重新壓縮直到看似符合。
對可信候選檢查tar -tf download.bin，等候最終結束，再比對必要檔名、目標版本及架構。預期有檔案卻清單空白不能接受；印出部分名稱後發生錯誤也不能接受。HTML或損壞資料應重新取得獲授權的完整副本；已驗證的tar或gzip層則選相應讀取方式。之後才解壓到新目錄並測試必要檔案。新目錄可保護既有輸出，但不是不可信壓縮檔的安全沙箱。
