Hol dir Blob-Layout

Der Get Blob Layout Vorgang gibt alle benutzerdefinierten Metadaten, HTTP-Standardeigenschaften und Systemeigenschaften für das Blob zurück. Zusätzlich kann optional das Layout des Blobs zurückgegeben werden. Das Layout eines Blobs ist eine Teilressource eines Blobs, die eine Aufschlüsselung aller Bereiche im Blob enthält, mit einem Endpunkt (Adresse), an dem dieser Bereich gelesen werden kann, was Hinweise darauf gibt, wie Lesungen am besten parallelisiert werden können.

Mit dieser API können Sie eine Download-Operation optimieren, indem Sie die folgenden zwei Schritte ausführen:

  1. Layout Discovery: Aufruf Get Blob Layout , um die Eigenschaften des Blobs abzurufen und seine Datenverteilung zu entdecken.
  2. Parallel Blob abrufen: Rufe Get Blob parallel für alle Blob-Bereiche, die dich interessieren, und nutze die Endpunkte, die aus dem Blob-Layout zurückgegeben werden, um diese Anfragen an den optimalen Ort zu routen.

Anfrage

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

GET-Methodenanforderung URI HTTP-Version
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=layout

https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=layout&snapshot=<DateTime>

https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=layout&versionid=<DateTime>

https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=layout&versionid=<DateTime>&marker=<ContinuationToken>&maxresults=1000		 HTTP/1.0

HTTP/1.1

URI-Parameter

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

Parameter Description
snapshot Optional. Der snapshot-Parameter ist ein nicht transparenter DateTime Wert, der, wenn er vorhanden ist, die abzurufende Blobmomentaufnahme angibt. Weitere Informationen zum Umgang mit Blob-Snapshots finden Sie unter Create a snapshot of a blob.
versionid Optional. Bei dem versionid Parameter handelt es sich um einen nicht transparenten DateTime Wert, der, wenn er vorhanden ist, die Version des abzurufenden Blobs angibt.
marker Optional. Ein Fortsetzungstoken, das von einer vorherigen Get Blob Layout Anfrage zurückgegeben wurde. Verwenden Sie dieses Token, um die nächste Reihe von Reichweiten abzurufen. Der Marker wird verwendet, um die Paginierung fortzusetzen, wenn die Antwort nicht alle Bereiche für den Blob oder den angegebenen Bereich enthält. Wenn ein Marker verwendet wird, muss auch ein If-Match Header mit einem Etag aus der vorherigen Anfrage beigefügt werden. Weitere Informationen zur Verwendung eines If-Match Headers finden Sie unter Specify conditional headers for Blob Storage operations. Außerdem, wenn die vorherige Anfrage einen Range OR-Header x-ms-range enthielt, muss diese Anfrage ebenfalls einen identischen Header enthalten. Wenn die letzte Anfrage keinen Bereichsheader enthielt, darf auch dieser Antrag keinen enthalten.
maxresults Optional. Die maximale Anzahl von Bereichen, die in der Antwort zurückkehren müssen. Die API wird niemals mehr Bereiche zurückgeben als der von maxresultsder angegebene Wert.
timeout Optional. Der parameter timeout wird in Sekunden ausgedrückt. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob Storage-Vorgänge.

Anfrage-Header

In der folgenden Tabelle werden die erforderlichen und optionalen Anforderungsheader beschrieben.

Anforderungs-Header Description
Authorization Required. 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 Required. Gibt die koordinierte Weltzeit (UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
x-ms-version Required. Gibt die Version des Vorgangs an, der für diese Anforderung verwendet werden soll. Get Blob Layout wird nur in der Version 2026-02-06 oder später unterstützt. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure Storage-Dienste.
Range oder x-ms-range Optional. Geben Sie Metadaten nur für die angegebenen Bereiche zurück. Wenn sowohl Range als auch x-ms-range angegeben sind, verwendet der Dienst den Wert von x-ms-range. Wenn keiner der Bereiche angegeben ist, werden Metadaten für den gesamten Blob zurückgegeben. Weitere Informationen finden Sie unter Spezifikation des Bereichs-Headers für Blob Storage Operations.
x-ms-lease-id: <ID> Optional. Wenn dieser Header angegeben ist, wird die Operation nur durchgeführt, wenn beide folgenden Bedingungen erfüllt sind:

- Der Pachtvertrag des Blobs ist derzeit aktiv.
- Die in der Anfrage angegebene Lease-ID stimmt mit der Lease-ID des Blobs überein.

Wenn eine dieser Bedingungen nicht erfüllt ist, schlägt die Anforderung fehl, und der Get Blob Layout Vorgang schlägt mit dem Statuscode 412 (Vorbedingung fehlgeschlagen) fehl.
x-ms-upn Optional. Gültig für Konten mit aktiviertem hierarchischen Namensraum. Wenn zutreffend, werden die in den x-ms-owner, x-ms-group, und x-ms-acl Antwort-Headern zurückgegebenen Benutzeridentitätswerte von Microsoft Entra-Objekt-IDs in Benutzer-Hauptnamen umgewandelt. Wenn der Wert falsch 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 freundlichen Namen haben.
x-ms-client-request-id Optional. Stellt einen clientsgenerierten, undurchsichtigen Wert mit einer Zeichenbegrenzung von 1 Kibibyte (KiB) bereit, die in den Analyseprotokollen verzeichnet wird, wenn das Storage Analytics Logging aktiviert ist. Wir empfehlen dringend, diesen Header zu verwenden, wenn Sie clientseitige Aktivitäten mit Anfragen verknüpfen, die vom Server empfangen werden. Weitere Informationen finden Sie unter Über Azure Storage Analytics Logging.

Diese Operation unterstützt auch die Verwendung bedingter Header, um das Blob-Layout und die Eigenschaften nur dann zurückzugeben, wenn eine bestimmte Bedingung erfüllt ist. Für weitere Informationen siehe Spezifikation bedingter Headers für Blob Storage Operationen. Beachten Sie, dass ein Header If-Match erforderlich ist, wenn a marker in den URI-Parametern verwendet wird.

Anfrage-Header (vom Kunden bereitgestellte Verschlüsselungsschlüssel)

Sie können die folgenden Header auf der Anfrage angeben, um einen Blob zu lesen, der 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 Anfrage aufnehmen, damit die Operation erfolgreich abgeschlossen werden kann.

Anforderungs-Header Description
x-ms-encryption-key Required. Der von Base64 codierte AES-256-Verschlüsselungsschlüssel.
x-ms-encryption-key-sha256 Optional. Der von Base64 codierte SHA256-Hash des Verschlüsselungsschlüssels.
x-ms-encryption-algorithm: AES256 Required. Spezifiziert den Algorithmus für die Verschlüsselung. Der Wert dieses Headers muss auf AES256 festgelegt sein.

Anforderungstext

None.

Antwort

Die Antwort enthält einen HTTP-Statuscode, eine Reihe von Antwortkopfzeilen und optional einen Antwortkörper mit dem Blob-Layout im XML-Format.

Statuscode

Eine erfolgreiche Operation gibt einen von zwei Statuscodes zurück:

  • HTTP 200 (OK), wenn die Antwort ein Blob-Layout im Body enthält.
  • HTTP 204 (No Content), wenn der Server kein Layout im Antwort-Body zurückgab. In diesem Fall ist die API funktional äquivalent zu Get Blob Properties.

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

Antwortkopfzeilen

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

Antwortkopfzeile Description
Content-Type Spezifiziert das Format, in dem die Ergebnisse im Antwortkörper zurückgegeben werden. Der Wert ist application/xml , wenn der Körper zurückgegeben wird.
Content-Length Zeigt die Größe des Antwortkörpers an, falls er zurückgegeben wird.
Last-Modified Das Datum/Uhrzeit, an dem der Blob zuletzt verändert wurde. Das Datumsformat folgt RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Kopfzeilen.

Jeder Vorgang, der das Blob ändert, einschließlich einer Aktualisierung der Metadaten oder Eigenschaften des Blobs, ändert den Zeitpunkt der letzten Änderung des Blobs.
x-ms-creation-time Das Datum bzw. die Uhrzeit, an der der Blob entstanden ist. Das Datumsformat folgt RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Kopfzeilen.
x-ms-meta-name:value Ein Satz von Name-Wert-Paaren, die den benutzerdefinierten Metadaten entsprechen, die diesem Blob zugeordnet sind.
x-ms-tag-count Wenn das Blob über Tags verfügt, wird die Anzahl der Tags zurückgegeben, die im Blob gespeichert sind. Dieser Header wird nicht zurückgegeben, wenn das Blob keine Tags enthält.
ETag Enthält einen Wert, den du für Operationen bedingt verwenden kannst. Für weitere Informationen siehe Spezifikation bedingter Headers für Blob Storage Operationen. Der ETag-Wert ist in Anführungszeichen eingeschlossen.
x-ms-copy-completion-time:<datetime> Abschlusszeit des letzten versuchten Copy Blob Vorgangs, bei dem dieses Blob das Zielblob war. Dieser Wert kann den Zeitpunkt 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 Set Blob Properties, Put Bloboder Put Block Listverwendet.
x-ms-copy-status-description: <error string> Tritt nur auf, wenn x-ms-copy-status ist failed oder pending. Beschreibt die Ursache eines schwerwiegenden oder nicht schwerwiegenden Fehlers beim Kopiervorgang. 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 Set Blob Properties, Put Bloboder Put Block List.
x-ms-copy-id: <id> Der Zeichenfolgenbezeichner für den letzten Versuch, den Vorgang auszuführen Copy Blob , 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 Set Blob Properties, Put Bloboder Put Block List.
x-ms-copy-progress: <bytes copied/bytes total> Enthält die Anzahl der kopierten Bytes und die Gesamtzahl der Bytes in der Quelle im letzten versuchten Copy Blob Vorgang, wobei dieses Blob das Zielblob war. 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 Set Blob Properties, Put Bloboder Put Block List.
x-ms-copy-source: url Eine URL mit einer Länge von bis zu 2 KB, die das Quellblob angibt, das beim letzten Versuch Copy Blob des Vorgangs 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 Set Blob Properties, Put Bloboder Put Block List.

Die in diesem Header zurückgegebene URL enthält alle Anfrageparameter, die bei der Kopieroperation auf dem Quellblob verwendet wurden. Wenn die URL ein Shared Access Signature (SAS)-Token enthält, wird die Signatur (sig Parameter) nicht enthalten.
x-ms-copy-status: <pending \| success \| aborted \| failed> Der Status des Kopiervorgangs, der durch x-ms-copy-id identifiziert wird, mit den folgenden Werten:

- success: Kopie erfolgreich abgeschlossen.
- pending: Kopie ist in Arbeit. Überprüfen Sie x-ms-copy-status-description , ob zeitweilige, nicht schwerwiegende Fehler den Kopiervorgang behindern, aber keine Fehler verursachen.
- aborted: Kopie wurde beendet von Abort Copy Blob.
- failed: Kopie fehlgeschlagen. Details zu Fehlern 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 Set Blob Properties, Put Bloboder Put Block List.
x-ms-incremental-copy: true Eingeschlossen, wenn es sich bei dem Blob um ein inkrementelles Kopierblob handelt.
x-ms-copy-destination-snapshot:<datetime> Enthalten, wenn es sich bei dem Blob um ein inkrementelles Kopierblob oder eine inkrementelle Kopiermomentaufnahme handelt, wenn x-ms-copy-status es sich um einen Erfolg handelt. Momentaufnahmezeit der letzten erfolgreichen inkrementellen Kopiermomentaufnahme für dieses Blob.
x-ms-lease-duration: <infinite \| fixed> Wenn ein Blob geleast wird, gibt sie an, ob die Lease unendlich oder fester Dauer ist.
x-ms-lease-state: <available \| leased \| expired \| breaking \| broken> Der Pachtstatus des Blobs.
x-ms-lease-status:<locked\| unlocked> Der Leasestatus des Blobs.
Cache-Control Wenn der Cache-Control Anforderungsheader zuvor für das Blob festgelegt wurde, wird dieser Wert in diesem Header zurückgegeben.
x-ms-request-id Dieser Header identifiziert die gestellte Anforderung eindeutig, und Sie können ihn zur Fehlerbehebung der Anforderung verwenden. 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 wird.
Accept-Ranges: bytes Gibt an, dass der Dienst Anforderungen für partielle BLOB-Inhalte unterstützt.
x-ms-server-encrypted: true/false Der Wert dieses Headers wird auf true den Wert 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-/Anwendungsmetadaten verschlüsselt sind).
x-ms-encryption-key-sha256 Dieser Header wird zurückgegeben, wenn der Blob mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt ist.
x-ms-encryption-context Wenn der Verschlüsselungskontext-Eigenschaftswert gesetzt ist, wird der gesetzte Wert zurückgegeben. Nur gültig, wenn der hierarchische Namespace für das Konto aktiviert ist.
x-ms-encryption-scope Dieser Header wird zurückgegeben, wenn der Blob mit einem Verschlüsselungsbereich verschlüsselt ist.
x-ms-access-tier Die Stufe eines Block Blob in einem Blob Storage- oder General Purpose v2-Konto. Gültige Werte sind Hot, Cool, Cold, Smart und Archive. Für detaillierte Informationen zur Standard-Blob-Block-Blob-Level-Tiering siehe Blob-Speichertiere.
x-ms-smart-access-tier Dieser Header wird nur für Anfragen zurückgegeben, die gegen Blobs im Tier Smart gestellt werden. Gültige Werte sind Hot, Coolund Cold. Für detaillierte Informationen zur Standard-Blob-Block-Blob-Level-Tiering siehe Blob-Speicher-Tiers.
x-ms-archive-status Für Blob-Speicher- oder allgemeine v2-Konten sind rehydrate-pending-to-hotdie gültigen Werte , rehydrate-pending-to-cool, und rehydrate-pending-to-cold. Wenn das Blob aktiviert wird und unvollständig ist, wird dieser Header zurückgegeben, der sowohl angibt, dass die Aktivierung aussteht, als auch die Zielebene anzeigt. Für detaillierte Informationen zur Standard-Blob-Block-Blob-Level-Tiering siehe Blob Storage Tiers.
x-ms-access-tier-change-time Gibt an, wann die Ebene für das Objekt zuletzt geändert wurde. Dieser Header wird nur zurückgegeben, wenn jemals eine Ebene für das Blockblob festgelegt wurde. Das Datumsformat folgt RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Kopfzeilen. Weitere Informationen zur Standard-Blob-Block-Blob-Tiering finden Sie unter Blob-Speicher-Tiers.
x-ms-rehydrate-priority Wenn sich ein Objekt im ausstehenden Zustand rehydratisiert, wird dieser Header mit der Priorität des Rehydrats zurückgegeben. Gültige Werte sind High/Standard. Für detaillierte Informationen zur Standard-Blob-Block-Blob-Level-Tiering siehe Blob-Speicher-Tiers.
x-ms-or-{policy-id}_{rule-id} Nur für Blockklumpen zurückgegeben. policy-id ist ein GUID-Wert, der den Bezeichner einer Objektreplikationsrichtlinie für das Speicherkonto darstellt. rule-id ist ein GUID-Wert, der den Bezeichner einer Richtlinienregel für den Blobcontainer darstellt. Wenn das Konto -enabled ist ObjectReplication, stellt der Wert dieses Headers den Replikationsstatus des Blobs mit den angegebenen Richtlinien- und Regelbezeichnern dar, entweder complete oder failed.
x-ms-or-policy-id Nur für Blockklumpen zurückgegeben. Wenn das Konto aktiviert ist ObjectReplication, stellt der Wert dieses Headers die Richtlinie dar, die die Replizierung steuert.
x-ms-last-access-time Gibt an, wann zuletzt auf die Daten des Blobs abgerufen wurden, basierend auf der letzten Zugriffszeitverfolgungsrichtlinie des Speicherkontos. Der Header wird nicht zurückgegeben, wenn das Speicherkonto nicht über eine Richtlinie für die Nachverfolgung der Zeit des letzten Zugriffs verfügt oder die Richtlinie deaktiviert ist. Informationen zum Festlegen der Richtlinie für die Nachverfolgungszeit des Speicherkontos für den letzten Zugriff finden Sie unter Blob Storage-API.
x-ms-blob-sealed Wurde nur für Anhängungsblobs zurückgegeben. Wenn das Anfügeblob versiegelt wurde, wäre der Wert true. Weitere Informationen finden Sie unter Append Blob Seal
x-ms-immutability-policy-until-date Gibt das für das Blob festgelegte Datum "Aufbewahrung bis" an. Dies ist das Datum, bis zu dem der Blob vor einer Änderung oder Löschung geschützt werden kann. Nur dann zurückgegeben, wenn eine Unveränderlichkeitsrichtlinie auf den Blob gesetzt ist. Der Wert dieses Headers hat das Format RFC1123.
x-ms-immutability-policy-mode: unlocked/locked Der Unveränderlichkeitsrichtlinienmodus, der zurückgegeben wird, wenn eine Unveränderlichkeitsrichtlinie für das Blob festgelegt ist. Die Werte sind unlocked/locked. unlocked Gibt an, dass der Benutzer die Richtlinie ändern kann, indem er das Aufbewahrungsdatum erhöht oder verringert. locked darauf hinweist, dass diese Handlungen verboten sind.
x-ms-legal-hold: true/false Dieser Header wird nicht zurückgegeben, wenn keine gesetzliche Aufbewahrungspflicht für das Blob vorhanden ist. Der Wert dieses Headers wird auf true festgelegt, wenn das Blob eine gesetzliche Aufbewahrungspflicht enthält und der Wert true ist. Andernfalls wird der Wert auf false festgelegt, wenn das Blob eine gesetzliche Aufbewahrungspflicht enthält und der Wert false ist.
x-ms-owner Nur für Konten mit aktiviertem hierarchischen Namensraum. Gibt den Besitzerbenutzer der Datei oder des Verzeichnisses zurück.
x-ms-group Nur für Konten mit aktiviertem hierarchischen Namensraum. Gibt die Besitzergruppe der Datei oder des Verzeichnisses zurück.
x-ms-permissions Nur für Konten mit aktiviertem hierarchischen Namensraum. Gibt die Berechtigungen zurück, die für Benutzer, Gruppen und andere für die Datei oder das Verzeichnis festgelegt sind. Jede einzelne Erlaubnis ist im Format [r,w,x,-]{3} .
x-ms-acl Nur für Konten mit aktiviertem hierarchischen Namensraum. Gibt die kombinierte Liste der Zugriffs- und Standardzugriffskontrollliste zurück, die für Benutzer,Gruppe und andere in der Datei oder im Verzeichnis festgelegt sind. Jeder Zugriffskontrolleintrag (ACE) besteht aus einem Scope, einem Typ, einer Benutzer- oder Gruppenkennung sowie Berechtigungen im jeweiligen Format.[scope]:[type]:[id]:[permissions] Der Umfang default gibt an, dass der ACE zur Standard-ACL eines Verzeichnisses gehört; ansonsten ist der Umfang implizit und der ACE gehört zur Zugriffs-ACL. Jede einzelne Erlaubnis ist im Format [r,w,x,-]{3} .
x-ms-resource-type Nur für Konten mit aktiviertem hierarchischem Namespace. Gibt den Ressourcentyp für den Pfad zurück, der entweder file oder directorysein kann.
x-ms-expiry-time Nur für Konten mit aktiviertem hierarchischem Namespace. Gibt die Ablaufzeit zurück, die für das Blob festgelegt ist. Wird nur für Dateien zurückgegeben, für die eine Ablaufzeit festgelegt ist.

Antwortkörper

Wenn der Antwortstatuscode HTTP 200 (OK) ist, enthält der Antwortkörper das Blob-Layout im XML-Format. Das Format der Antwort ist wie folgt:

<?xml version="1.0" encoding="utf-8"?>
<BlobLayout>
    <Ranges>
        <Range Start="0" End="1023" EndpointIndex="0" />
        <Range Start="1024" End="4096" EndpointIndex="1" />
    </Ranges>
    <Endpoints>
        <Endpoint Index="0" Value="host1:port" />
        <Endpoint Index="1" Value="host2:port" />
    </Endpoints>
    <NextMarker>marker</NextMarker>
    <MaxResults>2</MaxResults>
</BlobLayout>

Die XML-Antwort enthält folgende Elemente:

  • Bereiche: Enthält eine Liste von Bereichselementen, von denen jedes einen zusammenhängenden Bytebereich im Blob mit einem zugehörigen Endpunktindex angibt.

    • Bereich: Repräsentiert einen zusammenhängenden Bereich von Bytes im Blob.
      • Start: Der Startbyte-Offset des Bereichs (inklusive).
      • Ende: Der Endbyte-Offset des Bereichs (inklusive).
      • EndpointIndex: Der Index des Endpunkts in der Endpunktliste, aus dem dieser Bereich gelesen werden soll.

  • Endpunkte: Enthält eine Liste von Endpunkt-Elementen, von denen jedes einen Service-Endpunkt angibt.

    • Endpunkt: Repräsentiert einen Service-Endpunkt, von dem aus Blob-Bereiche gelesen werden können.
      • Index: Der Index dieses Endpunkts, referenziert durch Bereichselemente.
      • Wert: Der DNS-Hostname und Port im Format hostname:port. Dies ist der Service-Endpunkt, von dem Sie anschließend lesen sollten.

  • NextMarker: Ein Fortsetzungstoken, das in einer nachfolgenden Get Blob Layout Anfrage verwendet wird, um die nächste Reihe von Bereichen abzurufen. Dieses Element ist nur vorhanden, wenn es zusätzliche Bereiche zum Abrufen gibt.

  • MaxResults: Die maximale Anzahl der im API-Aufruf angeforderten Bereiche.

Autorisierung

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

Von Bedeutung

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

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

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

Erlaubnisse

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

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

Bemerkungen

  • Diese API ist nur für Append- und Blockblobs gültig.

  • Die API kann entweder mit HTTP 200 (OK) oder HTTP 204 (No Content) erfolgreich sein. Wenn HTTP 204 zurückgegeben wird, sind für den Blob keine Layoutinformationen verfügbar, und die API ist funktional äquivalent zu Get Blob Properties. Wenn keine Layoutinformationen verfügbar sind, sollten Clients Standardaufrufe Get Blob verwenden, um den Blob herunterzuladen.

  • Wenn ein Layout zurückgegeben wird, können Sie den in jedem Bereich bereitgestellten Host und Port verwenden, um den Inhalt des von diesem Range abgedeckten Blobs herunterzuladen. Es wird dringend empfohlen, diese Downloads auf dem ETag, die aus dem Get Blob Layout Anruf zurückgesendet werden, zu konditionieren, um eine starke Konsistenz bei den Lesungen zu gewährleisten.

  • Die Antwortheader x-ms-blob-content-* beziehen sich auf den Blob selbst und nicht auf die Layout-Subressource. Die Antwort Content-Type ist immer application/xml , wenn ein Antwortkörper zurückgegeben wurde.

  • Die API akzeptiert einen Range oder Header x-ms-range . Wenn der Range-Header weggelassen wird, gilt die Anfrage für den gesamten Blob. Die API wird niemals Bereiche zurückgeben, die über den Range-Header hinausgehen.

  • Die API ist paginiert. Die API gibt möglicherweise nicht genügend Bereiche zurück, um den gesamten Blob abzudecken, oder bei Bereichsanfragen nicht genug Bereiche, um den gesamten angeforderten Bereich abzudecken. Wenn das passiert, gibt die API eine NextMarker zurück, die du verwenden solltest, um zusätzliche Bereiche anzufordern. Wenn ein Marker verwendet wird, MUSST du auch eine If-Match Bedingung erfüllen, die mit dem ETag aus der Anfrage übereinstimmt, die den Marker generiert hat. Außerdem, wenn die Anfrage, die den Marker generiert hat, einen Range oder x-ms-range Header enthält, MUSS die nachfolgende Anfrage einen identischen Header enthalten. Wenn die Anfrage, die den Marker generierte, keinen Bereichskopf enthielt, DARF auch die nachfolgende Anfrage keinen Bereichskopf enthalten.

  • Sie DÜRFEN NICHT annehmen, dass die Liste der Endpunkte in der Antwort mit der Liste der Endpunkte aus vorherigen Get Blob Layout Anfragen an diesen Blob übereinstimmt. Dies gilt sogar, wenn die Anfrage einen Marker verwendet – die Endpunktliste kann nicht mit der Endpunktliste der Anfrage übereinstimmen, die den Marker erzeugt hat.

  • Der für jeden Bereich zurückgegebene Endpunkt ist ein DNS-Hostname und Port, die in der Form hostname:portzurückgegeben werden. Dies ist das Service-Endpunkt, das für diesen Bereich gelesen werden sollte. Sie MÜSSEN sowohl den Hostnamen als auch den Port verwenden, der beim Erstellen Ihrer HTTP-Anfrage angegeben ist. Der Hostname kann den Kontonamen nicht enthalten, daher MÜSSEN Sie in nachfolgenden Get Blob API-Aufrufen explizit den entsprechenden Host Header für diesen Endpunkt hinzufügen.

  • Das Layout eines Blobs kann sich im Laufe der Zeit ändern, selbst wenn der Blob nicht verändert wird. Das Layout eines beliebigen Blobs sollte nach fünf Minuten aktualisiert werden, also jedes Mal, wenn der Blob geändert wird.

Siehe auch

Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blob Storage-Fehlercodes
Setze Timeouts für Blob Storage-OperationenBlob Service-KonzepteSpezifiziere bedingte Header für Blob Storage-Operationen

  • Zuletzt aktualisiert um