次の方法で共有


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 Storage 開発に Azurite エミュレーターを使用する」を参照してください。

URI パラメーター

パラメーター 説明
blockid 必須。 ブロックを識別する有効な Base64 文字列値。 エンコードする前に、文字列のサイズが 64 バイト以下である必要があります。

指定した BLOB の場合、 blockid パラメーターに指定した値の長さは、各ブロックで同じサイズである必要があります。

: Base64 文字列は URL エンコードする必要があります。
timeout 任意。 timeout パラメーターは秒単位で表されます。 詳細については、「BLOB サービス操作のタイムアウトを設定する」を参照してください。

要求ヘッダー

必須の要求ヘッダーと省略可能な要求ヘッダーを次の表に示します。

リクエストヘッダー 説明
Authorization 必須。 承認スキーム、アカウント名、署名を指定します。 詳細については、「Azure Storageへの要求を承認する」を参照してください。
Date または x-ms-date 必須。 要求の世界協定時刻 (UTC) を指定します。 詳細については、「Azure Storageへの要求を承認する」を参照してください。
x-ms-version すべての承認された要求に必要です。 この要求に使用する操作のバージョンを指定します。 詳細については、「Azure Storage サービスのバージョン管理」を参照してください。 Put Block From URLの場合、バージョンは 2018-03-28 以降である必要があります。
Content-Length 必須。 要求本文で送信されるバイト数を指定します。 このヘッダーの値は 0 に設定する必要があります。 長さが 0 でない場合、操作は状態コード 400 (Bad Request) で失敗します。
x-ms-copy-source:name 必須。 ソース BLOB の URL を指定します。 値には、BLOB を指定する最大 2 キビバイト (KiB) の長さの URL を指定できます。 値は、要求 URI に表示されるように URL エンコードする必要があります。 ソース 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 Storageへの要求を承認する」を参照してください。

: Microsoft Entra では、ベアラー スキームのみがサポートされています。

: ソース オブジェクトがパブリックにアクセス可能な場合、またはソース オブジェクトがストレージ アカウントにあり、 x-ms-copy-source:name渡される SAS トークンを使用している場合、このヘッダーは必要ありません。

このヘッダーは、バージョン 2020-10-02 以降でサポートされています。
x-ms-source-range 任意。 指定した範囲内のソース URL 内の BLOB のバイトのみをアップロードします。 このヘッダーが指定されていない場合、ソース BLOB の内容全体が 1 つのブロックとしてアップロードされます。 詳細については、「 BLOB サービス操作の範囲ヘッダーの指定」を参照してください。
x-ms-source-content-md5 任意。 URI からのブロック コンテンツの MD5 ハッシュ。 このハッシュは、URI からのデータの転送中にブロックの整合性を確認するために使用されます。 このヘッダーを指定すると、ストレージ サービスは、コピー元から到着したコンテンツのハッシュとこのヘッダー値を比較します。

: この MD5 ハッシュは BLOB と共に保存されません。

2 つのハッシュが一致しない場合、操作はエラー コード 400 (Bad Request) で失敗します。
x-ms-source-content-crc64 任意。 URI からのブロック コンテンツの CRC64 ハッシュ。 このハッシュは、URI からのデータの転送中にブロックの整合性を確認するために使用されます。 このヘッダーを指定すると、ストレージ サービスは、コピー元から到着したコンテンツのハッシュとこのヘッダー値を比較します。

: この CRC64 ハッシュは BLOB と共に保存されません。

2 つのハッシュが一致しない場合、操作はエラー コード 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) 文字制限を持つクライアント生成の不透明な値を提供します。 このヘッダーを使用して、クライアント側のアクティビティと、サーバーが受信する要求を関連付けすることを強くお勧めします。 詳細については、「Monitor Azure Blob Storage」を参照してください。
x-ms-file-request-intent x-ms-copy-sourceヘッダーが Azure ファイルの URL で、x-ms-copy-source-authorizationヘッダーが OAuth トークンを指定している場合は必須です。 許容される値は backupです。 このヘッダーは、Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action または Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action が、x-ms-copy-source-authorization ヘッダーを使用して承認された ID に割り当てられた RBAC ポリシーに含まれている場合に付与されるように指定します。 バージョン 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 (Created) が返されます。

状態コードの詳細については、「状態コードとエラー コードを参照してください。

応答ヘッダー

この操作の応答には、次のヘッダーが含まれます。 応答には、追加の標準 HTTP ヘッダーも含まれる場合があります。 すべての標準ヘッダーは、HTTP/1.1 プロトコル仕様に準拠しています。

応答ヘッダー 説明
Content-MD5 クライアントがメッセージ コンテンツの整合性を確認できるように返されます。 このヘッダーの値は、Blob Storage によって計算されます。 要求ヘッダーで指定されている値と必ずしも同じではありません。 バージョン 2019-02-02 以降の場合、このヘッダーは要求にこのヘッダーがある場合にのみ返されます。
x-ms-content-crc64 バージョン 2019-02-02 以降の場合。 クライアントがメッセージ コンテンツの整合性を確認できるように返されます。 このヘッダーの値は、Blob Storage によって計算されます。 これは、要求ヘッダーで指定されている値と必ずしも同じではありません。

ヘッダー x-ms-source-content-md5 要求に存在しない場合に返されます。
x-ms-request-id 作成された要求を一意に識別し、それを使用して要求のトラブルシューティングを行うことができます。 詳細については、「API 操作のトラブルシューティング」を参照してください。
x-ms-version 要求の実行に使用された Blob Storage のバージョン。
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 要求と対応する応答のトラブルシューティングに使用できます。 このヘッダーの値は、要求に存在し、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: Sat, 31 Mar 2018 23:47:09 GMT  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  

認証

Azure Storage でデータ アクセス操作を呼び出す場合は、承認が必要です。 次の説明に従って、Put Block From URL 操作を承認できます。

Von Bedeutung

Microsoft では、マネージド ID で Microsoft Entra ID を使用して、Azure Storage への要求を承認することをお勧めします。 Microsoft Entra ID は、共有キーの承認と比較して優れたセキュリティと使いやすさを提供します。

Azure Storage では、Microsoft Entra ID を使用して BLOB データへの要求を認可できます。 Microsoft Entra ID を使用すると、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、セキュリティ プリンシパルにアクセス許可を付与できます。 セキュリティ プリンシパルには、ユーザー、グループ、アプリケーション サービス プリンシパル、または Azure マネージド ID を指定できます。 セキュリティ プリンシパルは、Microsoft Entra ID によって認証され、OAuth 2.0 トークンを返します。 その後、そのトークンを、Blob service に対する要求を認可するために使用できます。

Microsoft Entra ID を使用した承認の詳細については、「Microsoft Entra IDを使用して BLOB へのアクセスを承認する」を参照してください。

権限

Microsoft Entra ユーザー、グループ、マネージド ID、またはサービス プリンシパルが Put Block From URL 操作を呼び出すために必要な RBAC アクションと、このアクションを含む最小特権の組み込み Azure RBAC ロールを次に示します。

  • Azure RBAC アクション: Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write を
  • 最小特権組み込みロール: ストレージ BLOB データ共同作成者

Azure RBAC を使用したロールの割り当ての詳細については、「BLOB データにアクセスするための Azure ロールの割り当て」を参照してください。

注釈

Put Block From URL ブロック BLOB に将来含めるためにブロックをアップロードします。 ブロック BLOB には、最大 50,000 個のブロックを含めることができます。 各ブロックは異なるサイズにすることができます。 Put Block From URL でアップロードされるブロックの最大サイズは 100 メビバイト (MiB) です。 より大きなブロック (最大 4,000 MiB) をアップロードするには、「 ブロックの挿入」を参照してください。

バージョン 2020-10-02 以降では、コピー操作のソースに対して Microsoft Entra 承認がサポートされています。

BLOB には、いつでも最大 100,000 個のコミットされていないブロックを含めることができます。 この最大値を超えた場合、サービスは状態コード 409 (RequestEntityTooLargeBlockCountExceedsLimit) を返します。

次の表では、サービスのバージョンごとに許可されるブロックと BLOB の最大サイズについて説明します。

サービスのバージョン 最大ブロックサイズ( Put Block From URL経由) 最大 BLOB サイズ ( Put Block List 経由) 1 回の書き込み操作による最大 BLOB サイズ ( Put Blob From URL 経由)
バージョン 2020-04-08 以降 4,000 MiB 約190.7テビバイト(TiB)(4,000MiB×50,000ブロック) 5,000 MiB
2020-04-08 より前のバージョン 100 MiBの 約 4.75 TiB (100 MiB × 50,000 ブロック) 256 MiB

一連のブロックをアップロードしたら、このセットからサーバー上の BLOB を作成または更新するには、 Put Block List 操作を呼び出します。 セット内の各ブロックは、その BLOB 内で一意のブロック ID によって識別されます。 ブロック ID のスコープは特定の BLOB であるため、異なる BLOB が同じ ID のブロックを持つことができます。

まだ存在しない BLOB で Put Block From URL を呼び出すと、コンテンツの長さが 0 の新しいブロック BLOB が作成されます。 この BLOB は、include=uncommittedblobs オプションが指定されている場合、List Blobs 操作によって列挙されます。 アップロードしたブロックは、新しい BLOB で Put Block List を呼び出すまでコミットされません。 この方法で作成された BLOB は、サーバー上で 1 週間保持されます。 その期間内にブロックまたはコミットされたブロックを BLOB に追加しなかった場合、BLOB はガベージ コレクションされます。

Put Block From URL操作で正常にアップロードされたブロックは、Put Block List でコミットされるまで BLOB の一部になりません。 新しい BLOB または更新された BLOB をコミットするために Put Block List が呼び出される前に、 Get Blob を呼び出すと、コミットされていないブロックを含めずに BLOB の内容が返されます。

まだコミットされていない別のブロックと同じブロック ID を持つブロックをアップロードすると、その ID を持つ最後にアップロードされたブロックが、次に成功した Put Block List 操作でコミットされます。

Put Block List が呼び出されると、ブロック リストで指定されたコミットされていないすべてのブロックが新しい BLOB の一部としてコミットされます。 BLOB のブロック リストに指定されていないコミットされていないブロックは、ガベージ コレクションされ、Blob Storage から削除されます。 コミットされていないブロックは、最後に成功した Put Block From URL 操作から 1 週間以内に同じ BLOB で Put Block From URL または Put Block List への正常な呼び出しがない場合にも、ガベージ コレクションされます。 BLOB で Put Blob が呼び出されると、コミットされていないブロックはガベージ コレクションされます。

BLOB にアクティブなリースがある場合、クライアントは要求で有効なリース ID を指定して、BLOB にブロックを書き込む必要があります。 クライアントがリース ID を指定しない場合、または無効なリース ID を指定した場合、Blob Storage はステータス コード 412 (前提条件に失敗しました) を返します。 クライアントがリース ID を指定しているが、BLOB にアクティブなリースがない場合、Blob Storage はステータス コード 412 (前提条件に失敗しました) も返します。

指定した BLOB の場合、すべてのブロック ID は同じ長さである必要があります。 コミットされていない既存のブロックのブロック ID と異なる長さのブロック ID でブロックがアップロードされた場合、サービスはエラー応答コード 400 (Bad Request) を返します。

Put Block From URLを呼び出しても、既存の BLOB の最終変更時刻は更新されません。

ページ BLOB で Put Block From URL を呼び出すと、エラーが返されます。

"アーカイブ" BLOB で Put Block From URL を呼び出すとエラーが返され、 hot BLOB または cool BLOB で呼び出しても BLOB 層は変更されません。

請求書

価格要求は、Blob Storage API を使用するクライアントから、Blob Storage REST API を介して直接、または Azure Storage クライアント ライブラリから送信できます。 これらの要求には、トランザクションあたりの料金が発生します。 トランザクションの種類は、アカウントの課金方法に影響します。 たとえば、読み取りトランザクションは、書き込みトランザクションとは異なる課金カテゴリに発生します。 次の表に、ストレージ アカウントの種類に基づく Put Block From URL 要求の課金カテゴリを示します。

オペレーション ストレージ アカウントの種類 課金カテゴリ
Put Block From URL(宛先アカウント1) Premium ブロック BLOB
Standard 汎用 v2
Standard 汎用 v1
書き込み操作
URL からブロックを設定 (ソース アカウント2) Premium ブロック BLOB
Standard 汎用 v2
Standard 汎用 v1
読み取り操作

1宛先アカウントは、書き込みを開始するための 1 つのトランザクションに対して課金されます。
2ソースアカウントでは、ソースオブジェクトへの読み取りリクエストごとに 1 つのトランザクションが発生します。

さらに、ソース アカウントと宛先アカウントが異なるリージョン (米国北部と米国南部など) に存在する場合、要求の転送に使用される帯域幅は、エグレスとしてソース ストレージ アカウントに課金されます。 同じリージョン内のアカウント間のエグレスは無料です。

指定した課金カテゴリの価格については、「 Azure Blob Storage の価格」を参照してください。

こちらも参照ください