物件中繼資料

管理

本頁討論與物件一起儲存在 Cloud Storage 的常用中繼資料欄位。

簡介

儲存在 Cloud Storage 的物件具有相關聯的「中繼資料」。中繼資料可用來識別物件的屬性，還可以指定存取物件時應該如何處理物件。中繼資料以「鍵:值組合」的形式存在。舉例來說，物件的儲存空間級別由中繼資料項目「storageClass:STANDARD」表示。其中 storageClass 就是中繼資料的「鍵」，而所有的物件都會有這樣一個相關聯的鍵。STANDARD 則指定這個特定物件具有的「值」，這個值會隨物件的不同而異。

中繼資料的易變性也不盡相同；有些中繼資料可以隨時編輯，有些中繼資料只能在建立物件時設定，而有些中繼資料只能查看。舉例來說，您可以隨時編輯 Cache-Control 中繼資料的值，但只能在建立或重寫物件時指派 storageClass 中繼資料，也不能直接編輯 generation 中繼資料的值，不過 generation 的值會在取代物件時改變。

可編輯的中繼資料

使用者可變更的物件中繼資料有兩種：

  • 固定鍵中繼資料：雖已設定鍵、但可指定值的中繼資料。

  • 自訂中繼資料：藉由同時指定鍵及與此鍵關聯的值而新增的中繼資料。

編輯中繼資料時，通常應避免使用非 ASCII 字元，因為這些字元不適用於 XML API 所使用的 HTTP 標頭。

固定鍵中繼資料

您可以編輯物件的下列中繼資料，但必須有對應的足夠權限：

存取權控管中繼資料

Cloud Storage 使用身分與存取權管理 (IAM) 和存取控制清單 (ACL) 來控管物件的存取權。請透過這些連結，瞭解這些存取權控管方法及關聯的中繼資料。

快取控制

Cache-Control 中繼資料可指定從 Cloud Storage 提供資料方法的兩種思考方向：是否可快取資料，以及是否可轉換資料。

快取資料

Cache-Control 中繼資料可讓您控制是否允許快取功能快取您的物件，以及允許多久的時間，如此可用於滿足日後的要求。快取可包含瀏覽器和網際網路快取，以及 Cloud Storage 內建快取。

如果適用物件沒有 Cache-Control 中繼資料項目，Cloud Storage 會使用下列預設值：

如果您允許快取，下載內容可能會繼續接收物件的較舊版本，即使較新版本已經上傳。這是因為較舊的版本會在快取中保持「新鮮」一段時間 (取決於 max-age)。此外，由於可在網際網路上的各種位置快取物件，因此沒有方法可強制快取過的物件在全球過期。也就是說，如果撤銷物件的公開存取權，系統仍可從快取提供該物件，具體情況取決於上次存取時間和 Cache-Control 設定。舉例來說，如果物件是透過 public, max-age=3600 的 Cache-Control 提供服務，則該物件可能會在快取中保留一小時。如要避免提供公開可讀物件的快取版本，請在物件上設定 Cache-Control: no-store。

如要進一步控管快取行為，可以在值區前方設定 Cloud CDN。

轉換資料

Cache-Control 中繼資料也可讓您在儲存物件時提供物件，而不套用任何轉換至資料，例如：針對不相容的用戶端移除 gzip content-encoding。如要提供原狀的物件，請設定 Cache-Control:no-transform。

Content-Disposition

Content-Disposition 中繼資料指定轉換中資料的呈現資訊。設定 Content-Disposition 可讓您控制內容的呈現風格，例如決定是否應自動顯示附件，還是應該要求使用者執行某些動作來開啟該附件。如需 Content-Disposition 規格，請參閱 https://datatracker.ietf.org/doc/html/rfc6266。

Content-Encoding

Content-Encoding 中繼資料可用來表示物件已經過壓縮，同時仍保有物件的基礎 Content-Type。例如，以 gzip 壓縮的文字檔，可在 Content-Type 中指出它是文字檔，以及在 Content-Encoding 中指出它是使用 gzip 壓縮的。您應確保檔案確實使用指定的 Content-Encoding 進行壓縮，再更新檔案，否則嘗試下載物件時可能會發生非預期的行為。詳情請參閱轉碼頁面。

對於可壓縮的內容如文字等，使用 Content-Encoding: gzip 可節省網路和儲存費用，並可改善內容提供效能。但是對於本身已經壓縮的內容，如封存和許多媒體格式等，如將其他壓縮層級套用到這類內容並在 Content-Encoding 中繼資料中標示，通常不利於物件大小和效能，因此應該避免。

Content-Language

Content-Language 中繼資料表示物件主要用於哪些語言。如需這類中繼資料的典型值，請參閱 ISO 639-1 語言代碼。

Cloud Storage 支援長度最多 100 個字元的 Content-Language 值。

Content-Type

最常設定的中繼資料是 Content-Type (也稱為媒體類型)，可讓瀏覽器正確轉譯物件。所有物件都會在自己的 Content-Type 中繼資料指定值，但這個值無需與物件的基礎類型相符。舉例來說，如果上傳者未指定 Content-Type，且系統無法判斷，就會根據上傳物件的方式，將其設為 application/octet-stream 或 application/x-www-form-urlencoded。如需有效內容類型的清單，請參閱「IANA Media Types」(IANA 媒體類型) 頁面。

自訂時間

Custom-Time 中繼資料是使用者指定的時間和日期，以 RFC 3339 格式 YYYY-MM-DD'T'HH:MM:SS.SS'Z' 或 YYYY-MM-DD'T'HH:MM:SS'Z' 表示 (毫秒為零時)。通常會設定這項中繼資料，以便在物件生命週期管理中使用 DaysSinceCustomTime 條件。

物件設定 Custom-Time 後，就無法移除。此外，Custom-Time 的值不得減少。也就是說，您無法將 Custom-Time 設為早於現有 Custom-Time 的日期/時間。不過，您可以透過重新寫入物件，有效移除或重設 Custom-Time。

物件訴訟保留

使用中繼資料標記設定物件訴訟保留，避免物件遭到刪除或取代。詳情請參閱「物件訴訟保留」頁面。

保留設定

如果物件有保留設定，則該設定會定義日期和時間，在此之前物件無法刪除或取代。詳情請參閱物件保留鎖定。

自訂中繼資料

自訂中繼資料是指您定義鍵和值的中繼資料。如要建立自訂中繼資料，請指定鍵和值。建立自訂中繼資料 key:value 組合後，您可以刪除鍵或變更值。

自訂中繼資料有大小限制，且會產生儲存費用。

查看及編輯中繼資料頁面提供設定自訂中繼資料的相關資訊。

x-goog-meta- 前置字元

XML API 會使用要求標頭設定及擷取物件中繼資料，而 JSON API 則允許在可繼續上傳的最終要求中，使用要求標頭設定自訂中繼資料。為清楚區分自訂中繼資料標頭與標準要求標頭，這兩個 API 都會在自訂中繼資料標頭前面加上 x-goog-meta-。

不能編輯的中繼資料

有些中繼資料無法直接編輯，這種中繼資料會在建立或重寫物件時設定。在建立或重寫物件的過程中，您可以設定這類的中繼資料，例如：物件的儲存空間級別或客戶自行管理的加密金鑰。有些中繼資料會自動新增且只能查看，像是物件的產生編號或建立時間。

產生和中繼資料版本編號

每個 Cloud Storage 物件都有數值 generation 屬性和數值 metageneration 屬性，可做為中繼資料的一部分，用來唯一識別物件：

屬性 說明
generation 識別物件版本，無論值區是否使用物件版本管理功能，每個物件都會有這個 ID。
  • 物件版本的 generation 值永遠不會變更。同名的新物件可以取代現有物件，但新物件一律會指派不同的 generation。
  • 我們無法保證後續版本的產生編號會增加，但可確保每個新版本的產生編號都不重複。
  • 即使是同一個值區內的物件，不相關物件的產生編號也毫無關聯。
metageneration 指出中繼資料版本，並在更新特定 generation 的中繼資料時逐次增加。
  • 物件每次產生新的 generation，metageneration 都會從 1 開始。
  • 因此，如果沒有 generation 屬性，metageneration 屬性就毫無意義；兩者必須搭配使用。比較兩個物件版本的中繼資料生成世代毫無意義。

在下列情況中，會使用 generation 和 metageneration 屬性：

檢查碼機制

檢查碼是從相關聯物件的資料計算而來的中繼資料。校驗碼用於驗證物件資料是否已損毀。Cloud Storage 物件有數個檢查碼中繼資料欄位。

CRC32C

所有 Cloud Storage 物件都有 CRC32C 雜湊碼。用於計算 CRC32C 的程式庫包括：

Base64 編碼的 CRC32C 採用大端序的位元組順序。

MD5

如果 Cloud Storage 物件符合下列條件，就會有 MD5 雜湊：

如果要求中含有 Content-MD5 標頭，Cloud Storage 會比較提供的 MD5 雜湊與上傳物件的計算雜湊，驗證物件資料的完整性。如果雜湊值不相符，系統就會拒絕要求。

MD5 雜湊只適用於整個物件，無法檢查部分下載內容的完整性。為確保資料完整性驗證的可靠性，建議使用 CRC32C 總和檢查碼，因為每個物件都會有這個總和檢查碼。

ETag

所有 Cloud Storage 物件都有 ETag。不過，與 JSON API 相比，從 XML API 要求相同物件時，該物件可能會有不同的 ETag 值。在大多數情況下，使用者不應採用 ETag 中使用的值，但只要基礎資料或中繼資料改變時，ETag 也會按照規格跟著改變。

如果符合下列所有條件，物件的 ETag 標頭會傳回物件的 MD5 值：

修改時間

每個 Cloud Storage 物件都有 updated 屬性，用來指出物件中繼資料上次修改的時間。updated 時間最初會設為物件的建立時間，之後只要物件的任何中繼資料有變更，這個時間就會隨之變更。包括要求者所做的變更 (例如修改自訂中繼資料)，以及 Cloud Storage 代表要求者所做的變更 (例如根據物件生命週期設定變更儲存空間級別)。

後續步驟