gzip 壓縮檔轉碼

本頁討論如何將檔案轉成「gzip」壓縮狀態與解壓縮,內容包括轉碼概述、處理關聯中繼資料的最佳做法,以及 Cloud Storage 的壓縮檔行為。

轉碼和 gzip

gzip 是一種資料壓縮格式,一般用來減少檔案大小。這可以讓檔案的傳輸比未壓縮時快,且佔用的儲存空間較少。壓縮檔案有助減少成本和傳輸時間。Cloud Storage 的「轉碼」功能會自動變更檔案壓縮,再將檔案提供給要求者。當轉碼功能使檔案變成 gzip 壓縮時,這個檔案會被視為「壓縮」,反之,當產生的檔案不再是 gzip 壓縮狀態,就會被視為「解壓縮」。Cloud Storage 支援解壓縮格式的轉碼。

解壓縮轉碼

如果檔案在 Cloud Storage 中存成 gzip 壓縮物件,這些檔案可以自動解壓縮,再傳送給要求者,進而產生「身分編碼的」 (也就是未壓縮的) 檔案。如此一來,不僅將物件儲存在 Cloud Storage 中的成本會降低,還能將本身未經壓縮的檔案提供給要求者,對於像是提供檔案給客戶的情況,此功能非常實用。

物件必須滿足兩項條件,才能使用解壓縮轉碼:

  1. 檔案以 gzip 壓縮格式儲存於 Cloud Storage。

  2. 關聯的中繼資料包括 Content-Encoding: gzip

當物件滿足這兩項條件,那麼就會在接獲要求時進行解壓縮轉碼,此時,也會提供無 Content-Encoding 標頭的物件。如果您「要」滿足這兩項條件的物件以壓縮狀態提供的話 (例如為了降低輸出成本或時間),有兩種方法可阻止解壓縮轉碼發生:

  • 如果物件的要求包括 Accept-Encoding: gzip 標頭,則針對此特定要求,物件會以原狀提供,並加上 Content-Encoding: gzip 回應標頭。

  • 如果物件的 Cache-Control 中繼資料欄位設為 no-transform,則在所有後續要求中,物件會以壓縮物件的形式提供,無論是否有 Accept-Encoding 要求標頭都是如此。

Content-Type 和 Content-Encoding 的比較

關於 Content-TypeContent-Encoding 與轉碼之間的關係,有幾個行為應該注意。這兩者都是隨物件一起儲存的中繼資料,請參閱查看及編輯物件中繼資料一文,瞭解如何將中繼資料新增到物件的逐步操作說明。

Content-Type 應包含在所有上傳作業中,並指示上傳中物件的類型。例如:

Content-Type: text/plain

表示上傳的物件是純文字檔案。雖然不會執行任何檢查來確保指定的 Content-Type 符合所上傳物件的真正性質,但類型指定錯誤的話,絕對會造成要求者收到非預期中的內容,並且可能導致不希望發生的行為。

Content-Encoding 是選用項目,可視需要包含在壓縮檔案的上傳作業。例如:

Content-Encoding: gzip

表示上傳的物件為 gzip 壓縮檔。至於 Content-Type,不會執行任何檢查來確保指定的 Content-Encoding 會確實套用至上傳的物件,且物件指定錯誤的話,可能會導致後續的下載要求發生不希望發生的行為。

建議做法

  • 上傳 gzip 壓縮物件時,建議您在設定中繼資料時,同時指定 Content-TypeContent-Encoding。例如,對於壓縮的純文字檔案,可指定:

    Content-Type: text/plain
    Content-Encoding: gzip
    

    這樣可提供最多物件狀態相關資訊給存取物件的任何人,此外,也會讓物件可以在之後下載時進行解壓縮轉碼,讓用戶端應用程式正確處理 Content-Type 的語意。

  • 或者,您可以在上傳物件時設定 Content-Type 來指示壓縮,並且不使用任何 Content-Encoding。例如:

    Content-Type: application/gzip
    

    不過,在這個情況下,對於這個物件,只能馬上知道它是 gzip 壓縮,對於物件類型將一無所悉。而且,物件也會無法進行解壓縮轉碼。

不建議的做法

  • 雖然可以這樣做,但不建議上傳 gzip 壓縮檔時,將檔案的壓縮性質刪去。例如,對於 gzip 壓縮純文字檔案,應避免只設定 Content-Type: text/plain 而已,以免傳送給要求者的物件狀態遭到扭曲。

  • 同理,物件不可在省略 Content-Type 的情況下上傳,即使已包含 Content-Encoding,否則可能導致將 Content-Type 設為預設值,但根據上傳的執行方式,可能會造成要求被拒。

錯誤的做法

  • 不應設定中繼資料,重複回報物件的壓縮。

    Content-Type: application/gzip
    Content-Encoding: gzip
    

    這是指重複上傳早已是 gzip 壓縮的 gzip 壓縮物件,但其實通常不該如此 (如果您「確實」需要重複壓縮檔案,請參閱以下的對壓縮物件使用 gzip 一節)。當解壓縮轉碼發生在回報錯誤的物件時,該物件會以身分編碼的狀態提供,但要求者會「認為」收到的物件仍有關聯的壓縮層。對物件解壓縮將會失敗。

  • 同理,非 gzip 壓縮檔上傳時不應包含 Content-Encoding: gzip。否則,物件會「看起來似乎」可以進行轉碼,但要求物件時,轉碼作業會失敗。

對壓縮物件使用 gzip

有些物件如許多影片、音訊和影像檔等,本身不會提到 gzip 檔案,但其實已經過壓縮。對這類的物件使用 gzip,幾乎毫無助益:幾乎在所有情況下,這樣做會使物件因 gzip 作業負擔而變大。因此,一般不建議對壓縮內容使用 gzip,以免可能導致不希望發生的行為。

例如,雖然 Cloud Storage 允許上傳和儲存「重複壓縮」物件 (也就是物件已經過 gzip 壓縮,但又包含本身已壓縮的 Content-Type),但不允許提供重複壓縮狀態的物件,除非 Cache-Control 中繼資料包含 no-transform。相反的,它會移除外部 gzip 壓縮層,捨棄 Content-Encoding 回應標頭,然後提供結果物件。即使要求包含 Accept-Encoding: gzip 也不例外。

使用 Range 標頭

轉碼發生時,如果物件的要求包含 Range 標頭,則會在不發出通知的情況下略過該標頭。也就是說,要求提供局部內容是無法實現的,而回應會改為提供整個要求的物件。這種行為的發生,是因為如果沒有先將整個壓縮檔解壓縮,就無法選取其中的範圍;為了達成對提供檔案其中一部分的要求,而將整個可能很大的檔案解壓縮,等於用不妥當的方式來利用資源。您應注意這種行為,並且避免使用 Range 標頭來進行轉碼功能,因為這會依傳送整個物件來計費,而非只用傳送要求的範圍來計費。如要進一步瞭解使用 Range 標頭發出要求所允許的回應行為,請參閱規格

如果需要使用 Range 標頭來發出要求,請確保不會對所要求的物件進行轉碼。您可以在上傳物件時選擇適當的屬性來達成這項目標。例如,使用 Content-Type: application/gzip 但不使用 Content-Encoding 對物件提出範圍要求,將會按照這樣的要求來執行。

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Cloud Storage
需要協助嗎?請前往我們的支援網頁