Cloud Storage 建議您驗證傳入及傳出值區的資料。本頁說明使用 CRC32C 或 MD5 總和檢查碼執行驗證的最佳做法，並說明 gcloud storage rsync 指令使用的變更偵測演算法。
使用雜湊值防止資料損毀
在 Cloud 中，有多種原因可能造成資料在上傳或下載過程中毀損：
- 用戶端、伺服器電腦或路由器的路徑上發生記憶體錯誤
- 軟體錯誤 (例如：在客戶使用的程式庫中)
- 長時間上傳檔案時，來源檔案的變更
Cloud Storage 支援兩種雜湊，可用於檢查資料完整性：CRC32C 和 MD5。建議使用 CRC32C 驗證方法執行完整性檢查。偏好採用 MD5 的客戶可使用這種雜湊，只是 MD5 雜湊不支援所有物件。
用戶端驗證
對下載的資料即時進行雜湊運算，並將結果與伺服器提供的檢查碼進行比較，即可執行下載項目的完整性檢查。但請注意，伺服器提供的總和檢查碼是以儲存在 Cloud Storage 中的完整物件為準，因此無法使用伺服器提供的雜湊值驗證下列類型的下載內容：
經過解壓縮轉碼的下載作業，因為伺服器提供的檢查碼代表壓縮狀態的物件，而提供的資料已移除壓縮，因此雜湊值不同。
只包含部分物件資料的回應，會在發出
range要求時發生。Cloud Storage 建議您只針對上次收到偏移之後重新啟動下載完整物件的情況使用範圍要求，因為這樣您才可以在整個下載作業完成時計算和驗證總和檢查碼。
如果可以使用檢查碼驗證下載內容，請捨棄雜湊值錯誤的下載資料，並使用建議的重試邏輯重試要求。
伺服器端驗證
Cloud Storage 會在下列情況執行伺服器端驗證：
在 Cloud Storage 中執行複製或重寫要求時。
在上傳要求中提供物件的預期 MD5 或 CRC32C 雜湊。只有在您提供的雜湊值與 Cloud Storage 計算出的值相符時，系統才會建立物件。如果不相符，系統會拒絕要求並傳回
BadRequestException: 400錯誤。在適用的 JSON API 要求中，您會將總和檢查碼提供給物件資源。
在適用的 XML API 要求中，您可以使用
x-goog-hash標頭提供檢查碼。XML API 也接受標準 HTTP Content-MD5 標頭 (請參閱規格)。或者，您也可以對上傳內容執行用戶端驗證，做法是發出對上傳物件中繼資料的要求，然後比較上傳物件的雜湊值與預期值，並在出現不吻合時刪除物件。如果上傳開始時不知道物件的 MD5 或 CRC32C 雜湊值，這個方法就很有用。
如果是平行複合上傳，使用者應對每個組成元件的上傳執行完整性檢查，接著在組合要求中使用先決條件，來防止發生競爭狀況。Compose 要求不會執行伺服器端驗證，因此如果使用者想執行端對端完整性檢查，就必須對新的複合物件執行用戶端驗證。
Google Cloud CLI 驗證
使用 Google Cloud CLI 時，系統會驗證複製到 Cloud Storage 值區或從該值區複製的資料。這適用於 cp、mv 和 rsync 指令。如果來源資料的檢查碼與目的地資料的檢查碼不符，gcloud CLI 會刪除無效副本並輸出警告訊息。但這種情況極少發生。萬一發生了，您可以再試一次。
這項自動驗證會在物件完成後進行，因此無效物件會顯示 1 到 3 秒，隨後才會遭到識別和刪除。此外，gcloud CLI 可能會在上傳完成後中斷，但驗證程序尚未執行，導致無效物件留在原處。使用 --content-md5 旗標時，系統會進行伺服器端驗證，因此上傳單一檔案至 Cloud Storage 時，可避免發生這些問題。
變更「rsync」的偵測設定
gcloud storage rsync 指令也可以使用 MD5 或 CRC32C 總和檢查碼，判斷來源和目的地物件版本之間是否有差異。在下列情況下，指令會比較總和檢查碼：
來源和目的地都是雲端值區，且物件在兩個值區中都有 MD5 或 CRC32C 總和檢查碼。
物件在來源或目的地中都沒有檔案修改時間 (
mtime)。
如果相關物件在來源和目的地都有 mtime 值 (例如來源和目的地都是檔案系統)，rsync 指令會比較物件的大小和 mtime，而不是使用檢查碼。同樣地，如果來源是雲端 bucket，目的地是本機檔案系統，rsync 指令會使用來源物件的建立時間做為 mtime 的替代值，且指令不會使用總和檢查碼。
如果 mtime 和總和檢查碼都無法使用，rsync 只會比較檔案大小，判斷物件的來源版本和目的地版本之間是否有變更。舉例來說，比較複合物件與不支援 CRC32C 的雲端供應商物件時，由於複合物件沒有 MD5 總和檢查碼，因此無法使用 mtime 或總和檢查碼。