Put Blob

  • Artikel

Der Put Blob Vorgang erstellt ein neues Block-, Seiten- oder Anfügeblob oder aktualisiert den Inhalt eines vorhandenen Blockblobs. Der Put Blob Vorgang überschreibt alle Inhalte eines vorhandenen Blobs mit demselben Namen.

Wenn Sie ein vorhandenes Blockblob aktualisieren, überschreiben Sie alle vorhandenen Metadaten im Blob. Der Inhalt des vorhandenen Blobs wird mit dem Inhalt des neuen Blobs überschrieben. Partielle Updates werden mit Put Blobnicht unterstützt. Um eine teilweise Aktualisierung des Inhalts eines Blockblobs durchzuführen, verwenden Sie den Vorgang Blockliste platzieren .

Sie können ein Anfügeblob nur in Versionen 2015-02-21 und höher erstellen.

Ein Aufruf eines Put Blob zum Erstellen eines Seitenblobs oder eines Anfügeblobs initialisiert nur das Blob. Wenn das Blob bereits vorhanden ist, wird der Inhalt gelöscht. Um einem Seitenblob Inhalt hinzuzufügen, rufen Sie den Vorgang Seite put auf. Um einem Anfügeblob Inhalt hinzuzufügen, rufen Sie den Vorgang Block anfügen auf .

Anforderung

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

PUT-Methodenanforderungs-URI HTTP-Version
https://myaccount.blob.core.windows.net/mycontainer/myblob HTTP/1.1

Emulierte Speicherdienstanforderung

Wenn Sie eine Anforderung für den emulierten Speicherdienst stellen, geben Sie den Hostnamen des Emulators und den Blobdienstport als 127.0.0.1:10000an, gefolgt vom Namen des emulierten Speicherkontos:

PUT-Methodenanforderungs-URI HTTP-Version
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob HTTP/1.1

Der Speicheremulator unterstützt nur Blobgrößen von bis zu 2 Gibibytes (GiB).

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

URI-Parameter

Die folgenden zusätzlichen Parameter können für den Anforderungs-URI angegeben werden:

Parameter BESCHREIBUNG
timeout Optional. Der timeout-Parameter wird in Sekunden angegeben. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blobdienstvorgänge.

Anforderungsheader (alle Blobtypen)

Die erforderlichen und optionalen Anforderungsheader für alle Blobtypen 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 (Coordinated Universal Time, 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 für die Anforderung zu verwendenden Vorgangs an. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.
Content-Length Erforderlich. Die Länge der Anforderung.

Für ein Seitenblob oder ein Anfügeblob muss der Wert dieses Headers auf 0 festgelegt werden, da Put Blob nur zum Initialisieren des Blobs verwendet wird. Um Inhalte in ein vorhandenes Seitenblob zu schreiben, rufen Sie Put Page auf. Um Inhalte in ein Anfügeblob zu schreiben, rufen Sie Append Block auf.
Content-Type Optional. Der MIME-Inhaltstyp des BLOB. Der Standardtyp ist application/octet-stream.
Content-Encoding Optional. Gibt an, welche Inhaltscodierungen auf das BLOB angewendet wurden. Dieser Wert wird an den Client zurückgegeben, wenn der Vorgang Blob abrufen für die Blobressource ausgeführt wird. Wenn dieser Wert zurückgegeben wird, kann der Client ihn verwenden, um den Blobinhalt zu decodieren.
Content-Language Optional. Gibt die natürlichen Sprachen an, die von dieser Ressource verwendet werden.
Content-MD5 Optional. Ein MD5-Hash des BLOB-Inhalts. Mithilfe des Hash wird die Integrität des BLOB während der Übertragung überprüft. Wenn dieser Header angegeben ist, überprüft der Speicherdienst den eingegangenen Hash mit dem gesendeten. Wenn die beiden Hashs nicht übereinstimmen, schlägt der Vorgang mit Fehlercode 400 (Ungültige Anforderung) fehl.

Wenn der Header in Version 2012-02-12 oder höher ausgelassen wird, generiert Blob Storage einen MD5-Hash.

Ergebnisse aus Get Blob, Get Blob Properties und List Blobs enthalten den MD5-Hash.
x-ms-content-crc64 Optional. Ein CRC64-Hash des Blobinhalts. Mithilfe des Hash wird die Integrität des BLOB während der Übertragung überprüft. Wenn dieser Header angegeben ist, überprüft der Speicherdienst den eingegangenen Hash mit dem gesendeten. Wenn die beiden Hashs nicht übereinstimmen, schlägt der Vorgang mit Fehlercode 400 (Ungültige Anforderung) fehl. Dieser Header wird in den Versionen 02-02-2019 und höher unterstützt.

Wenn sowohl Content-MD5- als auch x-ms-content-crc64-Header vorhanden sind, schlägt die Anforderung mit einer 400 (Ungültige Anforderung) fehl.
Cache-Control Optional. Blob Storage speichert diesen Wert, verwendet oder ändert ihn jedoch nicht.
x-ms-blob-content-type Optional. Legt den Inhaltstyp des BLOB fest.
x-ms-blob-content-encoding Optional. Legt die Inhaltscodierung des BLOB fest.
x-ms-blob-content-language Optional. Legt die Sprache für den Inhalt des BLOB fest.
x-ms-blob-content-md5 Optional. Legt den MD5-Hash des BLOB fest.
x-ms-blob-cache-control Optional. Legt das Cachesteuerelement des BLOB fest.
x-ms-blob-type: <BlockBlob ¦ PageBlob ¦ AppendBlob> Erforderlich. Gibt den Typ des zu erstellenden Blobs an: Blockblob, Seitenblob oder Anfügen eines Blobs. Die Unterstützung zum Erstellen eines Anfügeblobs ist nur ab Version 2015-02-21 verfügbar.
x-ms-meta-name:value Optional. Name-Wert-Paare, die dem BLOB als Metadaten zugeordnet sind.

Hinweis: Ab Version 2009-09-19 müssen Metadatennamen den Benennungsregeln für C#-Bezeichner entsprechen.
x-ms-encryption-scope Optional. Gibt den Verschlüsselungsbereich an, der zum Verschlüsseln des Anforderungsinhalts verwendet werden soll. Dieser Header wird in Versionen 2019-02-02 und höher unterstützt.
x-ms-encryption-context Optional. Der Standardwert ist "Leer". Wenn der Wert festgelegt ist, werden Blobsystemmetadaten festgelegt. 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 höher unterstützt.
x-ms-tags Optional. Legt die angegebenen abfragezeichenfolgencodierten Tags für das Blob fest. Weitere Informationen finden Sie in den Anmerkungen. Unterstützt in Version 2019-12-12 und höher.
x-ms-lease-id:<ID> Erforderlich, wenn das BLOB über eine aktive Lease 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-blob-content-disposition Optional. Legt den Content-Disposition-Header des BLOBs fest. Dieser ist für die Version 2013-08-15 und höher verfügbar.

Das Content-Disposition Antwortheaderfeld enthält zusätzliche Informationen zur Verarbeitung der Antwortnutzlast, und Sie können es verwenden, um zusätzliche Metadaten anzufügen. Wenn der Header beispielsweise auf attachmentfestgelegt ist, gibt dies an, dass der Benutzer-Agent die Antwort nicht anzeigen soll. Stattdessen sollte ein Dialogfeld Speichern unter mit einem anderen Dateinamen als dem angegebenen Blobnamen angezeigt werden.

Die Antwort der Vorgänge Blob abrufen und Blobeigenschaften abrufen enthält den content-disposition Header.
Origin Optional. Gibt die Ursprungsdomäne an, von der die Anforderung ausgegeben wird. Wenn dieser Header vorhanden ist, werden CORS (Cross-Origin Resource Sharing)-Header für die Antwort erzeugt. Weitere Informationen finden Sie unter CORS-Unterstützung für die Azure Storage-Dienste.
x-ms-client-request-id Optional. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem Zeichenlimit von 1 Kibibyte (KiB) bereit, der in den Analyseprotokollen aufgezeichnet wird, wenn die Protokollierung konfiguriert ist. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt. Weitere Informationen finden Sie unter Informationen zur Speicheranalyseprotokollierung.
x-ms-access-tier Optional. Die Ebene, die für das Blob festgelegt werden soll. Für Seitenblobs auf einem Storage Premium Konto nur mit Version 2017-04-17 und höher. Eine vollständige Liste der von Seitenblobs unterstützten Tarife finden Sie unter Hochleistungsspeicher premium und verwaltete Datenträger für virtuelle Computer (VMs). Für Blockblobs, die in Blob Storage- oder Allgemeinen v2-Konten nur mit Version 2018-11-09 und höher unterstützt werden. Gültige Werte für Blockblobebenen sind Hot, ColdCool, und Archive. Hinweis: Cold Der Tarif wird für Version 2021-12-02 und höher unterstützt. Ausführliche Informationen zum Blockblobtiering finden Sie unter Speicherebenen "Heiß", "Kalt" und "Archiv".
x-ms-immutability-policy-until-date Version 2020-06-12 und höher. Gibt das Aufbewahrungsdatum an, das für das Blob festgelegt werden soll. Dies ist das Datum, bis zu dem das Blob vor dem Ändern oder Löschen geschützt werden kann. Folgt RFC1123 Format.
x-ms-immutability-policy-mode Version 2020-06-12 und höher. Gibt den Unveränderlichkeitsrichtlinienmodus an, der für das Blob festgelegt werden soll. Gültige Werte sind unlocked und locked. Mit unlockedkönnen Benutzer die Richtlinie ändern, indem sie die Aufbewahrung bis zum Datum erhöhen oder verringern. Mit lockedsind diese Aktionen verboten.
x-ms-legal-hold Version 2020-06-12 und höher. Gibt den gesetzlichen Aufbewahrungsspeicher an, der für das Blob festgelegt werden soll. Gültige Werte sind true und false.
x-ms-expiry-option Optional. Version 2023-08-03 und höher. Gibt die Ablaufdatumsoption für die Anforderung an. Weitere Informationen finden Sie unter ExpiryOption. Dieser Header gilt für Konten mit aktiviertem hierarchischem Namespace.
x-ms-expiry-time Optional. Version 2023-08-03 und höher. Gibt den Zeitpunkt an, zu dem das Blob abläuft. Das Format für das Ablaufdatum variiert je nach x-ms-expiry-option. Weitere Informationen finden Sie unter ExpiryOption. Dieser Header gilt für Konten mit aktiviertem hierarchischem Namespace.

Dieser Vorgang unterstützt zudem die Verwendung von bedingten Headern zum Schreiben in das BLOB nur dann, wenn eine bestimmte Bedingung erfüllt ist. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Blob Storage-Vorgänge.

Anforderungsheader (nur Seitenblobs)

Die Anforderungsheader, die nur für Vorgänge für Seitenblobs gelten, werden in der folgenden Tabelle beschrieben:

Anforderungsheader BESCHREIBUNG
x-ms-blob-content-length: bytes Erforderlich für Seitenblobs. Dieser Header gibt die maximale Größe für das Seitenblob an, bis zu 8 Tebibytes (TiB). Die Größe des Seitenblobs muss auf eine Begrenzung von 512 Bytes ausgerichtet werden.

Wenn dieser Header für ein Blockblob oder ein Anfügeblob angegeben ist, gibt Blob Storage status Code 400 (Ungültige Anforderung) zurück.
x-ms-blob-sequence-number: <num> Optional. Wird nur für Seitenblobs festgelegt. Die Sequenznummer ist ein vom Benutzer festgelegter Wert, anhand dessen Anforderungen nachverfolgt werden können. Der Wert der Sequenznummer muss zwischen 0 und 2^63 - 1 sein. Der Standardwert ist 0.
x-ms-access-tier Version 2017-04-17 und höher. Nur für Seitenblobs in einem Storage Premium-Konto. Gibt die Ebene an, die für das Blob festgelegt werden soll. Eine vollständige Liste der unterstützten Tarife finden Sie unter Hochleistungsspeicher premium und verwaltete Datenträger für VMs.
x-ms-client-request-id Dieser Header kann zur Problembehandlung von Anforderungen und entsprechenden Antworten verwendet werden. 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.

Anforderungsheader (vom Kunden bereitgestellte Verschlüsselungsschlüssel)

Ab Version 2019-02-02 können die folgenden Header für die Anforderung angegeben werden, um ein 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

Für ein Block-BLOB enthält der Anforderungstext den Inhalt des BLOB.

Bei einem Seitenblob oder einem Anfügeblob ist der Anforderungstext leer.

Beispiel für eine Anforderung

Im folgenden Beispiel wird eine Anforderung zum Erstellen eines Block-BLOB veranschaulicht:

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblockblob HTTP/1.1  
  
Request Headers:  
x-ms-version: 2015-02-21  
x-ms-date: <date>  
Content-Type: text/plain; charset=UTF-8  
x-ms-blob-content-disposition: attachment; filename="fname.ext"  
x-ms-blob-type: BlockBlob  
x-ms-meta-m1: v1  
x-ms-meta-m2: v2  
x-ms-expiry-option: RelativeToNow
x-ms-expiry-time: 30000
Authorization: SharedKey myaccount:YhuFJjN4fAR8/AmBrqBz7MG2uFinQ4rkh4dscbj598g=  
Content-Length: 11  
  
Request Body:  
hello world

Diese Beispielanforderung erstellt ein Seitenblob und gibt seine maximale Größe auf 1.024 Bytes an. Zum Hinzufügen von Inhalten zu einem Seitenblob müssen Sie Put Page aufrufen:

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/mypageblob HTTP/1.1  
  
Request Headers:  
x-ms-version: 2015-02-21  
x-ms-date: <date>  
Content-Type: text/plain; charset=UTF-8  
x-ms-blob-type: PageBlob  
x-ms-blob-content-length: 1024  
x-ms-blob-sequence-number: 0  
Authorization: SharedKey   
Origin: http://contoso.com  
Vary: Origin  
myaccount:YhuFJjN4fAR8/AmBrqBz7MG2uFinQ4rkh4dscbj598g=  
Content-Length: 0

Diese Beispielanforderung erstellt ein Anfügeblob. Zum Hinzufügen von Inhalten zum Anfügeblob müssen Sie Append Block aufrufen:

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myappendblob HTTP/1.1  
  
Request Headers:  
x-ms-version: 2015-02-21  
x-ms-date: <date>  
Content-Type: text/plain; charset=UTF-8  
x-ms-blob-type: AppendBlob  
Authorization: SharedKey myaccount:YhuFJjN4fAR8/AmBrqBz7MG2uFinQ4rkh4dscbj598g=  
Origin: http://contoso.com  
Vary: Origin  
Content-Length: 0

Antwort

Die Antwort enthält den HTTP-Statuscode und einen Satz von Antwortheadern.

Statuscode

Bei einem erfolgreichen Vorgang wird der Statuscode 201 (Erstellt) zurückgegeben.

Weitere Informationen zu status Codes finden Sie unter Status- und Fehlercodes.

Antwortheader

Die Antwort für diesen Vorgang umfasst die folgenden Header. Die Antwort kann außerdem weitere HTTP-Standardheader enthalten. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

Antwortheader BESCHREIBUNG
ETag Enthält einen Wert, den der Client verwenden kann, um bedingte PUT Vorgänge mithilfe des Anforderungsheaders If-Match auszufü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 der letzten Änderung des Blobs. Das Datumsformat entspricht RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Headern.

Bei jedem Schreibvorgang für das BLOB (einschließlich von Updates der Metadaten oder Eigenschaften des BLOB) wird der Zeitpunkt der letzten Änderung des BLOB geändert.
Content-MD5 Wird für ein Blockblob zurückgegeben, damit der Client die Integrität des Nachrichteninhalts überprüfen kann. Der Content-MD5 zurückgegebene Wert wird von Blob Storage berechnet. In Version 2012-02-12 und höher wird dieser Header zurückgegeben, auch wenn die Anforderung keine Content-MD5 Header oder x-ms-blob-content-md5 enthält.
x-ms-content-crc64 Wird für ein Blockblob zurückgegeben, damit der Client die Integrität des Nachrichteninhalts überprüfen kann. Der x-ms-content-crc64 zurückgegebene Wert wird von Blob Storage berechnet. Dieser Header wird immer ab Version 2019-02-02 zurückgegeben.
x-ms-request-id Identifiziert eindeutig die Anforderung, die gestellt wurde, und Sie können sie verwenden, um die Problembehandlung für die Anforderung zu beheben. Weitere Informationen finden Sie unter Problembehandlung bei API-Vorgängen.
x-ms-version Gibt die Blob Storage-Version an, die zum Ausführen der Anforderung verwendet wurde. Wird für Anforderungen zurückgegeben, die ab Version 2009-09-19 gestellt wurden.
Date Ein UTC-Datums-/Uhrzeitwert, der vom Dienst generiert wird, der die Uhrzeit angibt, zu der die Antwort initiiert wurde.
Access-Control-Allow-Origin Wird zurückgegeben, wenn die Anforderung einen Origin-Header enthält und CORS mit einer Abgleichsregel aktiviert ist. Dieser Header gibt den Wert des Ursprungsanforderungsheaders zurück, wenn eine Übereinstimmung vorliegt.
Access-Control-Expose-Headers Wird zurückgegeben, wenn die Anforderung einen Origin-Header enthält und CORS mit einer Abgleichsregel aktiviert ist. Gibt die Liste der Antwortheader zurück, die gegenüber dem Client oder Aussteller der Anforderung verfügbar gemacht werden sollen.
Access-Control-Allow-Credentials Wird zurückgegeben, wenn die Anforderung einen Origin Header enthält und CORS mit einer übereinstimmenden Regel aktiviert ist, die nicht alle Ursprünge zulässt. Dieser Header ist auf true festgelegt.
x-ms-request-server-encrypted: true/false Version 2015-12-11 und höher. Der Wert dieses Headers wird auf true festgelegt, wenn der Inhalt der Anforderung mithilfe des angegebenen Algorithmus erfolgreich verschlüsselt wurde. Andernfalls lautet der Wert false.
x-ms-encryption-key-sha256 Version 2019-02-02 und höher. Wird zurückgegeben, wenn die Anforderung einen vom Kunden bereitgestellten Schlüssel für die Verschlüsselung verwendet hat, damit der Client sicherstellen kann, dass der Inhalt der Anforderung mithilfe des bereitgestellten Schlüssels erfolgreich verschlüsselt wurde.
x-ms-encryption-scope Version 2019-02-02 und höher. Wird zurückgegeben, wenn die Anforderung einen Verschlüsselungsbereich verwendet hat, damit der Client sicherstellen kann, dass der Inhalt der Anforderung mithilfe des Verschlüsselungsbereichs erfolgreich verschlüsselt wurde.
x-ms-version-id: <DateTime> Version 2019-12-12 und höher. Dieser Header 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 Anforderungen verwendet werden, um auf das Blob zuzugreifen.

Antworttext

Keine.

Beispiel für eine Antwort

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
Content-MD5: sQqNsWTgdUEFt6mb5y4/5Q==  
x-ms-content-crc64: 77uWZTolTHU
Date: <date>  
ETag: "0x8CB171BA9E94B0B"  
Last-Modified: <date>  
Access-Control-Allow-Origin: http://contoso.com  
Access-Control-Expose-Headers: Content-MD5  
Access-Control-Allow-Credentials: True  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-version-id: <DateTime>

Authorization

Beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage ist eine Autorisierung erforderlich. Sie können den Put Blob Vorgang wie unten beschrieben autorisieren.

Wenn eine Anforderung Tags mit dem Anforderungsheader x-ms-tags angibt, muss der Aufrufer die Autorisierungsanforderungen des Vorgangs Set Blob Tags erfüllen.

Azure Storage unterstützt die Verwendung von Microsoft Entra ID zum Autorisieren von Anforderungen an Blobdaten. Mit Microsoft Entra ID können Sie die rollenbasierte Zugriffssteuerung (Azure RBAC) von Azure verwenden, um einem Sicherheitsprinzipal Berechtigungen zu erteilen. Der Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine verwaltete Azure-Identität sein. Der Sicherheitsprinzipal wird von Microsoft Entra ID authentifiziert, um ein OAuth 2.0-Token zurückzugeben. Das Token kann anschließend zum Autorisieren einer Anforderung an den Blob-Dienst verwendet werden.

Weitere Informationen zur Autorisierung mit Microsoft Entra ID finden Sie unter Autorisieren des Zugriffs auf Blobs mit Microsoft Entra ID.

Berechtigungen

Im Folgenden sind die RBAC-Aktion aufgeführt, die für einen Microsoft Entra Benutzer, Eine Gruppe oder einen Dienstprinzipal erforderlich ist, um den Put Blob Vorgang aufzurufen, und die integrierte Azure RBAC-Rolle mit den geringsten Berechtigungen, 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 Blobdaten.

Hinweise

Wenn Sie ein Blob erstellen, müssen Sie angeben, ob es sich um ein Blockblob, ein Anfügeblob oder um ein Seitenblob handelt, indem Sie den Wert des x-ms-blob-type Headers angeben. Nachdem ein Blob erstellt wurde, kann der Typ des Blobs nur geändert werden, wenn er gelöscht und neu erstellt wird.

In der folgenden Tabelle werden die maximal zulässigen Block- und Blobgrößen nach Dienstversion beschrieben:

Dienstversion Maximale Blockgröße (über Put Block) Maximale Blobgröße (über Put Block List) Maximale Blobgröße über einen einzelnen Schreibvorgang (über Put Blob)
Ab Version 2019-12-12 4.000 Mebibyte (MiB) Ungefähr 190,7 TiB (4.000 MiB × 50.000 Blöcke) 5.000 MiB
Versionen 2016-05-31 bis 2019-07-07 100 MiB Ungefähr 4,75 TiB (100 MiB × 50.000 Blöcke) 256 MiB
Versionen vor 2016-05-31 4 MiB Ungefähr 195 GiB (4 MiB × 50.000 Blöcke) 64 MiB

Wenn Sie versuchen, entweder ein Blockblob hochzuladen, das größer als die maximal zulässige Größe für diese Dienstversion ist, oder ein Seitenblob, das größer als 8 TiB ist, gibt der Dienst status Code 413 (Anforderungsentität zu groß) zurück. Blob Storage gibt auch zusätzliche Informationen zum Fehler in der Antwort zurück, einschließlich der maximal zulässigen Blobgröße in Bytes.

Um ein neues Seitenblob zu erstellen, initialisieren Sie zuerst das Blob, indem Sie aufrufen Put Blob, und geben Sie dann die maximale Größe von bis zu 8 TiB an. Wenn Sie ein Seitenblob erstellen, schließen Sie keinen Inhalt in den Anforderungstext ein. Nachdem das Blob erstellt wurde, rufen Sie Put Page auf, um dem Blob Inhalte hinzuzufügen oder zu ändern.

Um ein neues Anfügeblob zu erstellen, rufen Sie Put Blob auf, um es mit einer Inhaltslänge von 0 Bytes zu erstellen. Nachdem das Anfügeblob erstellt wurde, rufen Sie Append Block auf, um Inhalte am Ende hinzuzufügen.

Wenn Sie aufrufen Put Blob , um ein vorhandenes Blob mit demselben Namen zu überschreiben, werden alle Momentaufnahmen, die dem ursprünglichen Blob zugeordnet sind, beibehalten. Um zugeordnete Momentaufnahmen zu entfernen, rufen Sie zuerst Delete Blob auf, und rufen Sie dann auf Put Blob , um das Blob erneut zu erstellen.

Benutzerdefinierte Blobeigenschaften

Ein Blob verfügt über benutzerdefinierte Eigenschaften (über Header festgelegt), die Sie verwenden können, um Werte zu speichern, die Standard-HTTP-Headern zugeordnet sind. Sie können diese Werte anschließend lesen, indem Sie Get Blob Properties aufrufen, oder sie ändern, indem Sie Set Blob Properties aufrufen. Die Header mit benutzerdefinierten Eigenschaften und der entsprechende HTTP-Standardheader werden in der folgenden Tabelle aufgelistet:

HTTP-Header Header mit benutzerdefinierten BLOB-Eigenschaften
Content-Type x-ms-blob-content-type
Content-Encoding x-ms-blob-content-encoding
Content-Language x-ms-blob-content-language
Content-MD5 x-ms-blob-content-md5
Cache-Control x-ms-blob-cache-control

Die Semantik zum Festlegen oder Beibehalten dieser Eigenschaftswerte mit dem Blob lautet wie folgt:

  • Wenn der Client einen Header mit benutzerdefinierten Eigenschaften angibt (wie durch das x-ms-blob-Präfix angezeigt), wird dieser Wert mit dem BLOB gespeichert.

  • Wenn der Client einen HTTP-Standardheader angibt, aber nicht den benutzerdefinierten Eigenschaftenheader, wird der Wert in der entsprechenden benutzerdefinierten Eigenschaft gespeichert, die dem Blob zugeordnet ist, und wird durch einen Aufruf Get Blob Propertiesvon zurückgegeben. Wenn der Client den Content-Type-Header für die Anforderung festlegt, wird dieser Wert in der x-ms-blob-content-type-Eigenschaft des BLOB gespeichert.

  • Wenn der Client sowohl den HTTP-Standardheader als auch den entsprechenden Eigenschaftenheader für dieselbe Anforderung festlegt, verwendet die PUT-Anforderung den Wert, der für den HTTP-Standardheader bereitgestellt wird, aber der für den header der benutzerdefinierten Eigenschaft angegebene Wert wird mit dem Blob beibehalten und von nachfolgenden GET-Anforderungen zurückgegeben.

Wenn Tags im x-ms-tags Header bereitgestellt werden, müssen sie abfragezeichenfolgencodiert sein. Tagschlüssel und -werte müssen den in Set Blob Tagsangegebenen Benennungs- und Längenanforderungen entsprechen. Darüber hinaus kann der x-ms-tags Header bis zu 2 KB an Tags enthalten. Wenn weitere Tags erforderlich sind, verwenden Sie den Vorgang Blobtags festlegen .

Wenn das Blob über eine aktive Lease verfügt, muss der Client für die Anforderung zum Überschreiben des Blobs eine gültige Lease-ID angeben. Wenn der Client keine Lease-ID angibt oder eine ungültige Lease-ID angibt, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück. Wenn der Client eine Lease-ID angibt, das Blob jedoch nicht über eine aktive Lease verfügt, gibt Blob Storage auch status Code 412 (Vorbedingung fehlgeschlagen) zurück. Wenn der Client eine Lease-ID für ein Blob angibt, das noch nicht vorhanden ist, gibt Blob Storage status Code 412 (Vorbedingungsfehler) für Anforderungen zurück, die für Die Version 2013-08-15 und höher gestellt wurden. Für Versionen vor 2013-08-15 gibt Blob Storage status Code 201 (Erstellt) zurück.

Wenn ein vorhandenes Blob mit einer aktiven Lease durch einen Put Blob Vorgang überschrieben wird, bleibt die Lease für das aktualisierte Blob erhalten, bis sie abläuft oder freigegeben wird.

Ein Put Blob Vorgang ist 10 Minuten pro MiB zulässig. Wenn der Vorgang im Durchschnitt länger als 10 Minuten pro MiB dauert, ist das Zeitüberschreitungsout des Vorgangs.

Das Überschreiben eines archive Blobs schlägt fehl, und das Überschreiben eines hot oder cool Blobs erbt die Ebene vom alten Blob, wenn x-ms-access-tier kein Header bereitgestellt wird.

ExpiryOption

Sie können die folgenden Werte als x-ms-expiry-option Header senden. Bei diesem Header wird die Groß-/Kleinschreibung nicht beachtet.

Ablaufoption BESCHREIBUNG
RelativeToNow Legt das Ablaufdatum relativ zur aktuellen Zeit fest. x-ms-expiry-time muss als Anzahl von Millisekunden angegeben werden, die ab der aktuellen Zeit verstreichen sollen.
Absolute x-ms-expiry-time muss als absolute Zeit im RFC 1123-Format angegeben werden.
NeverExpire Legt fest, dass das Blob nie abläuft, oder entfernt das aktuelle Ablaufdatum. x-ms-expiry-time darf nicht angegeben werden.

Die Semantik zum Festlegen eines Ablaufdatums für ein Blob lautet wie folgt:

  • Set Expiry kann nur für ein Blob und nicht für ein Verzeichnis festgelegt werden.
  • Set Expiry mit einem expiryTime in der Vergangenheit ist nicht zulässig.
  • ExpiryTime kann nicht mit dem expiryOption Wert angegeben Neverwerden.

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. Für diese Anforderungen fallen Gebühren pro Transaktion an. Die Art der Transaktion wirkt sich auf die Belastung des Kontos aus. Beispielsweise werden Lesetransaktionen in eine andere Abrechnungskategorie als das Schreiben von Transaktionen angewendet. Die folgende Tabelle zeigt die Abrechnungskategorie für Put Blob Anforderungen basierend auf dem Speicherkontotyp:

Vorgang Speicherkontotyp Abrechnungskategorie
Put Blob Premium, Blockblob
Standard „Allgemein v2“
Standard „Allgemein v1“		 Schreibvorgänge

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

Weitere Informationen

Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Fehlercodes des Blobdiensts
Festlegen von Timeouts für Blobdienstvorgänge