科技 · 實用指南
Gzip 顯示「unexpected end of file」？再次解壓前先證明位元組來源
EOF 可能來自下載截斷、串流中斷，也可能只是把分片誤當成完整封存。先保存並驗證原始位元組，再修復真正失敗的傳輸或拼接環節。
「gzip: unexpected end of file」只說明解壓器遇到位元組流提前結束，並不直接說明原因。更換 tar 參數反覆執行無法補回從未到達的資料；即使已解出少量檔案，也不能證明部分封存可信。
我們以 151,552 位元組的確定性負載建立一個 gzip 成員。完整的 514 位元組成員可解壓；刪除末尾八位元組 trailer 後出現 EOFError。第一個 257 位元組分片也出現 EOFError，第二個分片單獨讀取則不是 gzip 標頭。依序拼回兩個分片後，514 位元組檔案的 SHA-256 與原始成員完全一致，解壓負載雜湊也一致。
這個受控測試用來支持診斷順序，不是復原保證。未知檔案還可能中段損壞、由變動的 URL 傳回、產生未完成、由多個合法成員串接，或外層另有格式。請保存失敗位元組，並盡量取得發佈者提供的校驗和或大小。
重試前凍結失敗證據
把檔案複製到新的證據路徑，記錄位元組數、SHA-256、來源 URL 或物件鍵、回應標頭、下載時間和全部分片名稱。不要用第二次下載覆蓋它，否則可能抹去揭露傳輸不穩定的差異。
對副本執行 gzip -t，並保存結束碼與標準錯誤。此測試會讀完整個 gzip 流並執行完整性檢查，不會把「解出部分檔案」誤當成功。處理不可信輸入時，應在隔離目錄中測試並避免自動解壓。
區分下載、串流、分片集與上游輸出
下載時應將收到的大小與雜湊和發佈者的簽名或認證中繼資料比較。檢查代理是否回傳 HTML、範圍請求是否提前結束，或續傳是否附加不相容位元組。重下載到新檔名，先比對雜湊再替換。
串流場景要同時記錄傳輸完成狀態和解壓錯誤。Node.js 需求案例在讀取同一 S3 物件時於不同位置失敗；這代表要查串流完成、重試與物件身分，而不是證明大型 gzip 天生無效。
僅依驗證清單拼接位元組分片
若製作者明確使用 split，先盤點每個分片、預期大小或雜湊，以及排序規則。Unix & Linux 案例說明 part.000 為何在 gzip 完成前結束：這些片段屬於同一檔案，必須依序拼接後再測試。
把拼接結果寫入新檔，不要覆蓋分片。先比對可信校驗和，再對該檔執行 gzip -t，最後執行真正的消費程式。gzip 通過只證明 gzip 完整性，並不證明所有預期應用記錄或 tar 成員都存在。
缺少可信來源位元組時應停止
不要因為已出現部分檔案就接受封存，不要刪除位元組直到測試通過，也不要屏蔽解壓錯誤。這些做法會把可見失敗變成靜默遺漏。應向發佈者或上游工作取得新的不可變物件與校驗和。
修復後記錄舊新雜湊、傳輸或拼接變更、完整 gzip 測試與下游驗證。保留未解決缺口；若沒有權威來源檔案，就應把輸出標示為部分結果，而非完整結果。
