Get Blob

Artikel
02/03/2024

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-owner`Antwortheadern 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 `true`ist, 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 `true`kein 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 `true`ist, 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 `attachment`festgelegt 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 Blob`oder `Put Block List`verwendet `Set Blob Properties`hat.
`x-ms-copy-status-description: <error string>`	Version 2012-02-12 und höher. Wird nur angezeigt, wenn `x-ms-copy-status` oder `pending`ist`failed`. 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 Blob`oder `Put Block List`verwendet `Set Blob Properties`hat.
`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 Blob`oder `Put Block List`verwendet `Set Blob Properties`hat.
`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 Blob`oder `Put Block List`verwendet `Set Blob Properties`hat.
`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 Blob`oder `Put Block List`verwendet `Set Blob Properties`hat. 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 Blob`beendet. - `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 Blob`oder `Put Block List`verwendet `Set Blob Properties`hat.
`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 `true`festgelegt.
`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 `true`der 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 `directory`kann.

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:

Azure RBAC-Aktion:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Integrierte Rolle mit den geringsten Berechtigungen:Speicherblobdatenleser

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

Eine SAS (Shared Access Signature) bietet sicheren delegierten Zugriff auf Ressourcen in einem Speicherkonto. Mit einer SAS haben Sie eine präzise Kontrolle darüber, wie ein Client auf Daten zugreifen kann. Sie können angeben, auf welche Ressource der Client zugreifen darf, welche Berechtigungen er für diese Ressourcen hat und wie lange die SAS gültig ist.

Der Get Blob Vorgang unterstützt drei Arten von Shared Access Signaturen: Benutzerdelegierungs-SAS, Dienst-SAS und Konto-SAS.

Als bewährte Sicherheitsmethode wird empfohlen, Microsoft Entra Anmeldeinformationen anstelle des Speicherkontoschlüssels zu verwenden, der leichter kompromittiert werden kann. Wenn Ihr Anwendungsentwurf Shared Access Signatures erfordert, verwenden Sie nach Möglichkeit Microsoft Entra Anmeldeinformationen, um eine SAS für die Benutzerdelegierung zu erstellen.

Wenn der Zugriff auf freigegebene Schlüssel für das Speicherkonto nicht zulässig ist, wird ein SAS-Diensttoken oder ein Konto-SAS-Token für eine Anforderung an Blob Storage nicht zulässig. Weitere Informationen finden Sie unter Grundlegendes dazu, wie sich das Aufheben der Zuordnung von freigegebenem Schlüssel auf SAS-Token auswirkt.

SAS für die Benutzerdelegierung

Eine Benutzerdelegierungs-SAS wird mit Microsoft Entra Anmeldeinformationen und auch durch die für die SAS angegebenen Berechtigungen geschützt.

Für das Aufrufen des Get Blob Vorgangs mithilfe eines SAS-Tokens, das an einen Container oder eine Blobressource delegiert wurde, ist die Berechtigung Lesen (r) als Teil des SAS-Tokens der Benutzerdelegierung erforderlich.

Weitere Informationen zur BENUTZERdelegierungs-SAS finden Sie unter Create einer Benutzerdelegierungs-SAS.

Dienst-SAS

Eine Dienst-SAS wird mit dem Speicherkontoschlüssel geschützt. Eine Dienst-SAS delegiert den Zugriff auf eine Ressource in einem einzelnen Azure Storage-Dienst, z. B. Blob Storage.

Für das Aufrufen des Get Blob Vorgangs mit einem SAS-Token, das an einen Container oder eine Blobressource delegiert wurde, ist die Leseberechtigung (r) als Teil des Dienst-SAS-Tokens erforderlich.

Weitere Informationen zur Dienst-SAS finden Sie unter Create einer Dienst-SAS.

Konto-SAS

Eine Konto-SAS wird mit dem Speicherkontoschlüssel geschützt. Eine Konto-SAS delegiert den Zugriff auf Ressourcen in einem oder mehreren der Speicherdienste. Alle Vorgänge, die über eine Dienst-SAS oder eine SAS für die Benutzerdelegierung verfügbar sind, sind auch über eine Konto-SAS verfügbar.

In der folgenden Tabelle sind der signierte Ressourcentyp und die signierten Berechtigungen angegeben, die beim Delegieren des Zugriffs angegeben werden sollen:

Vorgang	Signierter Dienst	Signierter Ressourcentyp	Signierte Berechtigung
Get Blob	Blob (b)	Objekt (o)	Lesen (r)

Weitere Informationen zur Konto-SAS finden Sie unter Create einer Konto-SAS.

Der Get Blob Vorgang unterstützt die Freigabeschlüsselautorisierung. Die Autorisierung mit Kontoschlüsseln wird für die meisten Szenarien nicht empfohlen, da sie weniger sicher ist.

Microsoft empfiehlt, die Autorisierung mit freigegebenem Schlüssel für das Speicherkonto nach Möglichkeit nicht zu verwenden. Weitere Informationen finden Sie unter Verhindern der Autorisierung mit gemeinsam verwendetem Schlüssel.

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ückgegeben`ResourceNotFound`. Wenn in der Antwort kein `ErrorCode` Element angezeigt wird, wird eine Standardzeichenfolgendarstellung des HTTP-status angezeigt, z`NotFound`. 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

Freigeben über

Get Blob

Anforderung

Emulierter Speicherdienst-URI

URI-Parameter

Anforderungsheader

Anforderungsheader (vom Kunden bereitgestellte Verschlüsselungsschlüssel)

Anforderungstext

Antwort

Statuscode

Antwortheader

Antworttext

Beispiel für eine Antwort

Authorization

Berechtigungen

SAS für die Benutzerdelegierung

Dienst-SAS

Konto-SAS

Hinweise

Abrechnung

Weitere Informationen

Zusätzliche Ressourcen