Freigeben über

Blockliste einfügen

Die Operation Put Block List schreibt einen Blob, indem sie die Liste der Block-IDs angibt, aus denen der Blob besteht. Um als Teil eines Blobs geschrieben zu werden, muss ein Block in einer früheren Put Block-Operation erfolgreich auf den Server geschrieben worden sein.

Du kannst Put Block List einen Blob aktualisieren, indem du nur die Blöcke hochlädst, die sich geändert haben, und dann die neuen und bestehenden Blöcke gemeinsam committen. Sie können dies tun, indem Sie angeben, ob Sie einen Block aus der zugesagten Blockliste oder aus der nicht festgelegten Blockliste committen oder die zuletzt hochgeladene Version des Blocks committen, je nachdem, welcher Liste sie angehört.

Anforderung

Sie können die Put Block List Anforderung wie folgt erstellen. Es wird empfohlen, HTTPS zu verwenden. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos:

PUT-Methodenanforderung URI HTTP-Version
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1

Emulierte Speicherdienstanforderung

Wenn Sie eine Anfrage gegen den emulierten Speicherdienst stellen, geben Sie den Emulator-Hostnamen und den Blob-Service-Port als 127.0.0.1:10000, gefolgt vom Namen des emulierten Speicherkontos:

PUT-Methodenanforderung URI HTTP-Version
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist HTTP/1.1

Der Speicheremulator unterstützt nur Blob-Größen von bis zu 2 Gibibyte (GiB).

Weitere Informationen finden Sie unter Verwenden des Azurite-Emulators für die lokale Azure Storage-Entwicklung.

URI-Parameter

Sie können die folgenden zusätzlichen Parameter für den Anforderungs-URI angeben:

Parameter Beschreibung
timeout Dies ist optional. Der parameter timeout wird in Sekunden ausgedrückt. Weitere Informationen finden Sie unter Set-Timeouts für Blob-Service-Operationen.

Anforderungsheader

Die erforderlichen und optionalen Anforderungsheader werden in der folgenden Tabelle beschrieben:

Anforderungsheader Beschreibung
Authorization Erforderlich. Gibt das Autorisierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
Date oder x-ms-date Erforderlich. Gibt die koordinierte Weltzeit (UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
x-ms-version Erforderlich für alle autorisierten Anforderungen. Gibt die Version des Vorgangs an, der für diese Anforderung verwendet werden soll. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.
Content-Length Erforderlich. Die Länge des Anfrage-Inhalts, in Bytes. Dieser Header bezieht sich auf die Inhaltslänge der Liste der Blöcke, nicht auf den Blob selbst.
Content-MD5 Dies ist optional. Ein MD5-Hash des Anforderungsinhalts. Dieser Hash wird verwendet, um die Integrität des Anforderungsinhalts während des Transports zu überprüfen. Wenn die beiden Hashs nicht übereinstimmen, schlägt der Vorgang mit Fehlercode 400 (Ungültige Anforderung) fehl.

Dieser Header ist mit dem Anfrageinhalt verknüpft und nicht mit dem Inhalt des Blobs selbst.
x-ms-content-crc64 Dies ist optional. Ein CRC64-Hash des Anfrage-Inhalts. Dieser Hash wird verwendet, um die Integrität des Anforderungsinhalts während des Transports zu überprüfen. Wenn die beiden Hashs nicht übereinstimmen, schlägt der Vorgang mit Fehlercode 400 (Ungültige Anforderung) fehl.

Dieser Header ist mit dem Anfrageinhalt verknüpft und nicht mit dem Inhalt des Blobs selbst.

Wenn sowohl Content-MD5- als auch x-ms-content-crc64-Header vorhanden sind, schlägt die Anfrage mit 400 (Bad Request) fehl.

Dieser Header wird in Version 2019-02-02 und höher unterstützt.
x-ms-blob-cache-control Dies ist optional. Setzt die Cache-Steuerung des Blobs ein. Wenn diese Eigenschaft angegeben ist, wird sie mit dem Blob gespeichert und mit einer Leseanforderung zurückgegeben.

Wenn die Eigenschaft nicht mit der Anfrage angegeben ist, wird sie für den Blob gelöscht, wenn die Anfrage erfolgreich ist.
x-ms-blob-content-type Dies ist optional. Legt den Inhaltstyp des Blobs fest. Wenn sie angegeben ist, wird diese Eigenschaft beim Blob gespeichert und mit einer Leseanforderung zurückgegeben.

Wenn der Inhaltstyp nicht angegeben ist, wird er auf den Standardtyp gesetzt, nämlich application/octet-stream.
x-ms-blob-content-encoding Dies ist optional. Setzt die Inhaltskodierung des Blobs. Wenn sie angegeben ist, wird diese Eigenschaft beim Blob gespeichert und mit einer Leseanforderung zurückgegeben.

Wenn die Eigenschaft nicht mit der Anfrage angegeben ist, wird sie für den Blob gelöscht, wenn die Anfrage erfolgreich ist.
x-ms-blob-content-language Dies ist optional. Legt die Inhaltssprache des Blobs fest. Wenn sie angegeben ist, wird diese Eigenschaft beim Blob gespeichert und mit einer Leseanforderung zurückgegeben.

Wenn die Eigenschaft nicht mit der Anfrage angegeben ist, wird sie für den Blob gelöscht, wenn die Anfrage erfolgreich ist.
x-ms-blob-content-md5 Dies ist optional. Ein MD5-Hash des BLOB-Inhalts. Dieser Hash wird nicht validiert, weil die Hashes der einzelnen Blöcke beim Hochladen validiert wurden.

Die Get Blob-Operation gibt den Wert dieses Headers im Content-MD5-Response-Header zurück.

Wenn diese Eigenschaft nicht mit der Anfrage angegeben ist, wird sie für den Blob gelöscht, falls die Anfrage erfolgreich ist.
x-ms-meta-name:value Dies ist optional. Benutzerdefinierte Name-Wert-Paare, die mit dem Blob verknüpft sind.

Seit Version 2009-09-19 müssen Metadatennamen den Namensregeln für C#-Identifikatoren entsprechen.
x-ms-encryption-scope Dies ist optional. Gibt den Verschlüsselungsbereich an, den zur Verschlüsselung des Blobs verwendet werden soll. Dieser Wert muss mit dem Verschlüsselungsumfang übereinstimmen, der zur Verschlüsselung aller Blöcke verwendet wird. Dieser Header wird in Version 2019-02-02 und höher unterstützt.
x-ms-encryption-context Dies ist optional. Standardeinstellung ist "Leer". Wenn der Wert gesetzt ist, setzt er Metadaten des Blob-Systems fest. Maximale Länge – 1024. Nur gültig, wenn der hierarchische Namespace für das Konto aktiviert ist. Dieser Header wird in den Versionen 2021-08-06 und später unterstützt.
x-ms-tags Dies ist optional. Setzt die spezifizierten Abfrage-String-kodierten Tags auf dem Blob. Weitere Informationen finden Sie im Abschnitt Bemerkungen . Unterstützt in Version 2019-12-12 und höher.
x-ms-lease-id:<ID> Erforderlich, wenn das Blob über eine aktive Pacht verfügt. Um diesen Vorgang für ein Blob mit einer aktiven Lease auszuführen, geben Sie die gültige Lease-ID für diesen Header an.
x-ms-client-request-id Dies ist optional. Stellt einen clientsgenerierten, undurchsichtigen Wert mit einer Zeichenbegrenzung von 1 Kibibyte (KiB) bereit, die in den Analyseprotokollen verzeichnet wird, wenn das Storage Analytics Logging konfiguriert wird. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt.
x-ms-blob-content-disposition Dies ist optional. Stellt den Content-Disposition Kopf des Blobs ein. Verfügbar für Version 2013-08-15 und höher.

Das Headerfeld Content-Disposition liefert zusätzliche Informationen darüber, wie die Antwortnutzlast verarbeitet werden soll, und kann verwendet werden, um zusätzliche Metadaten anzuhängen. Zum Beispiel, wenn es auf attachmentgesetzt ist, zeigt dieser Header an, dass der User-Agent die Antwort nicht anzeigen sollte, sondern stattdessen einen Dialog "Als speichern" anzeigen sollte.

Die Antwort der Get Blob - und Get Blob Properties-Operationen enthält den Inhaltsdispositions-Header.
x-ms-access-tier Dies ist optional. Version 2018-11-09 und später. Zeigt an, welche Stufe auf einem Blob gesetzt werden soll. Für Block Blobs wird dieser Header nur auf Blob-Speicher- oder allgemeinen V2-Konten ab Version 2018-11-09 und später unterstützt. Gültige Werte für Blockblob-Tiers sind Hot, Cool, Cold, Smart und Archive.
Hinweis:Cold Ebene wird für Version 2021-12-02 und höher unterstützt. Smart Tier wird ab Version 2026-02-06 und später unterstützt und befindet sich derzeit in der öffentlichen Vorschau.
Für detaillierte Informationen zum Block-Blob-Tiering siehe Blob Storage Tiers.
x-ms-immutability-policy-until-date Version 2020-06-12 und höher. Spezifiziert das auf dem Blob festgelegte Aufbewahrungsdatum . Dies ist das Datum, bis zu dem das Blob vor Änderungen oder Löschungen geschützt werden kann. Folgt RFC1123 Format.
x-ms-immutability-policy-mode Version 2020-06-12 und höher. Spezifiziert den auf dem Blob gesetzten Unveränderlichkeits-Policy-Modus. Gültige Werte sind unlocked und locked. Der Wert unlocked zeigt an, dass Nutzer die Richtlinie ändern können, indem sie das Bindungsdatum erhöhen oder verringern. Der Wert locked zeigt, dass diese Handlungen verboten sind.
x-ms-legal-hold Version 2020-06-12 und höher. Spezifiziert den rechtlichen Halt, der auf den Blob gesetzt werden soll. Die gültigen Werte sind true und false.
x-ms-expiry-option Dies ist optional. Version vom 03.08.2023 und später. Spezifiziert die Verfallsdatum-Option für die Anfrage, siehe ExpiryOption. Dieser Header ist gültig für Konten mit aktiviertem hierarchischen Namensraum.
x-ms-expiry-time Dies ist optional. Version vom 03.08.2023 und später. Gibt die Zeit an, zu der der Blob auf Ablauf gesetzt wird. Das Format für das Verfallsdatum variiert entsprechend .x-ms-expiry-option Weitere Informationen finden Sie unter ExpiryOption. Dieser Header ist gültig für Konten mit aktiviertem hierarchischen Namensraum.

Das expiryTime bereits vorhandene auf einem Blob wird nicht gelöscht, wenn die Anfrage keinen neuen Wert von enthält. expiryTime

Diese Operation unterstützt außerdem die Verwendung von bedingten Headern, um die Blockliste nur dann zu committen, wenn eine bestimmte Bedingung erfüllt ist. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Blob Storage-Vorgänge.

Anforderungsheader (vom Kunden bereitgestellte Verschlüsselungsschlüssel)

Seit Version 2019-02-02 können Sie auf der Anfrage folgende Header angeben, um einen Blob mit einem vom Kunden bereitgestellten Schlüssel zu verschlüsseln. Die Verschlüsselung mit einem vom Kunden bereitgestellten Schlüssel (und dem entsprechenden Satz von Headern) ist optional.

Anforderungsheader Beschreibung
x-ms-encryption-key Erforderlich. Der base64-codierte AES-256-Verschlüsselungsschlüssel.
x-ms-encryption-key-sha256 Erforderlich. Der base64-codierte SHA256-Hash des Verschlüsselungsschlüssels.
x-ms-encryption-algorithm: AES256 Erforderlich. Gibt den Algorithmus an, der für die Verschlüsselung verwendet werden soll. Der Wert dieses Headers muss auf AES256 festgelegt sein.

Anforderungstext

Im Request-Body können Sie die Blockliste angeben, die Blob Storage auf den gewünschten Block prüfen soll. So kann man einen bestehenden Blob aktualisieren, indem man einzelne Blöcke einfügt, ersetzt oder löscht, anstatt den gesamten Blob neu hochzuladen. Nachdem du den oder die geänderten Blöcke hochgeladen hast, kannst du eine neue Version des Blobs committen, indem du die neuen Blöcke zusammen mit den bestehenden Blöcken committest, die du behalten möchtest.

Um einen Blob zu aktualisieren, kann man angeben, dass der Dienst zuerst nach einer Block-ID in der Committed Block-Liste, in der Uncommitted Block-Liste oder in der Uncommitted Block-Liste und dann in der Committed Block-Liste suchen soll. Um anzugeben, welchen Ansatz verwendet werden soll, geben Sie die Block-ID an, die sich im entsprechenden XML-Element im Anforderungskörper befindet, wie folgt:

  • Gib die Block-ID innerhalb des Committed Elements an, um anzuzeigen, dass Blob Storage nur die Committed Block-Liste nach dem benannten Block durchsuchen soll. Wenn der Block in der Committed Block-Liste nicht gefunden wird, wird er nicht als Teil des Blobs geschrieben, und Blob Storage gibt den Statuscode 400 (Bad Request) zurück.

  • Geben Sie die Block-ID innerhalb des Elements Uncommitted an, um anzuzeigen, dass Blob Storage nur die Liste der uncommittierten Blöcke nach dem benannten Block durchsuchen sollte. Wenn der Block nicht in der Liste der uncommittierten Blöcke gefunden wird, wird er nicht als Teil des Blobs geschrieben, und Blob Storage gibt den Statuscode 400 (Bad Request) zurück.

  • Geben Sie die Block-ID innerhalb des Elements Latest an, um anzuzeigen, dass Blob Storage zuerst die Liste der nicht zugeteilten Blöcke durchsuchen sollte. Wenn der Block in der Uncommitted-Liste gefunden wird, ist diese Version des Blocks die neueste und sollte in den Blob geschrieben werden. Wenn der Block nicht in der Uncommitted-Liste gefunden wird, sollte der Service die Committed Block-Liste nach dem benannten Block durchsuchen und diesen Block in den Blob schreiben, falls er gefunden wird.

Der Anforderungskörper für diese Version von Put Block List verwendet folgendes XML-Format:

<?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>

Musteranforderung

Um es zu demonstrieren Put Block List, nehmen wir an, Sie haben drei Blöcke hochgeladen, die Sie jetzt festlegen möchten. Das folgende Beispiel committiert einen neuen Blob, indem es angibt, dass die neueste Version jedes aufgeführten Blocks verwendet werden soll. Es ist nicht notwendig zu wissen, ob diese Blockaden bereits gemacht wurden.

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>

Als Nächstes nehmen wir an, du möchtest den Blob aktualisieren. Der neue Blob hat folgende Änderungen:

  • Ein neuer Block mit Ausweis ANAAAA==. Dieser Block muss zuerst mit einem Aufruf zu Put Block hochgeladen werden und erscheint in der Liste der nicht zugeschriebenen Blocks, bis der Aufruf zu Put Block Listerfolgt.

  • Eine aktualisierte Version des Blocks mit ID AZAAAA==. Dieser Block muss zuerst mit einem Aufruf zu Put Block hochgeladen werden und erscheint in der Liste der nicht zugeschriebenen Blocks, bis der Aufruf zu Put Block Listerfolgt.

  • Entfernung des Blocks mit dem Ausweis AAAAAA==. Da dieser Block im nächsten Aufruf zu Put Block Listnicht enthalten ist, wird der Block effektiv aus dem Blob entfernt.

Das folgende Beispiel zeigt den Aufruf von Put Block List , der den Blob aktualisiert:

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>

Antwort

Die Antwort enthält einen HTTP-Statuscode und eine Reihe von Antwortheadern.

Statuscode

Ein erfolgreicher Vorgang gibt den Statuscode 201 (Erstellt) zurück.

Weitere Informationen zu Statuscodes finden Sie unter Status- und Fehlercodes.

Antwortkopfzeilen

Die Antwort für diesen Vorgang enthält die folgenden Header. Die Antwort kann auch zusätzliche Standard-HTTP-Header enthalten. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

Antwort Beschreibungen
ETag Das Entitäten-Tag enthält einen Wert, den der Client verwenden kann, um bedingte GET/PUT Operationen mithilfe des If-Match Request-Headers durchzuführen. Wenn die Anforderungsversion 2011-08-18 oder höher ist, wird der ETag-Wert in Anführungszeichen eingeschlossen.
Last-Modified Das Datum/die Uhrzeit, zu der das Blob zuletzt geändert wurde. Das Datumsformat folgt RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Kopfzeilen.

Jeder Vorgang, der das Blob ändert, einschließlich einer Aktualisierung der Metadaten oder Eigenschaften des Blobs, ändert den Zeitpunkt der letzten Änderung des Blobs.
Content-MD5 Wird zurückgegeben, sodass der Client auf die Integrität von Nachrichteninhalten überprüfen kann. Dieser Header bezieht sich auf den Inhalt der Anfrage (in diesem Fall auf die Liste der Blöcke und nicht auf den Inhalt des Blobs selbst). Für Version 2019-02-02 und später wird dieser Header nur zurückgegeben, wenn die Anfrage diesen Header enthält.
x-ms-content-crc64 Für Version 2019-02-02 und später wird dieser Header zurückgegeben, damit der Client die Integrität der Nachrichteninhalte überprüfen kann. Dieser Header bezieht sich auf den Inhalt der Anfrage (in diesem Fall auf die Liste der Blöcke und nicht auf den Inhalt des Blobs selbst).

Dieser Header wird zurückgegeben, wenn Content-md5 der Header in der Anfrage nicht vorhanden ist.
x-ms-request-id Identifiziert die anforderung eindeutig, die durchgeführt wurde, und Sie können sie verwenden, um die Anforderung zu beheben. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.
x-ms-version Die Version von Blob Storage, die zur Ausführung der Anfrage verwendet wird. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2009-09-19 und höher gestellt werden.
Date Ein UTC-Datum/-Uhrzeit-Wert, der vom Dienst generiert wird und angibt, wann die Antwort gestartet wurde.
x-ms-request-server-encrypted: true/false Version 2015-12-11 und höher. Der Wert dieses Headers wird gesetzt, true wenn der Inhalt der Anfrage erfolgreich mit dem angegebenen Algorithmus verschlüsselt wird. Andernfalls wird der Wert auf falsefestgelegt.
x-ms-encryption-key-sha256 Version 2019-02-02 und höher. Dieser Header wird zurückgegeben, wenn die Anfrage einen vom Kunden bereitgestellten Schlüssel zur Verschlüsselung verwendet hat, sodass der Client sicherstellen kann, dass der Inhalt der Anfrage erfolgreich verschlüsselt wird, indem er den bereitgestellten Schlüssel verwendet.
x-ms-encryption-scope Version 2019-02-02 und höher. Dieser Header wird zurückgegeben, wenn die Anfrage einen Verschlüsselungsbereich verwendet hat, sodass der Client sicherstellen kann, dass der Inhalt der Anfrage erfolgreich verschlüsselt wird, indem er den Verschlüsselungsbereich verwendet.
x-ms-version-id: <DateTime> Version 2019-12-12 und höher. Gibt einen undurchsichtigen DateTime Wert zurück, der das Blob eindeutig identifiziert. Der Wert dieses Headers gibt die Version des Blobs an, und er kann in nachfolgenden Anfragen verwendet werden, um auf den Blob zuzugreifen.
x-ms-client-request-id Kann verwendet werden, um Anfragen und die entsprechenden Antworten zu behandeln. Der Wert dieses Headers ist gleich dem Wert des x-ms-client-request-id Headers, wenn er in der Anforderung vorhanden ist und der Wert nicht mehr als 1.024 sichtbare ASCII-Zeichen enthält. Wenn der x-ms-client-request-id-Header in der Anforderung nicht vorhanden ist, ist er in der Antwort nicht vorhanden.

Beispielantwort

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>

Autorisierung

Die Autorisierung ist beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage erforderlich. Sie können den Put Block List Vorgang wie unten beschrieben autorisieren.

Wenn eine Anfrage Tags mit dem x-ms-tags Anfrage-Header angibt, muss der Aufrufer die Autorisierungsanforderungen der Set Blob Tags-Operation erfüllen.

Von Bedeutung

Microsoft empfiehlt die Verwendung der Microsoft Entra-ID mit verwalteten Identitäten, um Anforderungen an Azure Storage zu autorisieren. Die Microsoft Entra-ID bietet eine bessere Sicherheit und Benutzerfreundlichkeit im Vergleich zur Shared Key-Autorisierung.

Azure Storage unterstützt die Verwendung der Microsoft Entra-ID zum Autorisieren von Anforderungen an BLOB-Daten. Mit Der Microsoft Entra-ID können Sie azure role-based access control (Azure RBAC) verwenden, um Berechtigungen für einen Sicherheitsprinzipal zu erteilen. Der Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine von Azure verwaltete Identität sein. Der Sicherheitsprinzipal wird von Microsoft Entra ID authentifiziert, und gibt ein OAuth 2.0-Token zurück. Das Token kann dann verwendet werden, um eine Anforderung gegen den Blob-Dienst zu autorisieren.

Weitere Informationen zur Autorisierung mithilfe der Microsoft Entra-ID finden Sie unter Autorisieren des Zugriffs auf Blobs mithilfe von Microsoft Entra ID.

Erlaubnisse

Nachfolgend sind die RBAC-Aktion aufgeführt, die für einen Microsoft Entra-Benutzer, eine Gruppe, eine verwaltete Identität oder einen Dienstprinzipal erforderlich ist, um den Put Block List Vorgang aufzurufen, und die integrierte Azure RBAC-Rolle, die diese Aktion enthält:

Weitere Informationen zum Zuweisen von Rollen mithilfe von Azure RBAC finden Sie unter Zuweisen einer Azure-Rolle für den Zugriff auf BLOB-Daten.

Bemerkungen

Die Operation Put Block List setzt die Reihenfolge vor, in der Blöcke kombiniert werden sollen, um einen Blob zu bilden.

Dieselbe Block-ID kann mehrmals in der Liste der Blöcke angegeben werden. Wenn eine Block-ID mehr als einmal angegeben wird, repräsentiert sie den Bereich der Bytes an jedem dieser Orte in der Blockliste für den endgültig zugesagten Blob. Wenn eine Block-ID mehrmals in der Liste erscheint, müssen beide Instanzen der Block-ID innerhalb derselben Blockliste angegeben werden. Mit anderen Worten: Beide Instanzen müssen innerhalb des Elements Committed , des Elements Uncommitted oder des Elements Latest angegeben werden.

Mit kann man einen bestehenden Blob verändern, indem man einzelne Blöcke Put Block Listeinfügt, aktualisiert oder löscht, ohne den gesamten Blob erneut hochladen zu müssen. Man kann Block-IDs sowohl aus der aktuellen Blockliste als auch aus der nicht gebundenen Blockliste angeben, um einen neuen Blob zu erstellen oder den Inhalt eines bestehenden Blobs zu aktualisieren. Auf diese Weise können Sie einen Blob aktualisieren, indem Sie einige neue Blöcke aus der nicht gebundenen Blockliste und den Rest aus der committierten Blockliste, die bereits Teil des bestehenden Blobs sind, angibt.

Wenn im Element Latest eine Block-ID angegeben ist und dieselbe Block-ID sowohl in der Listen als auch in der nicht gebundenen Blockliste existiert, Put Block List commit der Block aus der nicht zugeteilten Blockliste. Wenn die Block-ID in der Committed Block-Liste vorhanden ist, aber nicht in der Uncommitt-Blockliste, Put Block List commit sie den Block aus der Committed Block-Liste.

Jeder Block in einem Blockblob kann eine andere Größe haben. Ein Block-Blob kann maximal 50.000 verpflichtete Blöcke enthalten. Die maximale Anzahl der nicht gebundenen Blöcke, die mit einem Blob verknüpft sein dürfen, beträgt 100.000.

Die folgende Tabelle beschreibt die maximal erlaubten Block- und Blob-Größen nach Serviceversion:

Dienstversion Maximale Blockgröße (über Put Block) Maximale Blob-Größe (über Put Block List) Maximale Blob-Größe per Einzelschreiboperation (über Put Blob)
Ab Version 2019-12-12 4.000 Mebibyte (MiB) Ca. 190,7 Tebibyte (TiB) (4.000 MiB × 50.000 Blöcke) 5.000 MiB
Versionen vom 31.05.2016 bis 07.07.2019 100 MiB Ungefähr 4,75 TiB (100 MiB × 50.000 Blöcke) 256 MiB
Versionen vor dem 31.05.2016 4 MiB Ungefähr 195 GiB (4 MiB × 50.000 Blöcke) 64 MiB

Wenn Sie Put Block List einen bestehenden Blob aktualisieren, werden die bestehenden Eigenschaften und Metadaten des Blobs überschrieben. Allerdings werden alle vorhandenen Schnappschüsse mit dem Blob beibehalten. Man kann die bedingten Anfrage-Header nur dann verwenden, um die Operation auszuführen, wenn eine bestimmte Bedingung erfüllt ist.

Wenn die Put Block List Operation wegen eines fehlenden Blocks fehlschlägt, musst du den fehlenden Block hochladen.

Alle ungebundenen Blöcke werden als Garbage Collected aufgenommen, wenn innerhalb einer Woche nach der letzten erfolgreichen Put Block Operation keine erfolgreichen Anrufe zum Put Block oder Put Block List auf dem Blob durchgeführt werden. Wenn Put Blob für das Blob aufgerufen wird, werden alle Blöcke, für die kein Commit ausgeführt wurde, von der Garbage Collection erfasst.

Wenn Tags im Header x-ms-tags angegeben sind, müssen sie mit einer Abfragezeichenkette codiert werden. Tag-Schlüssel und -Werte müssen den Namens- und Längenanforderungen entsprechen, wie in Set Blob Tags. Außerdem kann der Header x-ms-tags Tags von bis zu 2 KiB umfassen. Wenn weitere Tags benötigt werden, verwenden Sie die Operation Set Blob Tags .

Wenn der Blob einen aktiven Lease hat, muss der Client auf der Anfrage eine gültige Lease-ID angeben, um die Blockliste zu committen. Wenn der Client entweder keine Lease-ID oder eine ungültige Lease-ID angibt, gibt Blob Storage den Statuscode 412 (Vorbedingung fehlgeschlagen) zurück. Wenn der Client eine Lease-ID angibt, der Blob aber keinen aktiven Lease hat, gibt Blob Storage auch den Statuscode 412 (Precondition Failed) zurück. Wenn der Client eine Lease-ID für einen Blob angibt, der noch nicht existiert, gibt Blob Storage den Statuscode 412 (Precondition Failed) für Anfragen gegen Version 2013-08-15 oder später zurück. Für frühere Versionen gibt Blob Storage den Statuscode 201 (Erstellt) zurück.

Wenn der Blob einen aktiven Lease hat und du den Blob aktualisieren Put Block List willst, wird der Lease auf dem aktualisierten Blob aufrechterhalten.

Put Block List gilt nur für Blockblobs. Das Aufrufen Put Block List eines Page Blob führt zu Statuscode 400 (Bad Request).

Das Überschreiben eines Blobs archive schlägt fehl. Andernfalls erbt ein Blob die Stufe vom alten Blob, falls kein x-ms-access-tier Header bereitgestellt wird.

Abrechnung

Preisanforderungen können von Clients stammen, die Blob Storage-APIs verwenden, entweder direkt über die BLOB Storage-REST-API oder aus einer Azure Storage-Clientbibliothek. Diese Anforderungen anfallen Gebühren pro Transaktion. Der Transaktionstyp wirkt sich auf die Belastung des Kontos aus. Lesen Sie z. B. Transaktionen, die einer anderen Abrechnungskategorie als dem Schreiben von Transaktionen zugerechnet werden. Die folgende Tabelle zeigt die Abrechnungskategorie für Put Block List Anforderungen basierend auf dem Speicherkontotyp:

Vorgang Speicherkontotyp Abrechnungskategorie
Blockliste einfügen Premium-Blockblob
Standard für allgemeinen Zwecke v2
Standard-Allzweck v1		 Schreibvorgänge

Informationen zu den Preisen für die angegebene Abrechnungskategorie finden Sie unter Azure Blob Storage Pricing.

Siehe auch

Verstehe Blockblobs, Append Blobs und Page Blobs
Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blob-Service-Fehlercodes
Setze Timeouts für Blob-Service-Operationen

  • Last updated on