Put Block List

[アーティクル]
03/16/2023

Put Block List 操作は、BLOB を構成するブロック ID の一覧を指定することによって 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 ギビバイト (GiB) の BLOB サイズのみがサポートされます。

詳細については、ローカルでの Azure Storage の開発に Azurite エミュレーターを使用する方法に関するページを参照してください。

URI パラメーター

次の追加パラメーターを要求 URI に指定できます。

パラメーター	説明
`timeout`	省略可能。 `timeout` パラメーターは、秒単位で表されます。詳細については、「 BLOB サービス操作のタイムアウトを設定する」を参照してください。

要求ヘッダー

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

要求ヘッダー	説明
`Authorization`	必須。承認スキーム、アカウント名、署名を指定します。詳細については、「Azure Storage への要求を承認する」をご覧ください。
`Date` または `x-ms-date`	必須。要求に対して協定世界時 (UTC) を指定します。詳細については、「Azure Storage への要求を承認する」をご覧ください。
`x-ms-version`	すべての承認された要求に必要です。この要求に使用する操作のバージョンを指定します。詳細については、「Azure Storage サービスのバージョン管理」を参照してください。
`Content-Length`	必須。要求コンテンツの長さ (バイト単位)。このヘッダーは、BLOB 自体ではなく、ブロックのリストのコンテンツ長を参照します。
`Content-MD5`	省略可能。要求のコンテンツの MD5 ハッシュ。このハッシュは転送時の要求コンテンツの整合性を確認するために使用します。 2 つのハッシュが一致しない場合、操作はエラーコード 400 (無効な要求) で失敗します。このヘッダーは、BLOB 自体のコンテンツではなく、要求コンテンツに関連付けられます。
`x-ms-content-crc64`	省略可能。要求コンテンツの CRC64 ハッシュ。このハッシュは転送時の要求コンテンツの整合性を確認するために使用します。 2 つのハッシュが一致しない場合、操作はエラーコード 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`	省略可能。既定値は "空" です。値が設定されている場合は、BLOB システムのメタデータが設定されます。最大長-1024。アカウントに対して階層型名前空間が有効になっている場合にのみ有効です。このヘッダーは、バージョン 2021-08-06 以降でサポートされています。
`x-ms-tags`	省略可能。指定したクエリ文字列でエンコードされたタグを BLOB に設定します。詳細については、「解説」セクションを参照してください。バージョン 2019-12-12 以降でサポートされています。
`x-ms-lease-id:<ID>`	BLOB にアクティブなリースが存在する場合は必須です。アクティブなリースが存在する BLOB に対してこの操作を実行するには、このヘッダーに有効なリース ID を指定します。
`x-ms-client-request-id`	省略可能。ストレージ分析ログの構成時に分析ログに記録される 1 kibibyte (KiB) 文字制限を使用して、クライアントによって生成された不透明な値を提供します。このヘッダーを使用して、クライアント側のアクティビティとサーバーが受信する要求を関連付けるよう強くお勧めします。
`x-ms-blob-content-disposition`	省略可能。 BLOB の `Content-Disposition` ヘッダーを設定します。バージョン 2013-08-15 以降で使用できます。ヘッダーフィールドは `Content-Disposition` 、応答ペイロードの処理方法に関する追加情報を伝達し、追加のメタデータをアタッチするために使用できます。たとえば、がに `attachment`設定されている場合、このヘッダーは、ユーザーエージェントが応答を表示せず、代わりに [名前を付けて保存] ダイアログを表示する必要があることを示します。 GET BLOB および Get Blob Properties 操作からの応答には、content-disposition ヘッダーが含まれます。
`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 Storage 操作の条件付きヘッダーを指定する」を参照してください。

要求ヘッダー (顧客指定の暗号化キー)

バージョン 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 Storage が要求されたブロックに対してチェックする必要があるブロックリストを指定できます。この方法では、BLOB 全体を再アップロードするのではなく、個々のブロックを挿入、置換、または削除することで、既存の BLOB を更新できます。変更されたブロックまたはブロックをアップロードしたら、保持する既存のブロックと共に新しいブロックをコミットすることで、新しいバージョンの BLOB をコミットできます。

BLOB を更新する場合、ブロック ID をコミット後のブロック一覧から検索するか、コミット前のブロック一覧から検索するか、またはコミット前のブロック一覧を検索した後でコミット後のブロック一覧から検索するかを指定できます。使用する方法を指定するには、要求本文内の適切な XML 要素内にあるブロック ID を次のように指定します。

Blob Storage が名前付きブロックの Committed コミット済みブロックリストのみを検索する必要があることを示すには、要素内のブロック ID を指定します。コミットされたブロックリストにブロックが見つからない場合、ブロックは BLOB の一部として書き込まれず、Blob Storage は状態コード 400 (Bad Request) を返します。
Blob Storage が名前付きブロックの Uncommitted コミットされていないブロックリストのみを検索する必要があることを示すには、要素内のブロック ID を指定します。コミットされていないブロックリストにブロックが見つからない場合、ブロックは BLOB の一部として書き込まれず、Blob Storage は状態コード 400 (無効な要求) を返します。
Blob Storage が最初にコミットされていないブロックリストを Latest 検索する必要があることを示すために、要素内のブロック ID を指定します。対象ブロックがコミット前のブロック一覧に見つかった場合、そのブロックのバージョンが最新であり、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すために、コミットする 3 つのブロックをアップロードしたとします。次の例では、一覧の各ブロックの最新バージョンを使用するように指定して、新規 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 には、次の変更があります。

ID ANAAAA== の新規ブロック。このブロックは、最初に Put Block の呼び出しでアップロードする必要があり、の呼び出しまでコミットされていないブロックリストに Put Block List表示されます。
ID AZAAAA== のブロックの更新。このブロックは、最初に Put Block の呼び出しでアップロードする必要があり、の呼び出しまでコミットされていないブロックリストに Put Block List表示されます。
ID 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>

Response

応答には、HTTP 状態コードおよび一連の応答ヘッダーが含まれています。

status code

操作が正常に終了すると、状態コード 201 (Created) が返されます。

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

応答ヘッダー

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

Response	説明
`ETag`	エンティティタグに含まれる値は、クライアントが `If-Match` 要求ヘッダーを使用して条件付き `GET/PUT` 操作を実行するときに使用できます。要求バージョンが 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 Storage のバージョン。このヘッダーは、バージョン 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 Storage でデータアクセス操作を呼び出す場合は、承認が必要です。以下で説明するように、操作を Put Block List 承認できます。

要求で要求ヘッダーを持つタグが指定されている x-ms-tags 場合、呼び出し元は BLOB タグの設定操作の承認要件を満たす必要があります。

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

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

Shared Access Signature (SAS) は、ストレージアカウント内のリソースへのセキュリティで保護された委任されたアクセスを提供します。 SAS を使用すると、クライアントがデータにアクセスする方法をきめ細かく制御できます。クライアントがアクセスできるリソース、それらのリソースに対するアクセス許可、および SAS が有効な期間を指定できます。

この操作では Put Block List 、ユーザー委任 SAS、サービス SAS、アカウント SAS の 3 種類の共有アクセス署名がサポートされています。

セキュリティのベストプラクティスとして、ストレージアカウントキーではなくMicrosoft Entra資格情報を使用することをお勧めします。これは、より簡単に侵害される可能性があります。アプリケーション設計で共有アクセス署名が必要な場合は、可能であれば、Microsoft Entra資格情報を使用してユーザー委任 SAS を作成します。

ストレージアカウントに対して共有キーアクセスが許可されていない場合、サービス SAS トークンまたはアカウント SAS トークンは、Blob Storage への要求では許可されません。詳細については、「共有キーの禁止が SAS トークンにどのように影響するかを理解する」を参照してください。

ユーザー委任 SAS

ユーザー委任 SAS は、Microsoft Entra資格情報と、SAS に対して指定されたアクセス許可によっても保護されます。

Put Block Listコンテナーまたは BLOB リソースに委任された SAS トークンを使用して操作を呼び出すには、ユーザー委任 SAS トークンの一部として書き込み (w) アクセス許可が必要です。

ユーザー委任 SAS の詳細については、「ユーザー委任 SAS の作成」を参照してください。

サービス SAS

サービス SAS は、ストレージアカウントキーで保護されます。サービス SAS は、BLOB ストレージなどの単一の Azure Storage サービス内のリソースへのアクセスを委任します。

Put Block Listコンテナーまたは BLOB リソースに委任された SAS トークンを使用して操作を呼び出すには、サービス SAS トークンの一部として書き込み (w) アクセス許可が必要です。

サービス SAS の詳細については、「サービス SAS の作成」を参照してください。

アカウント SAS

アカウント SAS は、ストレージアカウントキーで保護されます。アカウント SAS は、1 つ以上のストレージサービスのリソースへのアクセスを委任します。サービスまたはユーザー委任 SAS を介して実行できるすべての操作は、アカウント SAS を介しても実行できます。

次の表は、アクセスを委任するときに指定する署名付きリソースの種類と署名付きアクセス許可を示しています。

操作	署名済みサービス	署名されたリソースの種類	署名されたアクセス許可
Put Block List	BLOB (b)	オブジェクト (o)	書き込み (w)

アカウント SAS の詳細については、「アカウント SAS の作成」を参照してください。

この操作では Put Block List 、共有キーの承認がサポートされています。アカウントキーを使用した承認は、セキュリティが低く、ほとんどのシナリオでは推奨されません。

可能な場合は、ストレージアカウントの共有キーの承認を禁止することをお勧めします。詳細については、「共有キーによる承認の防止」を参照してください。

注釈

Put Block List 操作によって、BLOB を作成するためにブロックが結合される順序が決まります。

ブロック一覧内に同じブロック ID を複数回指定できます。ブロック ID が複数回指定されている場合、最終的にコミットされた BLOB のブロックリスト内の各場所のバイト範囲を表します。同じブロック ID が一覧に複数出現した場合は、そのブロック ID のすべてのインスタンスを同じブロック一覧に指定する必要があります。つまり、すべてのインスタンスを Committed 要素、Uncommitted 要素、Latest 要素のいずれかに指定する必要があります。

では Put Block List、BLOB 全体を再度アップロードすることなく、個々のブロックを挿入、更新、または削除することで、既存の BLOB を変更できます。新規 BLOB を作成する場合、または既存 BLOB のコンテンツを更新する場合、ブロック ID を現在のコミット後のブロック一覧とコミット前のブロック一覧の両方から指定できます。このようにして、コミットされていないブロックリストからいくつかの新しいブロックを指定し、コミットされたブロックリストの残り (既に既存の BLOB の一部である) を指定することで、BLOB を更新できます。

Latest 要素に指定したブロック ID がコミット後のブロック一覧とコミット前のブロック一覧の両方に存在する場合、Put Block List はコミット前のブロック一覧からブロックをコミットします。コミットされたブロックリストにブロック ID が存在し、コミットされていないブロックリストに存在しない場合は、 Put Block List コミットされたブロックリストからブロックをコミットします。

ブロック BLOB 内の各ブロックのサイズは異なる場合があります。ブロック BLOB には、最大 50,000 個のコミット済みブロックを含めることができます。 BLOB に関連付けられる可能性があるコミットされていないブロックの最大数は 100,000 です。

次の表では、許可されるブロックと BLOB の最大サイズをサービスのバージョン別に示します。

サービスのバージョン	最大ブロックサイズ (経由 `Put Block`)	最大 BLOB サイズ (経由 `Put Block List`)	単一書き込み操作による最大 BLOB サイズ (経由 `Put Blob`)
バージョン 2019-12-12 以降	4,000 メビバイト (MiB)	約 190.7 テビバイト (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した操作の 1 週間以内に BLOB に対するPut Block呼び出しがPut Block List成功しなかった場合、ガベージコレクションされます。 PUT BLOB が BLOB で呼び出されると、コミットされていないブロックはすべてガベージコレクションされます。

ヘッダーにタグが x-ms-tags 指定されている場合は、クエリ文字列でエンコードする必要があります。タグキーと値は、で指定されている名前付けと長さの要件に Set Blob Tags準拠している必要があります。また、ヘッダーには x-ms-tags 、最大 2 KiB のサイズのタグを含むことができます。さらにタグが必要な場合は、 BLOB タグの設定操作を使用します。

BLOB にアクティブなリースがある場合、クライアントはブロックリストをコミットする要求に対して有効なリース ID を指定する必要があります。クライアントでリース ID が指定されていないか、無効なリース ID が指定されている場合、Blob Storage は状態コード 412 (前提条件に失敗しました) を返します。クライアントでリース ID が指定されているが、BLOB にアクティブなリースがない場合、Blob Storage は状態コード 412 (前提条件に失敗) も返します。クライアントでまだ存在しない BLOB のリース ID が指定されている場合、Blob Storage はバージョン 2013-08-15 以降に対して行われた要求の状態コード 412 (前提条件に失敗しました) を返します。以前のバージョンの場合、Blob Storage は状態コード 201 (作成済み) を返します。

BLOB にアクティブなリースが存在する場合、Put Block List を呼び出して BLOB を更新すると、更新された BLOB でもリースは維持されます。

Put Block List はブロック BLOB のみに適用されます。ページ BLOB に対して Put Block List を呼び出すと、ステータスコード 400 (Bad Request) が返されます。

アーカイブされた BLOB の上書きは失敗し、x-ms-access-tier ヘッダーが指定されていない場合、または cool BLOB を上書きhotすると古い BLOB から層が継承されます。

請求

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

操作	ストレージアカウントの種類	課金カテゴリ
Put Block List	Premium ブロック BLOB Standard 汎用 v2 Standard 汎用 v1	書き込み操作

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

こちらもご覧ください

ブロック BLOB、追加 BLOB、ページ BLOB について理解する
 Azure Storage への要求を承認する
 状態コードとエラーコード
 BLOB サービスのエラーコード
 BLOB サービス操作のタイムアウトを設定する