放置封鎖來自URL
此 Put Block From URL 作業會建立新的區塊，以作為從URL讀取內容的 Blob 一部分進行認可。 此 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 |
如需詳細資訊，請參閱使用 Azure 模擬器進行本機 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 (不正確的要求) 。 |
x-ms-copy-source:name |
必要。 指定來源 Blob 的 URL。 此值可以是最多 2 個 kibibytes 的 URL， (KiB) 長度指定 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 僅支援持有人配置。 2020-10-02 版和更新版本支援此標頭。 |
x-ms-source-range |
選擇性。 只上傳指定範圍內來源 URL 中 Blob 的位元組。 如果未指定此標頭，則會將整個來源 Blob 內容上傳為單一區塊。 如需詳細資訊，請參閱 指定 Blob 服務作業的範圍標頭。 |
x-ms-source-content-md5 |
選擇性。 來自 URI 之區塊內容的 MD5 哈希。 此哈希是用來在從 URI 傳輸數據期間驗證區塊的完整性。 當指定此標頭時，記憶體服務會比較從複製來源到達的內容哈希與這個標頭值。 注意：此 MD5 哈希不會與 Blob 一起儲存。 如果兩個哈希不相符，作業會失敗，錯誤碼為 400 (不正確的要求) 。 |
x-ms-source-content-crc64 |
選擇性。 URI 中區塊內容的CRC64哈希。 此哈希是用來在從 URI 傳輸數據期間驗證區塊的完整性。 當指定此標頭時，記憶體服務會比較從複製來源到達的內容哈希與這個標頭值。 注意：此 CRC64 哈希不會與 Blob 一起儲存。 如果兩個哈希不相符，作業會失敗，錯誤碼為 400 (不正確的要求) 。 如果和 x-ms-source-content-md5x-ms-source-content-crc64 標頭都存在，要求會失敗，並出現 400 (不正確的要求) 。2019-02-02 版和更新版本支援此標頭。 |
x-ms-encryption-scope |
選擇性。 指出用來加密來源內容的加密範圍。 2019-02-02 版和更新版本支援此標頭。 |
x-ms-lease-id:<ID> |
如果 Blob 具有作用中租用，則為必要項目。 若要在具有作用中租用的 Blob 執行這項作業，請指定此標頭的有效租用識別碼。 |
x-ms-client-request-id |
選擇性。 提供客戶端產生的不透明值，其中包含設定記錄時記錄的 1 kibibyte (KiB) 字元限制。 強烈建議您使用此標頭，將用戶端活動與伺服器接收的要求相互關聯。 如需詳細資訊，請參閱監視 Azure 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。 |
要求本文
無。
範例要求
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 記憶體計算。 它不一定與要求標頭中指定的值相同。 當 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 和更新版本。 如果要求使用加密範圍，則傳回 ，因此用戶端可以使用加密範圍來確保要求的內容已成功加密。 |
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 ID，您可以使用 Azure 角色型存取控制 (Azure RBAC) 來授與安全性主體的許可權。 安全性主體可能是使用者、群組、應用程式服務主體或 Azure 受控識別。 安全性主體是由 Microsoft Entra ID 驗證，以傳回 OAuth 2.0 令牌。 權杖接著可以用來授權對 Blob 服務的要求。
若要深入瞭解使用 Microsoft Entra ID 授權，請參閱使用 Microsoft Entra ID 授權 Blob 的存取權。
權限
以下是 Microsoft Entra 使用者、群組、受控識別或服務主體呼叫Put Block From URL作業所需的 RBAC 動作，以及包含此動作的最低特殊許可權 Azure RBAC 角色：
- Azure RBAC 動作：Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
- 最低特殊許可權內建角色：記憶體 Blob 數據參與者
若要深入瞭解如何使用 Azure RBAC 指派角色，請參閱 指派 Azure 角色以存取 Blob 數據。
備註
Put Block From URL會上傳區塊，以供未來包含在區塊 Blob 中。 區塊 Blob 最多可以包含 50,000 個區塊。 每個區塊的大小可能不同。 上傳 Put Block From URL 的區塊大小上限為100個mebibytes (MiB) 。 若要上傳大型區塊 (最多 4,000 MiB) ，請參閱 Put Block。
在 2020-10-02 版和更新版本中，複製作業的來源支援 Microsoft Entra 授權。
Blob 隨時最多可以有 100,000 個未認可的區塊。 如果超過此最大值，服務會傳回狀態代碼 409 (RequestEntityTooLargeBlockCountExceedsLimit) 。
下表描述依服務版本允許的最大區塊和 Blob 大小：
| 服務版本 | 透過 Put Block From URL) 的區塊大小上限 ( |
透過) 的 Put Block List Blob 大小上限 ( |
透過單一寫入作業的 Blob 大小上限， (透過 Put Blob From URL) |
|---|---|---|---|
| 版本 2020-04-08 和更新版本 | 4,000 MiB | 大約 190.7 個區塊 (TiB) (4,000 MiB × 50,000 個區塊) | 5,000 MiB |
| 2020-04-08 之前的版本 | 100 MiB | 大約 4.75 TiB (100 MiB × 50,000 個區塊) | 256 MiB |
上傳一組區塊之後，您可以藉由呼叫 Put Block List 作業，從此集合建立或更新伺服器上的 Blob。 集合中的每個區塊都是由該 Blob 內唯一的區塊標識碼來識別。 區塊識別碼的範圍僅限於特定 Blob，因此不同的 Blob 可以有相同識別碼的區塊。
如果您在尚不存在的 Blob 上呼叫 Put Block From URL ，則會建立新的區塊 Blob，其內容長度為 0。 如果指定 include=uncommittedblobs 選項，List Blobs 作業會列舉此 Blob。 您必須在新的 Blob 上呼叫 Put Block List，才會認可您上傳的一個或多個區塊。 以這種方式建立的 Blob 會在伺服器上維護一周。 如果您尚未在該期間內將更多區塊或認可區塊新增至 Blob，則會垃圾收集 Blob。
作業成功上傳的 Put Block From URL 區塊，在認可 Put Block ListBlob 之前不會成為 Blob 的一部分。 呼叫 以認可新的或更新的 Blob 之前 Put Block List ， 任何對取得 Blob 的呼叫都會傳回 Blob 內容，而不需要包含未認可的區塊。
如果您上傳的區塊與尚未認可的另一個區塊具有相同的區塊標識碼，則會在下一次成功 Put Block List 作業上認可該標識符的最後一個已上傳區塊。
呼叫 Put Block List 之後，指定在區塊清單中的所有未認可區塊，都會認可為新 Blob 的一部分。 未在 Blob 區塊清單中指定的任何未認可的區塊，都會從 Blob 記憶體進行垃圾收集並移除。 如果最後一次成功Put Block From URL作業之後一周內沒有成功呼叫Put Block From URL或Put Block List相同的 Blob，任何未認可的區塊也會進行垃圾收集。 如果在 Blob 上呼叫 Put Blob ，則會垃圾收集任何未認可的區塊。
如果 Blob 具有作用中的租用，客戶端必須在要求上指定有效的租用標識碼，才能將區塊寫入 Blob。 如果用戶端未指定租用標識碼或指定無效的租用標識符，Blob 記憶體會傳回狀態代碼 412 (前置條件失敗) 。 如果用戶端指定租用標識符，但 Blob 沒有作用中的租用，Blob 記憶體也會傳回狀態代碼 412 (前置條件失敗) 。
對於指定的 Blob，所有區塊標識碼都必須是相同的長度。 如果區塊的長度與任何現有未認可區塊的區塊標識符不同，則服務會傳回錯誤回應碼 400 (不正確的要求) 。
呼叫 Put Block From URL 不會更新現有 Blob 的上次修改時間。
在分頁 Blob 上呼叫 Put Block From URL 會傳回錯誤。
在「封存」Blob 上呼叫Put Block From URL會傳回錯誤，並在 或 cool Blob 上hot呼叫它並不會變更 Blob 層。
計費
定價要求可能源自使用 Blob 記憶體 API 的用戶端，無論是直接透過 Blob 記憶體 REST API，還是來自 Azure 記憶體用戶端連結庫。 這些要求會累算每個交易的費用。 交易類型會影響帳戶的收費方式。 例如，讀取交易會累算到與寫入交易不同的計費類別。 下表顯示根據記憶體帳戶類型的要求計費類別 Put Block From URL ：
| 作業 | 儲存體帳戶類型 | 計費類別 |
|---|---|---|
| 將 [封鎖來源 URL] (目的地帳戶1) | 進階區塊 Blob 標準一般用途 v2 標準一般用途 v1 |
寫入作業 |
| 將 [封鎖來自 URL] (來源帳戶2) | 進階區塊 Blob 標準一般用途 v2 標準一般用途 v1 |
讀取作業 |
1目的地帳戶會支付一筆交易來起始寫入的費用。
2來源帳戶會對來源物件的每個讀取要求產生一筆交易。
此外，如果來源和目的地帳戶位於不同的區域 (例如美國北部和美國南部) ，則用來傳輸要求的頻寬會以輸出方式向來源記憶體帳戶收費。 相同地區的帳戶之間其輸出為免費。
若要瞭解指定計費類別的定價，請參閱 Azure Blob 儲存體 定價。