Freigeben über

Copy Blob From URL

  • Artikel

Der Copy Blob From URL Vorgang kopiert ein Blob synchron in ein Ziel innerhalb des Speicherkontos für Quellblobgrößen von bis zu 256 Mebibytes (MiB). Diese API ist ab Version 2018-03-28 verfügbar.

Die Quelle für einen Copy Blob From URL Vorgang kann ein committetes Blockblob in einem beliebigen Azure-Speicherkonto sein, das entweder öffentlich oder mit einer Shared Access Signature autorisiert ist.

Anforderung

Sie können die Copy Blob From URL Anforderung wie folgt erstellen. Wir empfehlen HTTPS. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos, mycontainer durch den Namen Ihres Containers und myblob durch den Namen Ihres Zielblobs.

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

URI für den emulierten Speicherdienst

Wenn Sie eine Anforderung für 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:

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

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

URI-Parameter

Sie können im Anforderungs-URI die folgenden zusätzlichen Parameter angeben:

Parameter BESCHREIBUNG
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. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.
x-ms-meta-name:value Optional. Gibt ein benutzerdefiniertes Name-Wert-Paar an, das dem Blob zugeordnet ist. Wenn keine Namen-Wert-Paare angegeben werden, kopiert der Vorgang die Metadaten aus dem Quellblob oder der Quelldatei in das Zielblob. Wenn mindestens ein Name/Wert-Paar angegeben wird, wird das Zielblob mit den angegebenen Metadaten erstellt, und Metadaten werden nicht aus dem Quellblob oder der Quelldatei kopiert.

Ab Version 2009-09-19 müssen Metadatennamen den Benennungsregeln für C#-Bezeichner entsprechen. Weitere Informationen finden Sie unter Benennen und Verweisen auf Container, Blobs und Metadaten.
x-ms-encryption-scope Optional. Gibt den Verschlüsselungsbereich für die Verschlüsselung des Anforderungsinhalts an. Dieser Header wird ab Version 2020-12-06 unterstützt.
x-ms-tags Optional. Legt abfragezeichenfolgencodierte Tags für das Blob fest. Tags werden nicht aus der Kopierquelle kopiert. Weitere Informationen finden Sie unter Hinweise. Unterstützt in Version 2019-12-12 und höher.
x-ms-copy-source-tag-option Optional. Mögliche Werte sind REPLACE und COPY (beachten Sie die Groß-/Kleinschreibung). Standardwert: REPLACE.

Wenn COPY angegeben wird, werden die Tags aus dem Quellblob in das Zielblob kopiert. Das Quellblob muss privat sein, und die Anforderung muss über die Berechtigung für den Vorgang Get Blob Tags für das Quellblob und den Vorgang Set Blob Tags für das Zielblob verfügen. Dies verursacht einen zusätzlichen Aufruf des Get Blob Tags Vorgangs für das Quellkonto.

REPLACE legt Tags fest, die der x-ms-tags Header für das Zielblob angibt. Wenn x-ms-tags und keine Tags angegeben REPLACE sind, werden keine Tags für das Zielblob festgelegt. Das Angeben COPY von und x-ms-tags führt zu einem Fehler 409 (Konflikt).

Unterstützt in Version 2021-04-10 und höher.
x-ms-source-if-modified-since Optional. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um das BLOB nur dann zu kopieren, wenn das Quell-BLOB seit dem angegebenen Datum bzw. der angegebenen Uhrzeit geändert wurde. Wenn das Quellblob nicht geändert wurde, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück. Sie können diesen Header nicht angeben, wenn die Quelle eine Azure-Datei ist.
x-ms-source-if-unmodified-since Optional. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um das BLOB nur dann zu kopieren, wenn das Quell-BLOB seit dem angegebenen Datum bzw. der angegebenen Uhrzeit nicht geändert wurde. Wenn das Quellblob geändert wurde, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück. Sie können diesen Header nicht angeben, wenn die Quelle eine Azure-Datei ist.
x-ms-source-if-match Optional. Ein ETag-Wert. Geben Sie diesen bedingten Header an, um das Quellblob nur zu kopieren, wenn dessen ETag Wert dem angegebenen Wert entspricht. Wenn die Werte nicht übereinstimmen, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück. Sie können diesen Header nicht angeben, wenn die Quelle eine Azure-Datei ist.
x-ms-source-if-none-match Optional. Ein ETag-Wert. Geben Sie diesen bedingten Header an, um das Blob nur dann zu kopieren, wenn sein ETag Wert nicht mit dem angegebenen Wert übereinstimmt. Wenn die Werte identisch sind, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück. Sie können diesen Header nicht angeben, wenn die Quelle eine Azure-Datei ist.
If-Modified-Since Optional. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um das BLOB nur dann zu kopieren, wenn das Ziel-BLOB seit dem angegebenen Datum bzw. der angegebenen Uhrzeit geändert wurde. Wenn das Zielblob nicht geändert wurde, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück.
If-Unmodified-Since Optional. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um das BLOB nur dann zu kopieren, wenn das Ziel-BLOB seit dem angegebenen Datum bzw. der angegebenen Uhrzeit nicht geändert wurde. Wenn das Zielblob geändert wurde, gibt Blob Storage status Code 412 (Fehler bei der Vorbedingung) zurück.
If-Match Optional. Ein ETag-Wert. Geben Sie einen ETag Wert für diesen bedingten Header an, um das Blob nur dann zu kopieren, wenn der angegebene ETag Wert mit dem ETag Wert für ein vorhandenes Zielblob übereinstimmt. Wenn die Werte nicht übereinstimmen, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück.
If-None-Match Optional. Ein ETag Wert oder das Platzhalterzeichen (*).

Geben Sie einen ETag Wert für diesen bedingten Header an, um das Blob nur dann zu kopieren, wenn der angegebene ETag Wert nicht mit dem ETag Wert für das Zielblob übereinstimmt.

Geben Sie das Platzhalterzeichen (*) an, um den Vorgang nur auszuführen, wenn das Zielblob nicht vorhanden ist.

Wenn die angegebene Bedingung nicht erfüllt ist, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück.
x-ms-copy-source:name Erforderlich. Gibt die URL des Quellblobs an. Der Wert kann eine URL mit einer Länge von bis zu 2 Kibibytes (KiB) sein, die ein Blob angibt. Der Wert sollte so URL-codiert sein, wie er in einem Anforderungs-URI verwendet wird. Das Quellblob muss entweder öffentlich oder über eine Freigegebene Zugriffssignatur autorisiert sein. Wenn das Quellblob öffentlich ist, ist zum Ausführen des Vorgangs keine Autorisierung erforderlich. Wenn die Größe des Quellblobs größer als 256 MiB ist, schlägt die Anforderung mit einem Fehler 409 (Konflikt) fehl. Der Blobtyp des Quellblobs muss Blockblob sein. Hier sind einige Beispiele für Quellobjekt-URLs:

- 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>
x-ms-copy-source-authorization: <scheme> <signature> Optional. Gibt das Autorisierungsschema und die Signatur für die Kopierquelle an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
Nur der Schematräger wird für Microsoft Entra unterstützt.
Dieser Header wird in Version 2020-10-02 und höher unterstützt.
x-ms-requires-sync:true Erforderlich. Gibt an, dass es sich hierbei um einen synchronen Copy Blob From URL Vorgang anstelle eines asynchronen Copy Blob Vorgangs handelt.
x-ms-source-content-md5 Optional. Gibt einen MD5-Hash des Blobinhalts aus dem URI an. Dieser Hash wird verwendet, um die Integrität des Blobs während des Transports der Daten aus dem URI zu überprüfen. Wenn dieser Header angegeben wird, vergleicht der Speicherdienst den Hash des Inhalts, der aus der Kopierquelle eingegangen ist, mit diesem Headerwert.

Der MD5-Hash wird nicht mit dem Blob gespeichert.

Wenn die beiden Hashs nicht übereinstimmen, schlägt der Vorgang mit Fehlercode 400 (Ungültige Anforderung) fehl.
x-ms-lease-id:<ID> Erforderlich, wenn das Ziel-BLOB über eine aktive Lease verfügt. Die für diesen Header angegebene Lease-ID muss mit der Lease-ID des Ziel-BLOB übereinstimmen. Wenn die Anforderung die Lease-ID nicht enthält oder ungültig ist, schlägt der Vorgang mit status Code 412 (Vorbedingung fehlgeschlagen) fehl.

Wenn dieser Header angegeben ist und das Zielblob derzeit keine aktive Lease aufweist, schlägt der Vorgang mit status Code 412 (Vorbedingung fehlgeschlagen) fehl.

In Version 2012-02-12 und höher muss dieser Wert eine aktive, unendliche Lease für ein geleastes Blob angeben. Eine Lease-ID für endliche Dauer schlägt mit status Code 412 (Vorbedingung fehlgeschlagen) fehl.
x-ms-client-request-id Optional. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem Zeichenlimit von 1 KiB bereit, der beim Konfigurieren der Protokollierung in den Protokollen aufgezeichnet wird. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt.
x-ms-access-tier Optional. Gibt die Ebene an, die für das Zielblob festgelegt werden soll. Dieser Header gilt nur für Seitenblobs in einem Premium-Konto mit Version 2017-04-17 und höher. Eine vollständige Liste der unterstützten Tarife finden Sie unter Hochleistungsspeicher premium und verwaltete Datenträger für VMs. Dieser Header wird ab Version 2018-11-09 für Blockblobs unterstützt. Block blob tiering wird für Blob Storage- oder Universell v2-Konten unterstützt. Gültige Werte sind Hot, Cool, Cold und Archive. Hinweis:Cold die Ebene wird ab Version 2021-12-02 unterstützt. Ausführliche Informationen zum Blockblobtiering finden Sie unter Speicherebenen heiß, kalt und archivieren.

Anforderungstext

Keine.

Antwort

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

Statuscode

Ein erfolgreicher Vorgang gibt den Statuscode 202 (Akzeptiert) zurück.

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

Antwortheader

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

Antwortheader BESCHREIBUNG
ETag Wenn die Kopie abgeschlossen ist, enthält den ETag Wert des Zielblobs. Wenn die Kopie nicht abgeschlossen ist, enthält den ETag Wert des leeren Blobs, das am Anfang der Kopie erstellt wurde.

Der ETag Wert befindet sich in Anführungszeichen.
Last-Modified Gibt das Datum/die Uhrzeit zurück, an dem der Kopiervorgang zum Zielblob abgeschlossen wurde.
x-ms-request-id Identifiziert eindeutig die Anforderung, die gestellt wurde. Sie können es verwenden, um die Problembehandlung für die Anforderung zu beheben. Weitere Informationen finden Sie unter Problembehandlung bei API-Vorgängen.
x-ms-version Gibt die Version von Blob Storage an, die zum Ausführen der Anforderung verwendet wird.
Date Ein UTC-Datums-/Uhrzeitwert, der die Uhrzeit angibt, zu der der Dienst die Antwort gesendet hat.
x-ms-copy-id: <id> Zeichenfolgenbezeichner für diesen Kopiervorgang.
x-ms-copy-status: <success> Gibt den Zustand des Kopiervorgangs an. Ein Wert von success bedeutet, dass der Vorgang erfolgreich abgeschlossen wurde.
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 höchstens 1.024 sichtbare ASCII-Zeichen aufweist. Wenn der x-ms-client-request-id Header in der Anforderung nicht vorhanden ist, ist dieser Header in der Antwort nicht vorhanden.
x-ms-request-server-encrypted: true/false Legen Sie auf fest true , wenn der Inhalt der Anforderung erfolgreich über den angegebenen Algorithmus verschlüsselt wurde. Andernfalls lautet der Wert false.
x-ms-encryption-scope Wird zurückgegeben, wenn die Anforderung einen Verschlüsselungsbereich verwendet hat, sodass der Client sicherstellen kann, dass der Inhalt der Anforderung erfolgreich über den Verschlüsselungsbereich verschlüsselt wurde.

Antworttext

Keine.

Beispiel für eine Antwort

Im Folgenden ist eine Beispielantwort für eine Anforderung zum Kopieren eines BLOB dargestellt:

Response Status:  
HTTP/1.1 202 Accepted  
  
Response Headers:   
Last-Modified: <date>   
ETag: "0x8CEB669D794AFE2"  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-request-id: cc6b209a-b593-4be1-a38a-dde7c106f402  
x-ms-version: 2018-03-28  
x-ms-copy-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
x-ms-copy-status: success  
Date: <date>

Authorization

Beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage ist eine Autorisierung erforderlich. In der folgenden Tabelle wird beschrieben, wie die Ziel- und Quellobjekte für einen Copy Blob From URL Vorgang autorisiert werden können:

Objekttyp Microsoft Entra ID Autorisierung SAS-Autorisierung (Shared Access Signature) Shared Key Authorization (oder Shared Key Lite)
Zielblockblob Yes Yes Yes
Quellblockblob im selben Speicherkonto Yes Yes Yes
Quellblockblob in einem anderen Speicherkonto Nein Ja Nein

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

Sie können den Copy Blob From URL Vorgang wie unten beschrieben autorisieren. Beachten Sie, dass ein Quellblob in einem anderen Speicherkonto separat über ein SAS-Token mit der Berechtigung Lesen (r) autorisiert werden muss. Weitere Informationen zur Quellblobautorisierung finden Sie in den Details zum Anforderungsheader x-ms-copy-source.

Wichtig

Microsoft empfiehlt die Verwendung von 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 eine höhere Sicherheit und Benutzerfreundlichkeit.

Azure Storage unterstützt die Verwendung von Microsoft Entra ID zum Autorisieren von Anforderungen für Blobdaten. Mit Microsoft Entra ID können Sie die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC) 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 mithilfe von Microsoft Entra ID.

Berechtigungen

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 Copy Blob From URL Vorgang aufzurufen, und die integrierte Azure RBAC-Rolle mit den geringsten Berechtigungen, die diese Aktion enthält:

Zielblob

Quellblob innerhalb desselben Speicherkontos

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

Hinweise

Das Quell- und Zielblob für einen Copy Blob From URL Vorgang muss ein Blockblob sein.

In Version 2020-10-02 und höher wird Microsoft Entra Autorisierung für die Quelle des Kopiervorgangs unterstützt.

Der Vorgang Copy Blob From URL kopiert immer das gesamte Quellblob. Das Kopieren eines Bytebereichs oder einer Gruppe von Blöcken wird nicht unterstützt.

Sie können ein Quellblob in ein Zielblob mit einem anderen Namen kopieren. Das Zielblob kann ein vorhandenes Blockblob oder ein neues Blob sein, das durch den Kopiervorgang erstellt wird.

Beim Kopieren aus einem Blockblob werden alle committeten Blöcke und die zugehörigen Block-IDs kopiert. Nicht commitierte Blöcke werden nicht kopiert. Am Ende des Kopiervorgangs weist das Zielblob die gleiche Commit-Blockanzahl wie die Quelle auf.

Der ETag Wert für ein Blockblob ändert sich, wenn der Copy Blob From URL Vorgang gestartet wird und wenn der Vorgang abgeschlossen ist.

Kopieren von Blobeigenschaften und Metadaten

Wenn ein Blockblob kopiert wird, werden die folgenden Systemeigenschaften mit den gleichen Werten in das Zielblob kopiert:

  • Content-Type

  • Content-Encoding

  • Content-Language

  • Content-Length

  • Cache-Control

  • Content-MD5

  • Content-Disposition

Die Commit-Blockliste des Quellblobs wird ebenfalls in das Zielblob kopiert. Blöcke ohne ausgeführten Commit werden nicht kopiert.

Das Zielblob hat immer die gleiche Größe wie das Quellblob, sodass der Wert des Content-Length Headers für das Zielblob mit dem Wert dieses Headers für das Quellblob übereinstimmt.

Wenn der x-ms-tags Header Tags für das Zielblob bereitstellt, müssen diese abfragezeichenfolgencodiert sein. Tagschlüssel und -werte müssen den Benennungs- und Längenanforderungen entsprechen, die im Vorgang Blobtags festlegen angegeben sind.

Der x-ms-tags Header kann bis zu 2 Kilobits an Tags enthalten. Wenn Sie weitere Tags benötigen, verwenden Sie den Set Blob Tags -Vorgang.

Wenn der x-ms-tags Header keine Tags bereitstellt, werden Tags nicht aus dem Quellblob kopiert.

Kopieren eines geleasten Blobs

Der Copy Blob From URL Vorgang liest nur aus dem Quellblob, sodass der Leasestatus des Quellblobs keine Rolle spielt.

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 Abrechnung des Kontos aus. Beispielsweise werden Lesetransaktionen einer anderen Abrechnungskategorie zugeordnet als Schreibtransaktionen. Die folgende Tabelle zeigt die Abrechnungskategorie für Copy Blob From URL Anforderungen basierend auf dem Speicherkontotyp:

Vorgang Speicherkontotyp Abrechnungskategorie
Kopieren eines Blobs aus der URL (Zielkonto1) Premium, Blockblob
Standard „Allgemein v2“
Standard „Allgemein v1“		 Schreibvorgänge
Kopieren eines Blobs aus der URL (Quellkonto2) Premium, Blockblob
Standard „Allgemein v2“
Standard „Allgemein v1“		 Dient zum Lesen von Vorgängen.

1Dem Zielkonto wird eine Transaktion in Rechnung gestellt, um den Schreibvorgang zu initiieren.
2Das Quellkonto verursacht eine Transaktion für jede Leseanforderung an das Quellobjekt.

Informationen zu den Preisen für die angegebenen Abrechnungskategorien finden Sie unter Azure Blob Storage Preise.

Wenn sich die Quell- und Zielkonten in verschiedenen Regionen befinden (z. B. USA, Norden und USA, Süden), wird außerdem die Bandbreite, die Sie für die Übertragung der Anforderung verwenden, dem Quellspeicherkonto als ausgehender Datenverkehr in Rechnung gestellt. Der Ausgang zwischen Konten innerhalb derselben Region ist kostenlos.

Wenn Sie ein Quellblob in ein Zielblob mit einem anderen Namen innerhalb desselben Kontos kopieren, verwenden Sie zusätzliche Speicherressourcen für das neue Blob. Der Kopiervorgang führt dann zu einer Gebühr für die Kapazitätsauslastung des Speicherkontos für diese zusätzlichen Ressourcen.

Weitere Informationen

Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blob Storage-Fehlercodes
Grundlegendes dazu, wie Für Momentaufnahmen Gebühren anfallen