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 計算的值相符時，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 在上傳完成後，但在執行驗證前，可能會遭到中斷，導致無效物件留在原處。上傳單一檔案至 Cloud Storage 時，您可以使用伺服器端驗證 (使用 --content-md5 旗標時會發生) 避免這些問題。
rsync 的變更偵測
gcloud storage rsync 指令也可以使用 MD5 或 CRC32C 總和檢查碼，判斷來源和目的地所找到的物件版本是否有差異。指令會在下列情況下比較總和檢查碼：
來源和目的地都是雲端值區，且物件在兩個值區中都有 MD5 或 CRC32C 總和檢查碼。
來源或目標中都沒有物件的檔案修改時間 (
mtime)。
如果相關物件在來源和目的地中都有 mtime 值 (例如來源和目的地都是檔案系統)，rsync 指令會比較物件的大小和 mtime，而不會使用檢查和修復碼。同樣地，如果來源是雲端儲存格，而目的地是本機檔案系統，rsync 指令會使用為來源物件建立的時間來取代 mtime，且不會使用總和檢查碼。
如果 mtime 和總和檢查碼皆不可用，rsync 只會在判斷物件的來源版本和目的地版本是否有變更時，比較檔案大小。舉例來說，如果您將複合物件與不支援 CRC32C 的雲端服務供應商中的物件進行比較，則 mtime 和總和檢查碼都無法使用，因為複合物件沒有 MD5 總和檢查碼。