Freigeben über

Get Blob

  • Artikel

Der Get Blob-Vorgang liest oder lädt ein BLOB vom System herunter, einschließlich der zugehörigen Metadaten und Eigenschaften. Sie können auch Get Blob aufrufen, um eine Momentaufnahme zu lesen.

Anforderung

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

GET-Methodenanforderungs-URI HTTP-Version
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>

 HTTP/1.0

HTTP/1.1

Emulierter Speicherdienst-URI

Wenn Sie eine Anforderung an den emulierten Speicherdienst stellen, geben Sie den Emulatorhostnamen und Azure Blob Storage Port als 127.0.0.1:10000an, gefolgt vom Namen des emulierten Speicherkontos:

GET-Methodenanforderungs-URI HTTP-Version
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob HTTP/1.0

HTTP/1.1

Weitere Informationen finden Sie unter Verwenden des Azure-Speicheremulators für Entwicklung und Tests.

URI-Parameter

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

Parameter BESCHREIBUNG
snapshot Optional. Der parameter Momentaufnahme ist ein undurchsichtiger DateTime Wert, der, wenn er vorhanden ist, die abzurufende Blob-Momentaufnahme angibt. Weitere Informationen zum Arbeiten mit Blobmomentaufnahmen finden Sie unter Create einer Momentaufnahme eines Blobs.
versionid Optional, Version 2019-12-12 und höher. Der versionid Parameter ist ein undurchsichtiger DateTime Wert, der, sofern vorhanden, die Version des abzurufenden Blobs angibt.
timeout Optional. Der timeout-Parameter wird in Sekunden angegeben. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob Storage-Vorgänge.

Anforderungsheader

In der folgenden Tabelle werden erforderliche und optionale Anforderungsheader 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. Optional für anonyme Anforderungen. Gibt die Version des für die Anforderung zu verwendenden Vorgangs an. Wenn dieser Header für eine anonyme Anforderung weggelassen wird, führt der Dienst die Anforderung mit Version 2009-09-19 aus. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.
Range Optional. Gibt die Bytes des Blobs nur im angegebenen Bereich zurück.
x-ms-range Optional. Gibt die Bytes des Blobs nur im angegebenen Bereich zurück. Wenn Range und x-ms-range angegeben werden, verwendet der Dienst den Wert x-ms-range. Wenn kein Bereich angegeben wird, wird der gesamte Blobinhalt zurückgegeben. Weitere Informationen finden Sie unter Angeben des Bereichsheaders für Blob Storage-Vorgänge.
x-ms-lease-id: <ID> Optional. Wenn dieser Header angegeben ist, wird der Vorgang nur ausgeführt, wenn beide der folgenden Bedingungen erfüllt sind:

– Die Lease des Blobs ist derzeit aktiv.
– Die in der Anforderung angegebene Lease-ID entspricht der Lease-ID des Blobs.

Wenn dieser Header angegeben ist, aber eine dieser Bedingungen nicht erfüllt ist, schlägt die Anforderung fehl, und der Get Blob Vorgang schlägt mit status Code 412 (Vorbedingung fehlgeschlagen) fehl.
x-ms-range-get-content-md5: true Optional. Wenn dieser Header auf true festgelegt und zusammen mit dem Range Header angegeben wird, gibt der Dienst den MD5-Hash für den Bereich zurück, sofern der Bereich kleiner als oder gleich 4 Mebibytes (MiB) ist.

Wenn der Header ohne den Range Header angegeben wird, gibt der Dienst status Code 400 (Ungültige Anforderung) zurück.

Wenn der Header auf true festgelegt ist, wenn der Bereich 4 MiB überschreitet, gibt der Dienst status Code 400 (Ungültige Anforderung) zurück.
x-ms-range-get-content-crc64: true Optional. Wenn dieser Header auf true festgelegt und zusammen mit dem Range Header angegeben wird, gibt der Dienst den CRC64-Hash für den Bereich zurück, solange der Bereich kleiner als oder gleich 4 MiB ist.

Wenn der Header ohne den Range Header angegeben wird, gibt der Dienst status Code 400 (Ungültige Anforderung) zurück.

Wenn der Header auf true festgelegt ist, wenn der Bereich 4 MiB überschreitet, gibt der Dienst status Code 400 (Ungültige Anforderung) zurück.

Wenn sowohl der -Header als x-ms-range-get-content-crc64 auch der x-ms-range-get-content-md5 -Header vorhanden sind, schlägt die Anforderung mit einer 400 (ungültige Anforderung) fehl.

Dieser Header wird in Versionen 2019-02-02 und höher unterstützt.
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.
x-ms-upn Optional. Version 2023-11-03 und höher. Gültig für Konten mit aktiviertem hierarchischem Namespace. Wenn true, werden die Benutzeridentitätswerte, die in den x-ms-ownerAntwortheadern und x-ms-groupx-ms-acl zurückgegeben werden, von Microsoft Entra Objekt-IDs in Benutzerprinzipalnamen transformiert. Wenn der Wert false ist, werden sie als Microsoft Entra Objekt-IDs zurückgegeben. Der Standardwert ist false. Beachten Sie, dass Gruppen- und Anwendungsobjekt-IDs nicht übersetzt werden, da sie keine eindeutigen Anzeigenamen haben.
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 der Speicheranalyse aktiviert ist. Es wird dringend empfohlen, diesen Header zu verwenden, wenn Sie clientseitige Aktivitäten mit Anforderungen korrelieren, die vom Server empfangen werden. Weitere Informationen finden Sie unter Informationen zur Azure-Storage Analytics-Protokollierung.

Dieser Vorgang unterstützt zudem die Verwendung von bedingten Headern zum Lesen des BLOB. Hierfür muss jedoch eine angegebene Bedingung erfüllt sein. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Blob Storage-Vorgänge.

Anforderungsheader (vom Kunden bereitgestellte Verschlüsselungsschlüssel)

Ab Version 2019-02-02 können Sie die folgenden Header für die Anforderung angeben, um ein Blob zu lesen, das mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt ist. Die Verschlüsselung mit einem vom Kunden bereitgestellten Schlüssel (und dem entsprechenden Satz von Headern) ist optional. Wenn ein Blob zuvor mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt wurde, müssen Sie diese Header in die Anforderung einschließen, um den Lesevorgang erfolgreich abzuschließen.

Anforderungsheader BESCHREIBUNG
x-ms-encryption-key Erforderlich. Der Base64-codierte AES-256-Verschlüsselungsschlüssel.
x-ms-encryption-key-sha256 Optional. 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

Keine.

Antwort

Die Antwort enthält einen HTTP-Statuscode, eine Gruppe von Antwortheadern und den Antworttext, der den Inhalt des BLOB enthält.

Statuscode

Wenn der BLOB vollständig gelesen wird, wird der Statuscode 200 (OK) zurückgegeben.

Wenn ein bestimmter Bereich erfolgreich gelesen wird, wird der Statuscode 206 (Teilweiser Inhalt) 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.

Syntax BESCHREIBUNG
Last-Modified Das Datum/die Uhrzeit der letzten Änderung des Blobs. Das Datumsformat entspricht RFC 1123.

Durch jeden Vorgang, der das BLOB ändert, einschließlich eines Updates der Metadaten oder Eigenschaften des BLOB, wird die Uhrzeit der letzten Änderung aktualisiert.
x-ms-creation-time Version 2017-11-09 und höher. Das Datum/die Uhrzeit der Erstellung des Blobs. Das Datumsformat entspricht RFC 1123.
x-ms-meta-name:value Eine Gruppe von Name-Wert-Paaren, die diesem Blob als benutzerdefinierte Metadaten zugeordnet sind.
x-ms-tag-count Version 2019-12-12 und höher. Wenn das Blob Über Tags verfügt, gibt dieser Header die Anzahl der Tags zurück, die im Blob gespeichert sind. Der Header wird nicht zurückgegeben, wenn im Blob keine Tags vorhanden sind.
Content-Length Die Anzahl der im Antworttext vorhandenen Bytes.
Content-Type Der Inhaltstyp, der für das Blob angegeben wird. Der Standardinhaltstyp ist application/octet-stream.
Content-Range Gibt den Bytebereich an, der zurückgegeben wird, wenn der Client durch Festlegen Range des Anforderungsheaders eine Teilmenge des Blobs angefordert hat.
ETag Enthält einen Wert, den Sie zum bedingten Ausführen von Vorgängen verwenden können. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Blob Storage-Vorgänge. Wenn die Anforderungsversion 2011-08-18 oder höher ist, wird der ETag-Wert in Anführungszeichen eingeschlossen.
Content-MD5 Wenn das BLOB über einen MD5-Hash verfügt und bei dem Get Blob-Vorgang das vollständige BLOB gelesen werden soll, wird dieser Antwortheader zurückgegeben, sodass der Client die Integrität des Nachrichteninhalts überprüfen kann.

Legt in Version 2012-02-12 und höher den MD5-Hashwert eines Blockblobs fest, Put Blob auch wenn die Put Blob Anforderung keinen MD5-Header enthält.

Wenn die Anforderung einen angegebenen Bereich lesen soll und auf x-ms-range-get-content-md5 festgelegt trueist, gibt die Anforderung einen MD5-Hash für den Bereich zurück, solange die Bereichsgröße kleiner als oder gleich 4 MiB ist.

Wenn keine dieser Bedingungssätze lautet, wird truekein Wert für den Content-MD5 -Header zurückgegeben.

Wenn x-ms-range-get-content-md5 ohne den Range-Header angegeben wird, gibt der Dienst Statuscode 400 (Ungültige Anforderung) zurück.

Wenn x-ms-range-get-content-md5 auf true festgelegt ist, wenn der Bereich 4 MiB überschreitet, gibt der Dienst status Code 400 (ungültige Anforderung) zurück.
x-ms-content-crc64 Wenn die Anforderung einen angegebenen Bereich lesen soll und auf x-ms-range-get-content-crc64 festgelegt trueist, gibt die Anforderung einen CRC64-Hash für den Bereich zurück, solange die Bereichsgröße kleiner als oder gleich 4 MiB ist.

Wenn x-ms-range-get-content-crc64 ohne den Range-Header angegeben wird, gibt der Dienst Statuscode 400 (Ungültige Anforderung) zurück.

Wenn x-ms-range-get-content-crc64 auf true festgelegt ist, wenn der Bereich 4 MiB überschreitet, gibt der Dienst status Code 400 (ungültige Anforderung) zurück.
Content-Encoding Gibt den Wert zurück, der für den Anforderungsheader Content-Encoding angegeben wurde.
Content-Language Gibt den Wert zurück, der für den Anforderungsheader Content-Language angegeben wurde.
Cache-Control Wird zurückgegeben, wenn der Header zuvor für das Blob angegeben wurde.
Content-Disposition Wird für Anforderungen an die Version 2013-08-15 und höher zurückgegeben. Dieser Header gibt den Wert zurück, der für den x-ms-blob-content-disposition-Header angegeben wurde.

Das Content-Disposition Antwortheaderfeld enthält zusätzliche Informationen zur Verarbeitung der Antwortnutzlast und kann zum Anfügen zusätzlicher Metadaten verwendet werden. Wenn der Header beispielsweise auf attachmentfestgelegt ist, gibt dies an, dass der Benutzer-Agent die Antwort nicht anzeigen soll. Stattdessen wird ein Dialogfeld Speichern unter mit einem anderen Dateinamen als dem angegebenen Blobnamen angezeigt.
x-ms-blob-sequence-number Die aktuelle Sequenznummer für ein Seitenblob.

Dieser Header wird nicht für Blockblobs oder Anfügeblobs zurückgegeben.
x-ms-blob-type: <BlockBlob | PageBlob | AppendBlob> Gibt den Typ des BLOB zurück.
x-ms-copy-completion-time: <datetime> Version 2012-02-12 und höher. Die Abschlusszeit des letzten versuchten Copy Blob Vorgangs, bei dem dieses Blob das Zielblob war. Dieser Wert kann die Zeit eines abgeschlossenen, abgebrochenen oder fehlgeschlagenen Kopierversuchs angeben. Dieser Header wird nicht angezeigt, wenn eine Kopie aussteht, wenn dieses Blob noch nie das Ziel in einem Copy Blob Vorgang war oder wenn dieses Blob nach einem abgeschlossenen Copy Blob Vorgang geändert wurde, der , Put Bloboder Put Block Listverwendet Set Blob Propertieshat.
x-ms-copy-status-description: <error string> Version 2012-02-12 und höher. Wird nur angezeigt, wenn x-ms-copy-status oder pendingistfailed. Beschreibt die Ursache des letzten schwerwiegenden oder nicht schwerwiegenden Fehlers eines Kopiervorgangs. Dieser Header wird nicht angezeigt, wenn dieses Blob noch nie das Ziel in einem Copy Blob Vorgang war oder wenn dieses Blob nach einem abgeschlossenen Copy Blob Vorgang geändert wurde, der , Put Bloboder Put Block Listverwendet Set Blob Propertieshat.
x-ms-copy-id: <id> Version 2012-02-12 und höher. Ein Zeichenfolgenbezeichner für den letzten versuchten Copy Blob Vorgang, bei dem dieses Blob das Zielblob war. Dieser Header wird nicht angezeigt, wenn dieses Blob noch nie das Ziel in einem Copy Blob Vorgang war oder wenn dieses Blob nach einem abgeschlossenen Copy Blob Vorgang geändert wurde, der , Put Bloboder Put Block Listverwendet Set Blob Propertieshat.
x-ms-copy-progress: <bytes copied/bytes total> Version 2012-02-12 und höher. Enthält die Anzahl der kopierten Bytes und die Gesamtbytes in der Quelle im letzten versuchten Copy Blob Vorgang, bei dem dieses Blob das Zielblob war. Es kann von 0 bis zu Content-Length kopierten Bytes angezeigt werden. Dieser Header wird nicht angezeigt, wenn dieses Blob noch nie das Ziel in einem Copy Blob Vorgang war oder wenn dieses Blob nach einem abgeschlossenen Copy Blob Vorgang geändert wurde, der , Put Bloboder Put Block Listverwendet Set Blob Propertieshat.
x-ms-copy-source: url Version 2012-02-12 und höher. Eine URL mit einer Länge von bis zu 2 KiB, die das Quellblob oder die Datei angibt, das bzw. die im letzten versuchten Copy Blob Vorgang verwendet wurde, wobei dieses Blob das Zielblob war. Dieser Header wird nicht angezeigt, wenn dieses Blob noch nie das Ziel in einem Copy Blob Vorgang war oder wenn dieses Blob nach einem abgeschlossenen Copy Blob Vorgang geändert wurde, der , Put Bloboder Put Block Listverwendet Set Blob Propertieshat.

Die url, die in diesem Header zurückgegeben wird, enthält alle Anforderungsparameter, die beim Kopiervorgang für das Quellblob verwendet wurden, einschließlich des SAS-Tokens (Shared Access Signature), das für den Zugriff auf das Quellblob verwendet wurde.
x-ms-copy-status: <pending | success | aborted | failed> Version 2012-02-12 und höher. Der Status des Kopiervorgangs, der durch x-ms-copy-id identifiziert wird, mit den folgenden Werten:

- success: Der Kopiervorgang wurde erfolgreich abgeschlossen.
- pending: Das Kopieren wird ausgeführt. Überprüfen Sie x-ms-copy-status-description , ob zeitweilige, nicht schwerwiegende Fehler den Kopierfortschritt verlangsamen, aber keinen Fehler verursachen.
- aborted: Der Kopiervorgang wurde durch Abort Copy Blobbeendet.
- failed: Fehler beim Kopieren. Fehlerdetails finden Sie unter x-ms-copy-status-description.

Dieser Header wird nicht angezeigt, wenn dieses Blob noch nie das Ziel in einem Copy Blob Vorgang war oder wenn dieses Blob nach einem abgeschlossenen Copy Blob Vorgang geändert wurde, der , Put Bloboder Put Block Listverwendet Set Blob Propertieshat.
x-ms-lease-duration: <infinite | fixed> Version 2012-02-12 und höher. Gibt für ein geleastes BLOB an, ob die Lease von unbegrenzter oder fester Dauer ist.
x-ms-lease-state: <available | leased | expired | breaking | broken> Version 2012-02-12 und höher. Der Leasestatus des Blobs.
x-ms-lease-status:<locked | unlocked> Der aktuelle Leasestatus des BLOB.
x-ms-request-id Identifiziert die durchgeführte Anforderung eindeutig und kann zur Problembehandlung für die Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.
x-ms-version Gibt die Blob Storage-Version an, die zum Ausführen der Anforderung verwendet wurde. Enthalten für Anforderungen, die mit Version 2009-09-19 und höher vorgenommen wurden.

Dieser Header wird auch für anonyme Anforderungen ohne angegebene Version zurückgegeben, wenn der Container mit Blob Storage-Version 2009-09-19 für öffentlichen Zugriff markiert wurde.
Accept-Ranges: bytes Gibt an, dass der Dienst Anforderungen für teilweisen BLOB-Inhalt unterstützt. Enthalten für Anforderungen, die mit Version 2011-08-18 und höher erstellt werden, und für den lokalen Speicherdienst in SDK-Version 1.6 und höher.
Date Ein UTC-Datums-/Uhrzeitwert, der vom Dienst generiert wird, der den Zeitpunkt angibt, zu dem 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 Origin-Anforderungsheaders im Falle einer Übereinstimmung zurück.
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.
Vary Wird mit dem Wert des Origin-Headers zurückgegeben, wenn CORS-Regeln angegeben werden. Weitere Informationen finden Sie unter CORS-Unterstützung für die Azure Storage-Dienste .
Access-Control-Allow-Credentials Wird zurückgegeben, wenn die Anforderung einen Origin Header enthält und CORS mit einer Abgleichsregel aktiviert ist, die nicht alle Ursprünge zulässt. Dieser Header wird auf truefestgelegt.
x-ms-blob-committed-block-count Die Anzahl der committeten Blöcke, die im Blob vorhanden sind. Dieser Header wird nur für Anfügeblobs zurückgegeben.
x-ms-server-encrypted: true/false Version 2015-12-11 und höher. Der Wert dieses Headers wird auf true festgelegt, wenn die Blobdaten und Anwendungsmetadaten mit dem angegebenen Algorithmus vollständig verschlüsselt werden. Andernfalls wird der Wert auf false festgelegt (wenn das Blob unverschlüsselt ist oder wenn nur Teile der Blob- oder Anwendungsmetadaten verschlüsselt werden).
x-ms-encryption-key-sha256 Version 2019-02-02 und höher. Dieser Header wird zurückgegeben, wenn das Blob mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt ist.
x-ms-encryption-context Version 2021-08-06 und höher. Wenn der Wert der Verschlüsselungskontexteigenschaft festgelegt ist, wird der Festgelegtwert zurückgegeben. Gültig nur, wenn hierarchischer Namespace für das Konto aktiviert ist.
x-ms-encryption-scope Version 2019-02-02 und höher. Dieser Header wird zurückgegeben, wenn das Blob mit einem Verschlüsselungsbereich verschlüsselt ist.
x-ms-blob-content-md5 Version 2016-05-31 und höher. Wenn das Blob über einen MD5-Hash verfügt und die Anforderung einen Bereichsheader (Range oder x-ms-range) enthält, wird dieser Antwortheader mit dem Wert des MD5-Werts des gesamten Blobs zurückgegeben. Dieser Wert kann gleich dem Wert sein, der im Content-MD5-Header zurückgegeben wird, wobei letzterer aus dem angeforderten Bereich berechnet wird.
x-ms-client-request-id Kann verwendet werden, um Anforderungen und entsprechende 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 dieser Header in der Antwort nicht vorhanden.
x-ms-last-access-time Version 2020-02-10 und höher. Gibt den letzten Zeitpunkt an, zu dem auf die Daten des Blobs zugegriffen wurde, basierend auf der Richtlinie zur Nachverfolgung der letzten Zugriffszeit des Speicherkontos. Der Header wird nicht zurückgegeben, wenn das Speicherkonto nicht über eine Richtlinie zur Nachverfolgung der letzten Zugriffszeit verfügt oder wenn die Richtlinie deaktiviert ist. Informationen zum Festlegen der Richtlinie für die Nachverfolgung der letzten Zugriffszeit des Speicherkontos finden Sie unter Blob Service-API.
x-ms-blob-sealed Version 2019-12-12 und höher. Wird nur für Anfügeblobs zurückgegeben. Wenn das Anfügeblob versiegelt wurde, lautet trueder Wert . Weitere Informationen finden Sie unter Anfügen eines Blobsiegels.
x-ms-immutability-policy-until-date Version 2020-06-12 und höher. Gibt die Aufbewahrung bis zum Datum an, das für das Blob festgelegt ist. Dies ist das Datum, bis zu dem das Blob vor Änderungen oder Löschungen geschützt werden kann. Wird nur zurückgegeben, wenn eine Unveränderlichkeitsrichtlinie für das Blob festgelegt ist. Der Wert dieses Headers hat RFC1123 Format.
x-ms-immutability-policy-mode: unlocked/locked Version 2020-06-12 und höher. Wird zurückgegeben, wenn eine Unveränderlichkeitsrichtlinie für das Blob festgelegt ist. Die Werte sind unlocked und locked. unlocked gibt an, dass der Benutzer die Richtlinie ändern kann, indem er die Aufbewahrung bis zum Datum erhöht oder verringert. locked gibt an, dass diese Aktionen verboten sind.
x-ms-legal-hold: true/false Version 2020-06-12 und höher. Dieser Header wird nicht zurückgegeben, wenn für das Blob kein gesetzlicher Haltestand vorhanden ist. Der Wert dieses Headers wird auf true festgelegt, wenn das Blob einen legalen Halteraum enthält und sein Wert ist true. Andernfalls wird der Wert auf false festgelegt, wenn das Blob einen legalen Halteraum enthält und sein Wert ist false.
x-ms-owner Version 2020-06-12 und höher, nur für Konten mit aktiviertem hierarchischen Namespace. Gibt den Besitzer-Benutzer der Datei oder des Verzeichnisses zurück.
x-ms-group Version 2020-06-12 und höher, nur für Konten mit aktiviertem hierarchischen Namespace. Gibt die besitzende Gruppe der Datei oder des Verzeichnisses zurück.
x-ms-permissions Version 2020-06-12 und höher, nur für Konten mit aktiviertem hierarchischen Namespace. Gibt die Berechtigungen zurück, die für Benutzer, Gruppe und andere für die Datei oder das Verzeichnis festgelegt sind. Jede einzelne Berechtigung hat ein [r,w,x,-]{3} Format.
x-ms-acl Version 2023-11-03 und höher. Nur für Konten mit aktiviertem hierarchischen Namespace. Gibt die kombinierte Liste der Zugriffs- und Standardzugriffssteuerungsliste zurück, die für Benutzer, Gruppe und andere in der Datei oder dem Verzeichnis festgelegt sind. Jeder Zugriffssteuerungseintrag (Access Control Entry, ACE) besteht aus einem Bereich, einem Typ, einem Benutzer- oder Gruppenbezeichner und Berechtigungen im Format [scope]:[type]:[id]:[permissions]. Der default Bereich gibt an, dass der ACE zur Standard-ACL für ein Verzeichnis gehört. Andernfalls ist der Bereich implizit, und der ACE gehört zur Zugriffs-ACL. Jede einzelne Berechtigung hat ein [r,w,x,-]{3} Format.
x-ms-resource-type Version 2020-10-02 und höher, nur für Konten mit aktiviertem hierarchischen Namespace. Gibt den Ressourcentyp für den Pfad zurück, der entweder file oder sein directorykann.

Antworttext

Der Antworttext enthält den Inhalt des BLOB.

Beispiel für eine Antwort

Status Response:  
HTTP/1.1 200 OK  
  
Response Headers:  
x-ms-blob-type: BlockBlob  
x-ms-lease-status: unlocked  
x-ms-lease-state: available  
x-ms-meta-m1: v1  
x-ms-meta-m2: v2  
Content-Length: 11  
Content-Type: text/plain; charset=UTF-8  
Date: <date>  
ETag: "0x8CB171DBEAD6A6B"  
Vary: Origin  
Last-Modified: <date>  
x-ms-version: 2015-02-21  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-copy-id: 36650d67-05c9-4a24-9a7d-a2213e53caf6  
x-ms-copy-source: <url>  
x-ms-copy-status: success  
x-ms-copy-progress: 11/11  
x-ms-copy-completion-time: <date>

Authorization

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

Wichtig

Microsoft empfiehlt die Verwendung Microsoft Entra ID mit verwalteten Identitäten, um Anforderungen an Azure Storage zu autorisieren. Microsoft Entra ID bietet im Vergleich zur Autorisierung mit gemeinsam genutzten Schlüsseln überlegene Sicherheit und Benutzerfreundlichkeit.

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

Nachfolgend sind die RBAC-Aktion aufgeführt, die für einen Microsoft Entra Benutzer, Gruppe, verwaltete Identität oder Dienstprinzipal erforderlich ist, um den Get 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

Für ein Seitenblob werden von einem Get Blob-Vorgang über einen Bereich von Seiten, die noch keinen Inhalt aufweisen oder gelöscht wurden, Nullen für diese Bytes zurückgegeben.

Wenn Sie ein Seitenblob ohne angegebenen Bereich aufrufen Get Blob , gibt der Dienst den Bereich der Seiten bis zum angegebenen Wert für den x-ms-blob-content-length Header zurück. Für alle Seiten ohne Inhalt gibt der Dienst Nullen für diese Bytes zurück.

Bei einem Anfügeblob gibt der Get Blob Vorgang den x-ms-blob-committed-block-count Header zurück. Dieser Header gibt die Anzahl der committeten Blöcke im Blob an. Der x-ms-blob-committed-block-count Header wird nicht für Blockblobs oder Seitenblobs zurückgegeben.

Ein Get Blob Vorgang darf zwei Minuten pro MiB abgeschlossen werden. Wenn der Vorgang im Durchschnitt länger als zwei Minuten pro MiB dauert, tritt für den Vorgang ein Timeout auf.

Der x-ms-version-Header ist erforderlich, um ein BLOB abzurufen, das zu einem privaten Container gehört. Wenn das Blob zu einem Container gehört, der für den vollständigen oder teilweisen öffentlichen Zugriff verfügbar ist, kann es von jedem Client gelesen werden, ohne eine Version anzugeben. Die Dienstversion ist nicht erforderlich, um ein Blob abzurufen, das zu einem öffentlichen Container gehört. Weitere Informationen finden Sie unter Beschränken des Zugriffs auf Container und Blobs.

Ein Get Blob Vorgang für ein archiviertes Blockblob schlägt fehl.

Kopiervorgänge

Um zu ermitteln, ob ein Copy Blob Vorgang abgeschlossen wurde, überprüfen Sie zunächst, ob der x-ms-copy-id Headerwert des Zielblobs der Kopier-ID entspricht, die vom ursprünglichen Aufruf Copy Blobvon bereitgestellt wurde. Eine Übereinstimmung stellt sicher, dass eine andere Anwendung die Kopie nicht abbricht und einen neuen Copy Blob Vorgang startet. Suchen Sie als Nächstes nach dem x-ms-copy-status: success Header. Beachten Sie jedoch, dass alle Schreibvorgänge für ein Blob außer Lease, Put Pageund Put Block alle x-ms-copy-* Eigenschaften aus dem Blob entfernen. Diese Eigenschaften werden auch nicht von Copy Blob Vorgängen kopiert, die Blob Storage-Versionen vor 2012-02-12 verwenden.

Warnung

Die URL, die x-ms-copy-source im Header zurückgegeben wird, enthält alle Anforderungsparameter, die beim Kopiervorgang für das Quellblob verwendet wurden. Wenn Sie ein SAS-Token für den Zugriff auf das Quellblob verwenden, wird dieses SAS-Token im x-ms-copy-source Header angezeigt, wenn Get Blob im Zielblob aufgerufen wird.

Wenn x-ms-copy-status: failed in der Antwort angezeigt wird, enthält x-ms-copy-status-description weitere Informationen zum Copy Blob-Fehler.

Die drei Felder jedes x-ms-copy-status-description Werts werden in der folgenden Tabelle beschrieben:

Komponente BESCHREIBUNG
HTTP-Statuscode Eine standardmäßige dreistellige ganzzahlige Zahl, die den Fehler angibt.
Fehlercode Eine Schlüsselwort (keyword), die den Fehler beschreibt, der von Azure im <ErrorCode-Element> bereitgestellt wird. Wenn kein <ErrorCode-Element> angezeigt wird, wird ein Schlüsselwort (keyword) verwendet, der Standardfehlertext enthält, der dem 3-stelligen HTTP-status Code in der HTTP-Spezifikation zugeordnet ist. Weitere Informationen finden Sie unter Allgemeine REST-API-Fehlercodes.
Information Eine detaillierte Beschreibung des Fehlers, in Anführungszeichen eingeschlossen.

Die x-ms-copy-status Werte und x-ms-copy-status-description allgemeiner Fehlerszenarien werden in der folgenden Tabelle beschrieben:

Wichtig

Die Fehlerbeschreibungen in dieser Tabelle können sich ohne Warnung ändern, auch ohne Versionsänderung, sodass sie möglicherweise nicht genau mit Ihrem Text übereinstimmen.

Szenario x-ms-copy-status-Wert x-ms-copy-status-description-Wert
Der Kopiervorgang wurde erfolgreich abgeschlossen. success empty
Der Kopiervorgang wurde vom Benutzer abgebrochen. aborted empty
Beim Lesen aus dem Quell-BLOB während eines Kopiervorgangs ist ein Fehler aufgetreten, der Vorgang wird jedoch wiederholt. pending 502 BadGateway "Wiederholbarer Fehler beim Lesen der Quelle. Es wird versucht, den Vorgang zu wiederholen. Fehlerzeit: <Zeit>"
Beim Schreiben in das Ziel-BLOB eines Kopiervorgangs ist ein Fehler aufgetreten, der Vorgang wird jedoch wiederholt. pending 500 InternalServerError "Wiederholbarer Fehler. Es wird versucht, den Vorgang zu wiederholen. Fehlerzeit: <Zeit>"
Beim Lesen aus dem Quell-BLOB eines Kopiervorgangs ist ein nicht behebbarer Fehler aufgetreten. „Fehlgeschlagen“ 404 ResourceNotFound "Fehler beim Kopieren während des Lesens der Quelle."

Hinweis: Wenn der Dienst diesen zugrunde liegenden Fehler meldet, wird er im ErrorCode -Element zurückgegebenResourceNotFound. Wenn in der Antwort kein ErrorCode Element angezeigt wird, wird eine Standardzeichenfolgendarstellung des HTTP-status angezeigt, zNotFound. B. .
Das Timeout, das alle Kopiervorgänge einschränkt, ist abgelaufen. (Derzeit beträgt das Timeout 2 Wochen.) „Fehlgeschlagen“ 500 OperationCancelled "Die maximal zulässige Zeit für den Kopiervorgang wurde überschritten."
Der Kopiervorgang ist beim Lesen aus der Quelle zu oft fehlgeschlagen und hat kein Mindestverhältnis von Versuchen zu Erfolgen erfüllt. (Dieses Timeout verhindert, dass eine sehr schlechte Quelle über zwei Wochen wiederholt wird, bevor ein Fehler auftritt.) „Fehlgeschlagen“ 500 OperationCancelled "Fehler beim Kopieren während des Lesens der Quelle."

x-ms-last-access-time verfolgt den Zeitpunkt nach, zu dem auf die Daten des Blobs zugegriffen wurde, basierend auf der Richtlinie zur Nachverfolgung der letzten Zugriffszeit des Speicherkontos. Der Zugriff auf die Metadaten eines Blobs ändert nicht die Uhrzeit des letzten Zugriffs.

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 Get Blob Anforderungen basierend auf dem Speicherkontotyp:

Vorgang Speicherkontotyp Abrechnungskategorie
Get Blob Premium, Blockblob
Standard „Allgemein v2“
Standard „Allgemein v1“		 Dient zum Lesen von Vorgängen.

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
Blob Storage-Fehlercodes
Festlegen von Timeouts für Blob Storage-Vorgänge