共用方式為

從 URL 放置塊

該 Put Block From URL 作會創建一個新塊，作為 blob 的一部分提交，其中的內容是從 URL 讀取的。 此 API 從版本 2018-03-28 開始提供。

要求

您可以建構 Put Block From URL 要求，如下所示。 建議您使用 HTTPS。 以記憶體帳戶的名稱取代 myaccount：

PUT 方法請求 URI HTTP 版本
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=id HTTP/1.1 協定

仿真的記憶體服務要求

對類比記憶體服務發出請求時，請將模擬器主機名和 Blob 服務埠指定為 127.0.0.1:10000，後跟模擬的儲存帳戶名稱：

PUT 方法請求 URI HTTP 版本
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=block&blockid=id HTTP/1.1 協定

如需詳細資訊，請參閱 使用 Azurite 模擬器進行本機 Azure 記憶體開發。

URI 參數

參數 說明
blockid 必須的。 識別區塊的有效Base64字串值。 在編碼之前，字串的大小必須小於或等於64個字節。

對於指定的 blob，參數的 blockid 指定值的長度對於每個塊的大小必須相同。

注意：Base64 字串必須經過 URL 編碼。
timeout 選擇性。 timeout 參數是以秒為單位來表示。 如需詳細資訊，請參閱 設定 Blob 服務作業逾時。

請求標頭

下表說明必要和選擇性的要求標頭：

請求標頭 說明
Authorization 必須的。 指定授權配置、帳戶名稱和簽章。 如需詳細資訊，請參閱 授權對 Azure 記憶體的要求。
Date 或 x-ms-date 必須的。 指定要求的國際標準時間（UTC）。 如需詳細資訊，請參閱 授權對 Azure 記憶體的要求。
x-ms-version 所有已授權要求的必要專案。 指定要用於此要求的作業版本。 如需詳細資訊，請參閱 Azure 記憶體服務的版本設定。 對於 Put Block From URL，版本必須為 2018-03-28 或更高版本。
Content-Length 必須的。 指定要在要求主體中傳輸的位元組數目。 此標頭的值必須設置為 0。 當長度不為 0 時，作將失敗，狀態代碼為 400 （Bad Request）。
x-ms-copy-source:name 必須的。 指定源 blob 的 URL。 該值可以是長度最大為 2 KiB 的 URL，用於指定 blob。 該值應採用 URL 編碼，因為它將顯示在請求 URI 中。 源 blob 必須是公共的或通過共用訪問簽名授權的。 如果源 blob 是公共的，則無需授權即可執行該作。 以下是來源物件 URL 的一些範例：

- https://myaccount.blob.core.windows.net/mycontainer/myblob
- https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>
- https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime>
x-ms-copy-source-authorization: <scheme> <signature> 選擇性。 指定複製來源的授權配置和簽章。 如需詳細資訊，請參閱 授權對 Azure 記憶體的要求。

注意：Microsoft Entra 僅支援不記名方案。

注意：如果您的源物件是可公開訪問的，或者您的源對象位於存儲帳戶中，並且您使用的是傳入 x-ms-copy-source:name的 SAS 令牌，則不需要此標頭。

版本 2020-10-02 及更高版本支援此標頭。
x-ms-source-range 選擇性。 僅上傳指定範圍內的源 URL 中 blob 的位元組。 如果未指定此標頭，則整個源 blob 內容將作為單個塊上傳。 有關詳細資訊，請參閱 指定 Blob 服務作的範圍標頭。
x-ms-source-content-md5 選擇性。 來自 URI 的區塊內容的 MD5 哈希值。 此哈希用於在從 URI 傳輸數據期間驗證塊的完整性。 指定此標頭后，存儲服務會將從 copy-source 到達的內容的哈希值與此標頭值進行比較。

注意：此 MD5 哈希值不與 blob 一起存儲。

如果兩個哈希不匹配，則作將失敗，錯誤代碼為 400 （Bad Request）。
x-ms-source-content-crc64 選擇性。 來自 URI 的區塊內容的 CRC64 哈希值。 此哈希用於在從 URI 傳輸數據期間驗證塊的完整性。 指定此標頭后，存儲服務會將從 copy-source 到達的內容的哈希值與此標頭值進行比較。

注意：此 CRC64 哈希值不與 blob 一起存儲。

如果兩個哈希不匹配，則作將失敗，錯誤代碼為 400 （Bad Request）。

如果同時 x-ms-source-content-md5 存在和 x-ms-source-content-crc64 標頭，則請求將失敗，並顯示 400 （Bad Request）。

版本 2019-02-02 及更高版本支援此標頭。
x-ms-encryption-scope 選擇性。 指示用於加密源內容的加密範圍。 版本 2019-02-02 及更高版本支援此標頭。
x-ms-lease-id:<ID> 如果 blob 有有效的租約，則為必須。 若要對具有活動租約的 blob 執行此作，請為此標頭指定有效的租約 ID。
x-ms-client-request-id 選擇性。 提供客戶端產生的不透明值，其中包含設定記錄時記錄的 1-kibibyte （KiB） 字元限制。 強烈建議您使用此標頭，將用戶端活動與伺服器接收的要求相互關聯。 如需詳細資訊，請參閱 監視 Azure Blob 記憶體。
x-ms-file-request-intent 如果 x-ms-copy-source header 是 Azure 檔 URL，則 x-ms-copy-source-authorization 為 Required，並且 header 指定 OAuth 令牌。 可接受的值為 backup。 如果 Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action 或 Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action 包含在指派給使用 x-ms-copy-source-authorization 標頭授權的身分識別中，則此標頭指定應授與 Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action 或 Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action。 適用於版本 2025-07-05 及更高版本。

要求標頭（客戶提供的加密金鑰 ）

從版本 2019-02-02 開始，可以在請求中指定以下標頭，以使用客戶提供的密鑰加密 blob。 使用客戶提供的金鑰（和相應的標頭集）進行加密是可選的。

請求標頭 說明
x-ms-encryption-key 必須的。 Base64 編碼的 AES-256 加密金鑰。
x-ms-encryption-key-sha256 必須的。 加密金鑰的Base64編碼SHA256哈希。
x-ms-encryption-algorithm: AES256 必須的。 指定要用於加密的演算法。 此標頭的值必須設定為 AES256。

請求主體

沒有。

範例要求

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=AAAAAA%3D%3D HTTP/1.1  
  
Request Headers:  
x-ms-version: 2018-03-28  
x-ms-date: Sat, 31 Mar 2018 14:37:35 GMT    
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 0
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-499

回應

回應包含 HTTP 狀態代碼和一組響應標頭。

狀態代碼

成功的作業會傳回狀態代碼 201 （已建立）。

如您需狀態代碼的詳細資訊，請參閱 狀態和錯誤碼。

回應標頭

此作業的回應包含下列標頭。 回應也可能包含額外的標準 HTTP 標頭。 所有標準標頭都符合 HTTP/1.1 通訊協定規格，。

回應標頭 說明
Content-MD5 傳回 ，讓用戶端可以檢查訊息內容完整性。 此標頭的值由 Blob 儲存計算。 它不一定與要求標頭中指定的值相同。 對於版本 2019-02-02 及更高版本，僅當請求具有此標頭時，才會返回此標頭。
x-ms-content-crc64 對於版本 2019-02-02 及更高版本。 傳回 ，讓用戶端可以檢查訊息內容完整性。 此標頭的值由 Blob 儲存計算。 它不一定與請求標頭中指定的 value 相同。

當請求中不存在 header 時 x-ms-source-content-md5 返回。
x-ms-request-id 唯一識別已提出的要求，而且您可以使用它來針對要求進行疑難解答。 如需詳細資訊，請參閱 針對 API 作業進行疑難解答。
x-ms-version 用來執行要求的 Blob 記憶體版本。
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 和更新版本。 如果請求使用了加密範圍，則返回 Token，因此客戶端可以確保使用加密範圍成功加密請求的內容。
x-ms-client-request-id 可用來針對要求和對應的回應進行疑難解答。 如果此標頭存在於要求中，則這個標頭的值等於 x-ms-client-request-id 標頭的值，而且值包含不超過 1,024 個可見的 ASCII 字元。 如果要求中沒有 x-ms-client-request-id 標頭，它就不會出現在回應中。

範例回應

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sat, 31 Mar 2018 23:47:09 GMT  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

授權

在 Azure 記憶體中呼叫任何數據存取作業時，需要授權。 您可以授權 Put Block From URL 作業，如下所示。

這很重要

Microsoft建議搭配受控識別使用 Microsoft Entra ID 來授權對 Azure 記憶體的要求。 相較於共用密鑰授權，Microsoft Entra ID 提供更高的安全性和易於使用性。

Azure 儲存體支援使用 Microsoft Entra ID 來授權對 Blob 資料的要求。 使用 Microsoft Entra 識別符，您可以使用 Azure 角色型存取控制 （Azure RBAC） 將權限授與安全性主體。 安全性主體可能是使用者、群組、應用程式服務主體或 Azure 受控識別。 安全性主體會由 Microsoft Entra ID 驗證，以傳回 OAuth 2.0 令牌。 令牌接著可用來授權對 Blob 服務的要求。

若要深入瞭解使用 Microsoft Entra 識別符進行授權，請參閱 使用 Microsoft Entra ID授權 Blob 存取權。

權限

以下列出Microsoft Entra 使用者、群組、受控識別或服務主體呼叫 Put Block From URL 作業所需的 RBAC 動作，以及包含此動作的最低特殊許可權內建 Azure RBAC 角色：

若要深入瞭解如何使用 Azure RBAC 指派角色，請參閱 指派 Azure 角色以存取 blob 資料。

備註

Put Block From URL 上傳塊以將來包含在塊 blob 中。 塊 blob 最多可以包含 50,000 個塊。 每個塊的大小可以不同。 上傳的數據 Put Block From URL 塊的最大大小為 100 兆位元組 （MiB）。 要上傳更大的數據塊（最大 4000 MiB），請參閱 放置數據塊。

在 2020-10-02 版和更新版本中，複製作業的來源支援Microsoft Entra 授權。

一個 blob 在任何時候最多可以有 100,000 個未提交的塊。 如果超過此最大值，服務將返回狀態代碼 409 （RequestEntityTooLargeBlockCountExceedsLimit）。

下表描述了按服務版本允許的最大塊大小和 blob 大小：

服務版本 最大區塊大小（通過 Put Block From URL） 最大 blob 大小（通過 Put Block List） 通過單個寫入作（通過 Put Blob From URL） 實現的最大 blob 大小
版本 2020-04-08 及更高版本 4000 兆位元組 大約 190.7 TiB（4000 MiB × 50000 個數據塊） 5000 兆位元組
2020-04-08 之前的版本 100 MiB 大約 4.75 TiB（100 MiB × 50000 個數據塊） 256 MiB

上傳一組塊后，您可以通過調用 Put Block List 作從此集創建或更新 blob。 集中的每個塊都由該 blob 中唯一的塊ID標識。 塊ID的範圍限定為特定 blob，因此不同的 blob 可以具有具有相同 ID 的塊。

如果調用 Put Block From URL 尚不存在的 blob，則會創建一個內容長度為 0 的新塊 blob。 如果指定了選項，List Blobs則作將枚舉include=uncommittedblobs此 blob。 在調用 Put Block List 新 blob 之前，不會提交上傳的一個或多個塊。 以這種方式創建的 blob 將在伺服器上保留一周。 如果在該時間段內未向 blob 添加更多塊或提交的塊，則會對 blob 進行垃圾回收。

使用Put Block From URL作成功上傳的區塊使用 . Put Block List Before Put Block List 來提交新的或更新的 blob，則對 Get Blob 的任何調用都會返回 blob 內容，而不包含未提交的塊。

如果您上傳的塊與另一個尚未提交的塊具有相同的塊ID，則具有該ID的最後一個上傳塊將在下一次成功 Put Block List 作時提交。

之後 Put Block List ，塊清單中指定的所有未提交的塊都將作為新 blob 的一部分提交。 未在 blob 的塊清單中指定的任何未提交塊都會被垃圾回收並從 Blob 儲存中刪除。 如果在上次成功Put Block From URL作后的一周內沒有成功調用Put Block List同一 blob 或Put Block From URL對同一 blob 進行垃圾回收，則也會對任何未提交的塊進行垃圾回收。 如果在 blob 上調用 Put Blob ，則會對任何未提交的塊進行垃圾回收。

如果 blob 具有活動租約，則客戶端必須在請求中指定有效的租約 ID，才能將塊寫入 blob。 如果用戶端未指定租約ID或指定了無效的租約ID，則 Blob 儲存將返回狀態代碼 412（前提條件失敗）。 如果用戶端指定了租約ID，但 blob 沒有活動租約，則 Blob 存儲還會返回狀態代碼 412（前提條件失敗）。

對於指定的 blob，所有塊 ID 的長度必須相同。 如果上傳數據塊的塊ID長度與任何現有未提交數據塊的塊ID長度不同，則服務將返回錯誤響應代碼400（Bad Request）。

調用 Put Block From URL 不會更新現有 blob 的上次修改時間。

對頁 blob 調用 Put Block From URL 將返回錯誤。

調用 Put Block From URL 'archive' blob 會返回錯誤，而在 或 hot blob 上cool調用它不會更改 blob 層。

帳單管理

定價要求可能來自使用 Blob 記憶體 API 的用戶端，無論是直接透過 Blob 記憶體 REST API，還是來自 Azure 記憶體用戶端連結庫。 這些要求會依交易產生費用。 交易類型會影響帳戶的收費方式。 例如，讀取交易累算到與寫入交易不同的計費類別。 下表根據記憶體帳戶類型顯示 Put Block From URL 要求的計費類別：

行動 記憶體帳戶類型 計費類別
Put Block From URL（目標帳戶1） 進階區塊 Blob
標準一般用途 v2
標準一般用途 v1		 寫入作業
Put Block From URL（源帳戶2） 進階區塊 Blob
標準一般用途 v2
標準一般用途 v1		 讀取作業

1目標帳戶需要為啟動寫入的 1 個事務付費。
阿拉伯數位源帳戶對源物件的每個讀取請求都會產生一個事務。

此外，如果源帳戶和目標帳戶位於不同的區域（例如，美國北部和美國南部），則用於傳輸請求的頻寬將作為出口向源存儲帳戶收費。 同一區域內的帳戶之間的出口是免費的。

若要瞭解指定計費類別的定價，請參閱 Azure Blob 儲存定價。

另請參閱