本頁面說明 Cloud Storage 中的資源物件。如要瞭解 Cloud Storage 的運作方式，請參閱 Cloud Storage 產品總覽。
物件
物件指的是您儲存在 Cloud Storage 中的個別資料片段。值區中可建立的物件數量沒有限制。
物件分為兩大部分：物件資料和物件中繼資料。物件資料通常是您要儲存到 Cloud Storage 的檔案，且 Cloud Storage 完全不會解讀這類資料。物件中繼資料則有一系列的「名稱/值」組合，描述各項物件性質。
所有物件都會共用兩個重要的物件中繼資料：物件的名稱和產生編號。將物件新增至 Cloud Storage 值區時，您會指定物件名稱，Cloud Storage 會指派產生號。名稱和產生編號可用於唯一識別該值區中的物件。
您可以使用存取控制清單 (ACL) 控管個別物件的存取權。您也可以使用身分與存取權管理 (IAM) 來控管值區或受管理資料夾內所有物件的存取權。
命名注意事項
在 Cloud Storage 中命名物件時，請務必遵守特定規定，確保相容性並避免發生錯誤。這些規定適用於平面命名空間 bucket 和啟用階層命名空間的 bucket。
一般規定
- 物件名稱可包含按任何順序排列的有效 Unicode 字元。
- 物件名稱不得包含回車或換行字元。
- 請注意，透過 gcloud CLI 和 Google Cloud 控制台等介面傳送的反斜線會在幕後逸出。舉例來說，
\n會變為\\n。回車和換行字元限制僅適用於 ANSI 轉義字元。
- 請注意，透過 gcloud CLI 和 Google Cloud 控制台等介面傳送的反斜線會在幕後逸出。舉例來說，
- 物件名稱的開頭不得為
.well-known/acme-challenge/。 - 物件不能命名為
.或..。
命名空間專屬物件大小限制
物件名稱的大小上限會因值區的命名空間而異：
- 扁平命名空間值區中的物件名稱大小：如果採用 UTF-8 編碼，則為 1 到 1024 個位元組。
使用階層命名空間的值區中物件名稱大小：物件名稱可分為兩個部分：
- 資料夾名稱：物件所在資料夾的名稱。以 UTF-8 編碼時，資料夾名稱的大小上限為 512 個位元組。
- Base name：位於資料夾中的物件名稱。以 UTF-8 編碼時，基礎名稱的大小上限為 512 個位元組。
舉例來說，路徑
my-folder/my-object.txt代表物件，其基本名稱為my-object.txt，儲存在名為my-folder/的資料夾中。
建議
強烈建議您避免在物件名稱中使用下列項目：
- 在 XML 1.0 中無效的控制字元 (#x7F–#x84 及 #x86–#x9F)：這些字元會在您嘗試列出物件時造成 XML 清單問題。
#字元：Google Cloud CLI 指令會將結尾為 #<數字字串> 的物件名稱解讀為版本 ID，因此在物件名稱中加入#可能會導致系統無法使用 gcloud CLI 對這些版本化物件執行作業。[、]、*或?字元：Google Cloud CLI 指令會將這些字元解讀為萬用字元，因此在物件名稱中加入這些字元可能會導致無法執行萬用字元作業。此外，*和?並非 Windows 中檔案名稱的有效字元。:、"、<、>或|字元：這些字元不是 Windows 檔案名稱的有效字元，因此如果下載方法中包含重新命名產生的 Windows 檔案，則嘗試將名稱中使用這些字元的物件下載至 Windows 檔案時會失敗。/字元雖然不是 Windows 中檔案名稱的有效字元，但通常可用於模擬目錄結構的物件名稱；Google Cloud CLI 等工具在下載至 Windows 環境時，會自動將字元轉換為\。- 機密資訊或個人識別資訊 (PII)：物件名稱比物件資料更容易讓人看見。舉例來說，物件名稱會出現在物件的網址中，以及在列出值區中的物件時。
您無法直接重新命名現有物件，但可以間接重新命名物件，方法是複製及刪除原始物件。
物件命名空間
您可以在下列命名空間中儲存物件：
平面命名空間
使用扁平命名空間的值區會以扁平結構儲存物件，不含階層結構，也就是沒有目錄或資料夾。
為方便起見，系統會以幾種方式將物件視為彷彿儲存在資料夾階層中：
代管資料夾是一種 Cloud Storage 資源，可針對具有共用名稱前置字串的物件群組提供更廣泛的存取權。
Google Cloud console 和 Google Cloud CLI 等工具會將物件名稱中的斜線 (
/) 字元解讀為分隔符，以便模擬值區中的資料夾。
舉例來說，如果您在值區 your-bucket 中建立名為 folder1/file.txt 的物件，該物件的路徑為 your-bucket/folder1/file.txt，而 Cloud Storage 中並未儲存名為 folder1 的資料夾。從 Cloud Storage 的角度來看，字串 folder1/ 是物件名稱的一部分。
不過，由於物件名稱中含有 /，因此某些工具會實作資料夾的外觀。舉例來說，使用 Google Cloud 主控台時，您會前往物件 folder1/file1.txt，就好像物件名稱為 file1.txt，位於名為 folder1 的資料夾中。同樣地，您可以建立名為 folder1 的受管理的資料夾，然後 file1.txt 就會受此受管理資料夾設定的存取權政策所約束。
請注意，由於物件位於扁平命名空間，因此在列出多層級巢狀子目錄時，具有許多巢狀層級的目錄結構無法呈現與原生檔案系統一樣的效能。
請參閱「要求頻率最佳做法」，瞭解如何在大量上傳內容時避免使用依序排列的名稱，以便提升效能。以連續名稱上傳的物件可能會使用相同的後端伺服器，進而限制效能。
模擬資料夾
為協助您整理 Cloud Storage 值區中的物件，部分工具會模擬資料夾，而 JSON 和 XML API 都提供功能，可讓您設計自己的命名慣例來模擬資料夾。按一下下列分頁標籤，瞭解不同工具如何處理模擬資料夾。
控制台
Google Cloud 主控台會建立資料夾的視覺化表示法，類似於本機檔案瀏覽器。
在 Google Cloud 控制台中，您可以在值區中建立空資料夾，或上傳現有資料夾。
上傳現有資料夾時，資料夾名稱會成為資料夾中所有物件路徑的一部分。上傳內容也會包含任何子資料夾和其中的物件。
如要建立資料夾，請按照以下步驟進行：
- 在 Google Cloud 控制台，前往 Cloud Storage「Buckets」頁面。
前往值區。
按一下「建立資料夾」建立空白的新資料夾，或按一下「上傳資料夾」上傳現有資料夾。
指令列
Cloud Storage CLI 會使用各種規則模擬一般指令列目錄體驗。
為了營造階層式檔案樹狀結構的錯覺，gcloud CLI 會套用下列規則，判斷指令中的目的地網址應視為物件名稱或資料夾：
如果到達網頁網址以
/字元結尾，gcloud 指令列指令會將到達網頁網址視為資料夾。舉例來說，請考慮下列指令，其中your-file是檔案名稱：gcloud storage cp your-file gs://your-bucket/abc/
這個指令的結果是，Cloud Storage 會在值區
your-bucket中建立名為abc/your-file的物件。如果您使用
--recursive標記或**等萬用字元將多個來源檔案複製到目的地網址，gcloud CLI 會將目的地網址視為資料夾。舉例來說，請考慮下列指令，其中top-dir是包含file1和file2等檔案的資料夾：gcloud storage cp top-dir gs://your-bucket/abc --recursive
這項指令的結果是，Cloud Storage 會在值區
your-bucket中建立物件abc/top-dir/file1和abc/top-dir/file2。如果上述兩種規則都不符合，gcloud CLI 會檢查值區中的物件，判斷目的地網址是物件名稱還是資料夾。舉例來說，請考慮下列指令，其中
your-file是檔案名稱：gcloud storage cp your-file gs://your-bucket/abc
gcloud CLI 會使用
/分隔符和 prefix=abc，為your-bucket提出物件清單要求，以判斷your-bucket中是否有路徑以abc/開頭的物件。如果是這樣，gcloud CLI 會將abc/視為資料夾名稱，而指令會在值區your-bucket中建立物件abc/your-file。否則，gcloud CLI 會在your-bucket中建立abc物件。
這種以規則為基礎的方法與許多工具的運作方式不同，後者會建立 0 位元組物件，用於標示資料夾的存在狀態。gcloud CLI 可瞭解這類工具使用的幾項慣例，例如在 0 位元組物件的名稱結尾加上 _$folder$ 的慣例，但不需要這類標記物件實作與 UNIX 指令一致的命名行為。
除了這些規則之外，gcloud CLI 處理來源檔案的方式取決於您是否使用 --recursive 標記。如果您使用這個標記，gcloud CLI 會建構物件名稱，以便從遞迴處理點開始鏡像來源目錄結構。舉例來說，請考慮下列指令，其中 home/top-dir 是包含 file1 和 sub-dir/file2 等檔案的資料夾：
gcloud storage cp home/top-dir gs://your-bucket --recursive
這項指令的結果是，Cloud Storage 會在值區 your-bucket 中建立物件 top-dir/file1 和 top-dir/sub-dir/file2。
相反地，如果沒有 --recursive 旗標，即使因萬用字元 (例如 **) 而複製多個檔案，也會導致物件以來源檔案的最終路徑元件命名。舉例來說，假設 home/top-dir 是包含 file1 和 sub-dir/file2 等檔案的資料夾，則指令如下：
gcloud storage cp home/top-dir/** gs://your-bucket
在值區 your-bucket 中建立名為 file1 和 file2 的物件。
重試和命名
當 gcloud CLI 重新嘗試中斷的要求時，您可能會遇到以下問題：第一次嘗試會複製部分檔案，而後續嘗試會遇到已存在的目標資料夾，導致物件名稱不正確。
舉例來說，請考慮下列指令，其中 your-dir/ 底下有 dir1 和 dir2 等子資料夾，且兩個子資料夾都包含 abc 檔案：
gcloud storage cp ./your-dir gs://your-bucket/new --recursive
如果路徑 gs://your-bucket/new 尚不存在，gcloud CLI 會在第一次成功嘗試時建立下列物件：
new/dir1/abc new/dir2/abc
不過，在下次成功執行相同指令時，gcloud CLI 會建立下列物件：
new/your-dir/dir1/abc new/your-dir/dir2/abc
如要讓 gcloud CLI 每次都能正常運作，請嘗試下列操作：
在目的地網址的結尾加上斜線，讓 gcloud CLI 一律將其視為資料夾。
使用
gcloud storage rsync。由於rsync不會使用 Unix cp 定義的資料夾命名規則，因此無論目的地子資料夾是否存在，都會一律正常運作。
其他注意事項
您無法使用 gcloud CLI 建立零位元組物件，模擬空白資料夾。
下載至本機檔案系統時，gcloud CLI 會略過名稱結尾為
/字元的物件，因為 Linux 和 macOS 不允許建立結尾為/的檔案。如果您使用指令碼結合子路徑來建構檔案路徑，請注意，由於
/只是物件名稱中剛好出現的字元，CLI 會將gs://your-bucket/folder/解讀為與gs://your-bucket/folder不同的物件。
REST API
JSON API
JSON API 中不存在資料夾。您可以使用 prefix 和 delimiter 查詢參數，縮小所列物件的範圍，並模擬資料夾。
舉例來說，如要列出值區 my-bucket 中前置字串為 folder/subfolder/ 的所有物件，請使用以下網址提出物件清單要求：
"https://storage.googleapis.com/storage/v1/b/my-bucket/o?prefix=folder/subfolder/"
XML API
XML API 中沒有資料夾，您可以使用 prefix 和 delimiter 查詢參數，縮小列出的物件並模擬資料夾。
舉例來說，如要列出值區 my-bucket 中前置字串為 folder/subfolder/ 的所有物件，請使用以下網址提出物件清單要求：
"https://storage.googleapis.com/my-bucket?prefix=folder/subfolder/"
移除模擬資料夾
由於模擬資料夾並未實際存在，因此您通常可以透過重新命名物件來移除模擬資料夾，這樣模擬資料夾就不會再是物件名稱的一部分。舉例來說，如果您有名為 folder1/file 的物件，只要將物件重新命名為 file，即可移除模擬資料夾 folder1/。
不過，如果您使用的是會建立零位元物件做為資料夾預留位置的工具 (例如 Google Cloud 主控台)，則必須刪除零位元物件，才能移除資料夾。
階層命名空間
階層命名空間可讓您在 Cloud Storage 值區中，以檔案系統 (例如資料夾的階層) 來整理物件。階層式命名空間可提升效能，並協助您有效率地管理資料。如要進一步瞭解階層式命名空間和使用時機，請參閱「階層式命名空間」。
物件不變原則
物件是不會變更的，也就是說，物件一經上傳，在整個儲存週期中即完全不會變更。物件的儲存週期指的是從成功建立物件 (上傳) 到成功刪除物件之間的時期。在具體做法上，這表示您無法對物件做出累進式的變更，例如附加或截斷作業。不過，儲存在 Cloud Storage 的物件是可以替換的，而且會以整體化的方式進行；也就是在新的上傳作業完成之前，會將舊版本的物件提供給讀取者，完成上傳作業後，則將新版本的物件提供給讀取者。單一替換作業的意義其實是一個不可變物件的生命週期結束，以及另一個不可變物件生命週期的開始。
每次取代物件資料時，物件的產生編號都會變更。因此，產生編號可用來唯一識別不可變動的物件。
請注意，快速取代相同物件的限制為每秒一次。如果更換同一個物件的頻率過高，可能會導致 429 Too Many Requests 錯誤。您應設計應用程式，以便每秒最多上傳一次特定物件的資料，並使用指數輪詢重試策略處理偶發的 429 Too Many Requests 錯誤。