放置區塊清單
Put Block List 作業可透過指定組成 Blob 的區塊識別碼清單，將 Blob 寫入。 若要寫入為 Blob 的一部分，區塊必須在先前 的 Put Block 作業中成功寫入伺服器。
您可以只上傳已變更的區塊，然後一起認可新的和現有的區塊，以呼叫 Put Block List 更新 Blob。 您可以指定是否要認可已認可區塊清單或未認可的區塊清單，或認可最近上傳的區塊版本，無論其所屬列表為何。
要求
您可以建構 Put Block List 要求，如下所示。 建議您使用 HTTPS。 以您的記憶體帳戶名稱取代 myaccount ：
| PUT 方法要求 URI | HTTP 版本 |
|---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist |
HTTP/1.1 |
模擬記憶體服務要求
當您對模擬記憶體服務提出要求時，請將模擬器主機名和 Blob 服務埠指定為 127.0.0.1:10000，後面接著仿真的記憶體帳戶名稱：
| PUT 方法要求 URI | HTTP 版本 |
|---|---|
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist |
HTTP/1.1 |
記憶體模擬器僅支援最多 2 gibibytes (GiB) 的 Blob 大小。
如需詳細資訊，請參閱使用 Azure 模擬器進行本機 Azure 儲存體開發。
URI 參數
您可以在要求 URI 上指定下列其他參數：
| 參數 | 描述 |
|---|---|
timeout |
選擇性。
timeout 參數以秒為單位。 如需詳細資訊，請參閱 設定 Blob 服務作業的逾時。 |
要求標頭
下表說明必要的和選擇性要求標頭：
| 要求標頭 | 描述 |
|---|---|
Authorization |
必要。 指定授權配置、帳戶名稱和簽章。 如需詳細資訊，請參閱授權對 Azure 儲存體提出要求。 |
Date 或 x-ms-date |
必要。 指定要求的「國際標準時間」(UTC)。 如需詳細資訊，請參閱授權對 Azure 儲存體提出要求。 |
x-ms-version |
所有已授權要求都需要。 指定用於這個要求的作業版本。 如需詳細資訊，請參閱 Azure 儲存體服務的版本。 |
Content-Length |
必要。 要求內容的長度，以位元組為單位。 此標頭是指區塊清單的內容長度，而不是 Blob 本身的內容長度。 |
Content-MD5 |
選擇性。 要求內容的 MD5 雜湊。 在傳輸期間，此雜湊可用來驗證要求內容的完整性。 如果兩個哈希不相符，作業會失敗，錯誤碼為 400 (不正確的要求) 。 此標頭與要求內容相關聯，而不是與 Blob 本身的內容相關聯。 |
x-ms-content-crc64 |
選擇性。 要求內容的CRC64哈希。 在傳輸期間，此雜湊可用來驗證要求內容的完整性。 如果兩個哈希不相符，作業會失敗，錯誤碼為 400 (不正確的要求) 。 此標頭與要求內容相關聯，而不是與 Blob 本身的內容相關聯。 如果 Content-MD5 和 x-ms-content-crc64 標頭都存在，要求會失敗，並出現 400 (不正確的要求) 。 2019-02-02 版和更新版本支援此標頭。 |
x-ms-blob-cache-control |
選擇性。 設定 Blob 的快取控制。 如果指定這個屬性，則會以 Blob 儲存，並以讀取要求傳回。 如果未使用要求指定屬性，則會在要求成功時清除 Blob。 |
x-ms-blob-content-type |
選擇性。 設定 Blob 的內容類型。 如果指定此屬性，這個屬性會與 Blob 一起儲存，並以讀取要求傳回。 如果未指定內容類型，則會將其設定為預設類型，也就是 application/octet-stream。 |
x-ms-blob-content-encoding |
選擇性。 設定 Blob 的內容編碼。 如果指定此屬性，這個屬性會與 Blob 一起儲存，並以讀取要求傳回。 如果未使用要求指定屬性，則會在要求成功時清除 Blob。 |
x-ms-blob-content-language |
選擇性。 設定 Blob 的內容語言。 如果指定此屬性，這個屬性會與 Blob 一起儲存，並以讀取要求傳回。 如果未使用要求指定屬性，則會在要求成功時清除 Blob。 |
x-ms-blob-content-md5 |
選擇性。 Blob 內容的 MD5 雜湊。 不會驗證此哈希，因為每個區塊上傳時都會驗證個別區塊的哈希。 取得 Blob 作業會傳回 Content-MD5 回應標頭中這個標頭的值。 如果未使用要求指定這個屬性，則會在要求成功時清除 Blob。 |
x-ms-meta-name:value |
選擇性。 與 Blob 相關聯的使用者定義名稱/值組。 自 2009-09-19 版開始，元數據名稱必須遵守 C# 識別碼的命名規則。 |
x-ms-encryption-scope |
選擇性。 指出用來加密 Blob 的加密範圍。 此值必須符合加密範圍，該範圍是用來加密所有正在認可的區塊。 2019-02-02 版和更新版本支援此標頭。 |
x-ms-encryption-context |
選擇性。 預設值為 「Empty」。 如果設定值，則會設定 Blob 系統元數據。 最大長度-1024。 只有在帳戶啟用階層命名空間時才有效。 2021-08-06 版和更新版本支援此標頭。 |
x-ms-tags |
選擇性。 在 Blob 上設定指定的查詢字串編碼標記。 如需詳細資訊，請參閱一節。 2019-12-12 版和更新版本支援。 |
x-ms-lease-id:<ID> |
如果 Blob 具有作用中租用，則為必要項目。 若要在具有作用中租用的 Blob 執行這項作業，請指定此標頭的有效租用識別碼。 |
x-ms-client-request-id |
選擇性。 提供客戶端產生的不透明值，其中包含 1 kibibyte (KiB) 設定記憶體分析記錄時記錄在分析記錄中的字元限制。 強烈建議您使用此標頭，將用戶端活動與伺服器接收的要求相互關聯。 |
x-ms-blob-content-disposition |
選擇性。 設定 Blob 的 Content-Disposition 標頭。 適用於 2013-08-15 版和更新版本。Content-Disposition標頭欄位會傳達如何處理響應承載的其他資訊，並可用來附加其他元數據。 例如，如果設定為 attachment，這個標頭表示使用者代理程式不應該顯示回應，而是應該顯示 [另存新檔] 對話方塊。取得 Blob 和取得 Blob 屬性作業的回應包括內容處置標頭。 |
x-ms-access-tier |
選擇性。 版本 2018-11-09 和更新版本。 指出要設定在 Blob 上的層。 對於區塊 Blob，只有 2018-11-09 版和更新版本才支援 Blob 記憶體或一般用途 v2 帳戶。 區塊 Blob 層Hot的有效值為、 CoolCold和 Archive。
注意： Cold 2021-12-02 版和更新版本支持階層。 如需區塊 Blob 分層的詳細資訊 ，請參閱經常性存取、非經常性存取和封存儲存層。 |
x-ms-immutability-policy-until-date |
版本 2020-06-12 和更新版本。 指定要在 Blob 上設定的 保留日期 。 這是可以保護 Blob 免於修改或刪除的日期。 遵循RFC1123格式。 |
x-ms-immutability-policy-mode |
版本 2020-06-12 和更新版本。 指定要在 Blob 上設定的不變性原則模式。 有效值為 unlocked 和 locked。 值 unlocked 表示使用者可以藉由增加或減少 保留期限 來變更原則。 值 locked 表示禁止這些動作。 |
x-ms-legal-hold |
版本 2020-06-12 和更新版本。 指定要在 Blob 上設定的法律保留。 有效值為 true 和 false。 |
x-ms-expiry-option |
選擇性。 版本 2023-08-03 和更新版本。 指定要求的到期日選項，請參閱 ExpiryOption。 此標頭適用於已啟用階層命名空間的帳戶。 |
x-ms-expiry-time |
選擇性。 版本 2023-08-03 和更新版本。 指定 Blob 設定為到期的時間。 到期日的格式會根據 x-ms-expiry-option而有所不同。 如需詳細資訊，請參閱 ExpiryOption。 此標頭適用於已啟用階層命名空間的帳戶。 expiryTime如果要求未包含 新值，則 Blob 上已存在的 不會清除expiryTime |
唯有在符合指定條件的情況下，此作業也可支援使用條件式標頭以認可區塊清單。 如需詳細資訊，請參閱 指定 Blob 記憶體作業的條件式標頭。
要求標頭 (客戶提供的加密金鑰)
從 2019-02-02 版開始，您可以在要求上指定下列標頭，以使用客戶提供的密鑰來加密 Blob。 使用客戶提供的金鑰進行加密 (，而對應的標頭集) 是選擇性的。
| 要求標頭 | 描述 |
|---|---|
x-ms-encryption-key |
必要。 Base64 編碼的 AES-256 加密金鑰。 |
x-ms-encryption-key-sha256 |
必要。 加密金鑰的Base64編碼SHA256哈希。 |
x-ms-encryption-algorithm: AES256 |
必要。 指定要用於加密的演算法。 此標頭的值必須設定為 AES256。 |
要求本文
在要求本文中，您可以指定 Blob 記憶體應該檢查要求區塊的區塊清單。 如此一來，您可以插入、取代或刪除個別區塊來更新現有的 Blob，而不是重新載入整個 Blob。 上傳已變更的區塊或區塊之後，您可以認可新的 Blob 版本，方法是將新區塊與您想要保留的現有區塊一起認可。
若要更新 Blob，您可以指定服務在認可的區塊清單或未認可的區塊清單中尋找區塊識別碼，或先後在未認可及認可的區塊清單中尋找區塊識別碼。 若要指出要使用的方法，請指定要求主體內適當 XML 元素內的區塊標識碼，如下所示：
指定 元素內的
Committed區塊標識符，以指出 Blob 記憶體應該只搜尋具名區塊的認可區塊清單。 如果區塊在已認可的區塊清單中找不到，它不會寫入為 Blob 的一部分，而 Blob 記憶體會傳回狀態代碼 400 (不正確的要求) 。指定 元素內的
Uncommitted區塊標識符，以指出 Blob 記憶體應該只搜尋具名區塊的未認可區塊清單。 如果在未認可的區塊清單中找不到該區塊，它就不會寫入為 Blob 的一部分，而 Blob 記憶體會傳回狀態代碼 400 (不正確的要求) 。指定 元素內的
Latest區塊標識符，以指出 Blob 記憶體應該先搜尋未認可的區塊清單。 如果在未認可的清單中找到此區塊，此區塊會是最新版本，且應該寫入 Blob。 如果在未認可的清單中找不到該區塊，服務應該搜尋已認可的區塊清單，找出具名區塊，並在找到該區塊時將該區塊寫入 Blob。
此版本 Put Block List 的要求本文會使用下列 XML 格式：
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<Committed>first-base64-encoded-block-id</Committed>
<Uncommitted>second-base64-encoded-block-id</Uncommitted>
<Latest>third-base64-encoded-block-id</Latest>
...
</BlockList>
範例要求
為了示範 Put Block List，假設您已上傳三個您現在想要認可的區塊。 下列範例會透過指定列示的每個區塊所應使用的最新版本，認可新的 Blob。 您不需要確定是否已認可這些區塊。
Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1
Request Headers:
x-ms-date: Wed, 31 Aug 2011 00:17:43 GMT
x-ms-version: 2011-08-18
Content-Type: text/plain; charset=UTF-8
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=
Content-Length: 133
Request Body:
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<Latest>AAAAAA==</Latest>
<Latest>AQAAAA==</Latest>
<Latest>AZAAAA==</Latest>
</BlockList>
接下來，假設您想要更新 Blob。 新的 Blob 有下列變更：
識別碼為
ANAAAA==的新區塊。 必須先上傳此區塊，並呼叫 Put Block，並在未認可的區塊清單中顯示，直到呼叫Put Block List為止。識別碼為
AZAAAA==之區塊的更新版本。 必須先上傳此區塊，並呼叫 Put Block，並在未認可的區塊清單中顯示，直到呼叫Put Block List為止。移除識別碼為
AAAAAA==的區塊。 由於此區塊未包含在下一次對的Put Block List呼叫中，因此區塊會有效地從 Blob 中移除。
下列範例示範如何呼叫 Put Block List 以更新 Blob：
Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1
Request Headers:
x-ms-date: Wed, 31 Aug 2009 00:17:43 GMT
x-ms-version: 2011-08-18
Content-Type: text/plain; charset=UTF-8
x-ms-expiry-option: RelativeToNow
x-ms-expiry-time: 30000
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=
Content-Length: 133
Request Body:
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<Uncommitted>ANAAAA==</Uncommitted>
<Committed>AQAAAA==</Committed>
<Uncommitted>AZAAAA==</Uncommitted>
</BlockList>
回應
回應包括 HTTP 狀態碼和一組回應標頭。
狀態碼
成功的作業會傳回狀態碼「201 (已建立)」。
如需狀態代碼的詳細資訊，請參閱 狀態和錯誤碼。
回應標頭
這項作業的回應包括下列標頭。 回應也可能包括其他標準 HTTP 標頭。 所有標準標頭都符合 HTTP/1.1 通訊協議規格。
| 回應 | 說明 |
|---|---|
ETag |
實體標記包含用戶端使用 GET/PUT 要求標頭執行條件式 If-Match 作業所使用的值。 如果要求版本是 2011-08-18 或更新版本，ETag 值會以引號括住。 |
Last-Modified |
上次修改 Blob 的日期/時間。 日期格式會依照 RFC 1123。 如需詳細資訊，請參閱 代表標頭中的日期/時間值。 修改 Blob 的任何作業 (包括 Blob 更新的中繼資料或屬性)，都會變更 Blob 上次修改的時間。 |
Content-MD5 |
傳回 ，讓用戶端可以檢查訊息內容完整性。 此標頭是指此案例中要求 (的內容，也就是區塊清單，而不是 Blob 本身的內容) 。 針對 2019-02-02 版和更新版本，只有在要求具有此標頭時，才會傳回此標頭。 |
x-ms-content-crc64 |
針對 2019-02-02 版和更新版本，會傳回此標頭，讓用戶端可以檢查訊息內容完整性。 此標頭是指此案例中要求 (的內容，也就是區塊清單，而不是 Blob 本身的內容) 。 當要求中沒有標頭時 Content-md5 ，就會傳回此標頭。 |
x-ms-request-id |
可唯一識別提出的要求，而且您可以使用它對要求進行疑難解答。 如需詳細資訊，請參閱 針對 API 作業進行疑難解答。 |
x-ms-version |
用來執行要求的 Blob 記憶體版本。 針對針對 2009-09-19 版和更新版本提出的要求，會傳回此標頭。 |
Date |
服務所產生的 UTC 日期/時間值，指出何時起始回應。 |
x-ms-request-server-encrypted: true/false |
版本 2015-12-11 和更新版本。 如果指定的演算法成功加密要求的內容，此標頭的值會設定為 true 。 否則，會將值設定為 false。 |
x-ms-encryption-key-sha256 |
版本 2019-02-02 和更新版本。 如果要求使用客戶提供的金鑰進行加密，則會傳回此標頭，因此用戶端可以使用提供的金鑰，確保要求的內容已成功加密。 |
x-ms-encryption-scope |
版本 2019-02-02 和更新版本。 如果要求使用加密範圍，則會傳回此標頭，因此用戶端可以使用加密範圍來確保要求的內容已成功加密。 |
x-ms-version-id: <DateTime> |
版本 2019-12-12 和更新版本。 傳回可唯一識別 Blob 的不透明 DateTime 值。 此標頭的值表示 Blob 的版本，而且可用於後續要求來存取 Blob。 |
x-ms-client-request-id |
可用來針對要求及其對應的回應進行疑難解答。 如果此標頭存在於要求中，且值包含不超過 1,024 個可見的 ASCII 字元，則此標頭的值等於標頭的值 x-ms-client-request-id 。
x-ms-client-request-id如果標頭不存在於要求中，則它不會出現在回應中。 |
範例回應
Response Status:
HTTP/1.1 201 Created
Response Headers:
Transfer-Encoding: chunked
x-ms-content-crc64: 77uWZTolTHU
Date: Sun, 25 Sep 2011 00:17:44 GMT
ETag: “0x8CB172A360EC34B”
Last-Modified: Sun, 25 Sep 2011 00:17:43 GMT
x-ms-version: 2011-08-18
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-version-id: <DateTime>
授權
在 Azure 記憶體中呼叫任何數據存取作業時，需要授權。 您可以授權 Put Block List 作業，如下所述。
如果要求指定具有要求標頭的 x-ms-tags 標記，呼叫端必須符合 設定 Blob 標記 作業的授權需求。
重要
Microsoft 建議使用 Microsoft Entra ID 搭配受控識別來授權 Azure 記憶體的要求。 相較於共用密鑰授權，Microsoft Entra ID 提供更高的安全性和易於使用性。
Azure 記憶體支援使用 Microsoft Entra ID 來授權 Blob 數據的要求。 使用 Microsoft Entra ID，您可以使用 Azure 角色型存取控制 (Azure RBAC) 授與安全性主體的許可權。 安全性主體可能是使用者、群組、應用程式服務主體或 Azure 受控識別。 安全性主體會由 Microsoft Entra ID 進行驗證，以傳回 OAuth 2.0 令牌。 權杖接著可以用來授權對 Blob 服務的要求。
若要深入瞭解使用 Microsoft Entra ID 授權，請參閱使用 Microsoft Entra ID 授權 Blob 的存取權。
權限
以下是 Microsoft Entra 使用者、群組、受控識別或服務主體呼叫Put Block List作業所需的 RBAC 動作，以及包含此動作的最低特殊許可權 Azure RBAC 角色：
- Azure RBAC 動作：Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
- 最低特殊許可權的內建角色：記憶體 Blob 數據參與者
若要深入瞭解如何使用 Azure RBAC 指派角色，請參閱 指派 Azure 角色以存取 Blob 數據。
備註
Put Block List 作業會強制執行此順序，結合區塊以建立 Blob。
您可以在區塊清單中指定多次相同的區塊識別碼。 如果指定一次以上的區塊標識符，它代表最後認可 Blob 區塊清單中每個位置的位元組範圍。 如果區塊識別碼在清單中出現多次，則必須在相同的區塊清單中指定區塊識別碼的兩個執行個體。 換句話說，您必須在 Committed 項目、Uncommitted 項目或 Latest 項目中指定這兩個執行個體。
使用 Put Block List，您可以插入、更新或刪除個別區塊來修改現有的 Blob，而不需要再次上傳整個 Blob。 您可以指定目前認可的區塊清單和未認可的區塊清單中的區塊識別碼，以建立新的 Blob 或更新現有 Blob 的內容。 如此一來，您可以從未認可的區塊清單中指定幾個新區塊，以及來自已認可區塊清單的其餘區塊，這些區塊已是現有 Blob 的一部分，
如果在 Latest 項目中指定區塊識別碼，但認可及未認可的區塊清單中存在相同的區塊識別碼，Put Block List 會認可位於未認可的區塊清單中的區塊。 如果已認可的區塊標識碼存在於已認可的區塊清單中，但不存在於未認可的區塊清單中， Put Block List 請認可來自已認可區塊清單的區塊。
區塊 Blob 中的每個區塊都可以是不同的大小。 區塊 Blob 最多可以包含 50,000 個已認可的區塊。 可能與 Blob 相關聯的未認可區塊數目上限為 100,000。
下表描述依服務版本允許的區塊和 Blob 大小上限：
| 服務版本 | 透過) 的 Put Block 區塊大小上限 ( |
透過) 的 Put Block List Blob 大小上限 ( |
透過單一寫入作業的 Blob 大小上限， (透過 Put Blob) |
|---|---|---|---|
| 2019-12-12 版和更新版本 | 4,000 mebibytes (MiB) | 大約 190.7 tb (TiB) (4,000 MiB × 50,000 個區塊) | 5,000 MiB |
| 版本 2016-05-31 到 2019-07-07 | 100 MiB | 大約 4.75 TiB (100 MiB × 50,000 個區塊) | 256 MiB |
| 2016-05-31 之前的版本 | 4 MiB | 大約 195 GiB (4 MiB × 50,000 個區塊) | 64 MiB |
當您呼叫 Put Block List 更新現有的 Blob 時，會覆寫 Blob 的現有屬性和中繼資料。 但是，任何現有的快照集會保留在 Blob 中。 您可以使用此條件式標頭，僅在符合指定條件時，才執行作業。
Put Block List如果作業因為遺漏區塊而失敗，您需要上傳遺漏的區塊。
如果在上次成功Put Block作業之後的一周內沒有成功呼叫Put Block或 Put Block List Blob，則會垃圾收集任何未認可的區塊。 如果在 Blob 上呼叫 Put Blob ，則會垃圾收集任何未認可的區塊。
如果在標頭中 x-ms-tags 提供標籤，則必須進行查詢字串編碼。 標記索引鍵和值必須符合 命名和長度需求，如 中所 Set Blob Tags指定。 此外， x-ms-tags 標頭可以包含大小上限為 2 KiB 的標記。 如果需要更多標籤標，請使用 設定 Blob 標記 作業。
如果 Blob 有作用中的租用，客戶端必須在要求上指定有效的租用標識碼，才能認可區塊清單。 如果用戶端未指定租用標識碼或指定無效的租用標識符，Blob 記憶體會傳回狀態代碼 412 (前置條件失敗) 。 如果用戶端指定租用標識符，但 Blob 沒有作用中的租用，Blob 記憶體也會傳回狀態代碼 412 (前置條件失敗) 。 如果用戶端在尚未存在的 Blob 上指定租用標識符，Blob 記憶體會針對針對 2013-08-15 版或更新版本提出的要求，傳回狀態代碼 412 (前置條件失敗) 。 針對舊版，Blob 記憶體會傳回狀態代碼 201 (建立) 。
如果 Blob 有作用中租用，且您呼叫 Put Block List 更新 Blob，更新的 Blob 中會保留此租用。
Put Block List 只適用於區塊 Blob。 對分頁 Blob 呼叫 Put Block List 會導致狀態碼 400 (不正確的要求)。
覆寫封存的 Blob 失敗，如果未提供 x-ms-access-tier 標頭，則覆 hot 寫 或 cool Blob 會繼承舊 Blob 的層。
計費
定價要求可能源自使用 Blob 記憶體 API 的用戶端，無論是直接透過 Blob 記憶體 REST API，還是來自 Azure 記憶體用戶端連結庫。 這些要求會累算每個交易的費用。 交易類型會影響帳戶的收費方式。 例如，讀取交易會累算到與寫入交易不同的計費類別。 下表顯示根據記憶體帳戶類型的要求計費類別 Put Block List ：
| 作業 | 儲存體帳戶類型 | 計費類別 |
|---|---|---|
| 放置區塊清單 | 進階區塊 Blob 標準一般用途 v2 標準一般用途 v1 |
寫入作業 |
若要瞭解指定計費類別的定價，請參閱 Azure Blob 儲存體 定價。
另請參閱
瞭解區塊 Blob、附加 Blob 和分頁 Blob
授權對 Azure 記憶體的要求
狀態和錯誤碼
Blob 服務錯誤碼
設定 Blob 服務作業的逾時