Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Operacja Copy Blob From URL
kopiuje obiekt blob do miejsca docelowego na koncie magazynu synchronicznie dla źródłowych rozmiarów obiektów blob do 256 mebibajtów (MiB). Ten interfejs API jest dostępny od wersji 2018-03-28.
Źródłem Copy Blob From URL
operacji może być dowolny zatwierdzony blokowy obiekt blob na dowolnym koncie usługi Azure Storage, które jest publiczne lub autoryzowane przy użyciu sygnatury dostępu współdzielonego.
Żądanie
Żądanie Copy Blob From URL
można skonstruować w następujący sposób. Zalecamy użycie protokołu HTTPS. Zastąp myaccount ciąg nazwą konta magazynu, mycontainer nazwą kontenera, a myblob nazwą docelowego obiektu blob.
Identyfikator URI żądania metody PUT | Wersja protokołu HTTP |
---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob |
Protokół HTTP/1.1 |
Identyfikator URI emulowanej usługi magazynu
Podczas wysyłania żądania względem emulowanej usługi magazynu określ nazwę hosta emulatora i port Azure Blob Storage jako 127.0.0.1:10000
, a następnie nazwę emulowanego konta magazynu:
Identyfikator URI żądania metody PUT | Wersja protokołu HTTP |
---|---|
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob |
Protokół HTTP/1.1 |
Aby uzyskać więcej informacji, zobacz Use the Azurite emulator for local Azure Storage development (Używanie emulatora Azurite do lokalnego programowania w usłudze Azure Storage).
Parametry identyfikatora URI
Dla identyfikatora URI żądania można określić następujące dodatkowe parametry:
Parametr | Opis |
---|---|
timeout |
Opcjonalny. Parametr timeout jest wyrażony w sekundach. Aby uzyskać więcej informacji, zobacz Ustawianie limitów czasu dla operacji usługi Blob Storage. |
Nagłówki zapytań
W poniższej tabeli opisano wymagane i opcjonalne nagłówki żądań:
Nagłówek żądania | Opis |
---|---|
Authorization |
To jest wymagane. Określa schemat autoryzacji, nazwę konta i podpis. Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage. |
Date lub x-ms-date |
To jest wymagane. Określa uniwersalny czas koordynowany (UTC) dla żądania. Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage. |
x-ms-version |
Wymagane dla wszystkich autoryzowanych żądań. Aby uzyskać więcej informacji, zobacz Przechowywanie wersji usług Azure Storage. |
x-ms-meta-name:value |
Opcjonalny. Określa zdefiniowaną przez użytkownika parę nazwa/wartość skojarzoną z obiektem blob. Jeśli nie określono żadnych par nazwa/wartość, operacja skopiuje metadane ze źródłowego obiektu blob lub pliku do docelowego obiektu blob. Jeśli określono co najmniej jedną parę nazwa/wartość, docelowy obiekt blob zostanie utworzony z określonymi metadanymi, a metadane nie zostaną skopiowane ze źródłowego obiektu blob lub pliku. Począwszy od wersji 2009-09-19, nazwy metadanych muszą być zgodne z regułami nazewnictwa identyfikatorów języka C#. Aby uzyskać więcej informacji, zobacz Nazewnictwo i odwoływanie się do kontenerów, obiektów blob i metadanych. |
x-ms-encryption-scope |
Opcjonalny. Wskazuje zakres szyfrowania do szyfrowania zawartości żądania. Ten nagłówek jest obsługiwany w wersji 2020-12-06 i nowszych. |
x-ms-tags |
Opcjonalny. Ustawia tagi zakodowane w ciągu zapytania w obiekcie blob. Znaczniki nie są kopiowane ze źródła kopiowania. Aby uzyskać więcej informacji, zobacz Uwagi. Obsługiwane w wersji 2019-12-12 i nowszych. |
x-ms-copy-source-tag-option |
Opcjonalny. Możliwe wartości to REPLACE and COPY (z uwzględnieniem wielkości liter). Wartość domyślna to REPLACE .Jeśli COPY zostanie określony, tagi ze źródłowego obiektu blob zostaną skopiowane do docelowego obiektu blob. Źródłowy obiekt blob musi być prywatny, a żądanie musi mieć uprawnienia do operacji Pobierz tagi obiektu blob w źródłowym obiekcie blob i operacji Ustaw tagi obiektu blob w docelowym obiekcie blob. Powoduje to dodatkowe wywołanie Get Blob Tags operacji na koncie źródłowym.REPLACE ustawi tagi określone przez x-ms-tags nagłówek w docelowym obiekcie blob. Jeśli x-ms-tags określono REPLACE i nie ma tagów, żadne tagi nie zostaną ustawione w docelowym obiekcie blob. Określenie COPY i x-ms-tags spowoduje błąd 409 (konflikt).Obsługiwane w wersji 2021-04-10 i nowszych. |
x-ms-source-if-modified-since |
Opcjonalny. Wartość DateTime . Określ ten nagłówek warunkowy, aby skopiować obiekt blob tylko wtedy, gdy źródłowy obiekt blob został zmodyfikowany od określonej daty/godziny. Jeśli źródłowy obiekt blob nie został zmodyfikowany, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiódł się). Nie można określić tego nagłówka, jeśli źródło jest plikiem platformy Azure. |
x-ms-source-if-unmodified-since |
Opcjonalny. Wartość DateTime . Określ ten nagłówek warunkowy, aby skopiować obiekt blob tylko wtedy, gdy źródłowy obiekt blob nie został zmodyfikowany od określonej daty/godziny. Jeśli źródłowy obiekt blob został zmodyfikowany, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiódł się). Nie można określić tego nagłówka, jeśli źródło jest plikiem platformy Azure. |
x-ms-source-if-match |
Opcjonalny.
ETag Wartość. Określ ten nagłówek warunkowy, aby skopiować źródłowy obiekt blob tylko wtedy, gdy jego ETag wartość jest zgodna z określoną wartością. Jeśli wartości nie są zgodne, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiódł się). Nie można określić tego nagłówka, jeśli źródło jest plikiem platformy Azure. |
x-ms-source-if-none-match |
Opcjonalny.
ETag Wartość. Określ ten nagłówek warunkowy, aby skopiować obiekt blob tylko wtedy, gdy jego ETag wartość nie jest zgodna z określoną wartością. Jeśli wartości są identyczne, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiódł się). Nie można określić tego nagłówka, jeśli źródło jest plikiem platformy Azure. |
If-Modified-Since |
Opcjonalny. Wartość DateTime . Określ ten nagłówek warunkowy, aby skopiować obiekt blob tylko wtedy, gdy docelowy obiekt blob został zmodyfikowany od określonej daty/godziny. Jeśli docelowy obiekt blob nie został zmodyfikowany, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiódł się). |
If-Unmodified-Since |
Opcjonalny. Wartość DateTime . Określ ten nagłówek warunkowy, aby skopiować obiekt blob tylko wtedy, gdy docelowy obiekt blob nie został zmodyfikowany od określonej daty/godziny. Jeśli docelowy obiekt blob został zmodyfikowany, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiódł się). |
If-Match |
Opcjonalny.
ETag Wartość. Określ wartość tego nagłówka warunkowego ETag , aby skopiować obiekt blob tylko wtedy, gdy określona ETag wartość jest zgodna z wartością ETag istniejącego docelowego obiektu blob. Jeśli wartości nie są zgodne, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiódł się). |
If-None-Match |
Opcjonalny. Wartość ETag lub symbol wieloznaczny (*).Określ wartość tego nagłówka warunkowego ETag , aby skopiować obiekt blob tylko wtedy, gdy określona ETag wartość nie jest zgodna z wartością ETag docelowego obiektu blob.Określ symbol wieloznaczny (*), aby wykonać operację tylko wtedy, gdy docelowy obiekt blob nie istnieje. Jeśli określony warunek nie zostanie spełniony, usługa Blob Storage zwróci kod stanu 412 (Warunek wstępny nie powiódł się). |
x-ms-copy-source:name |
To jest wymagane. Określa adres URL źródłowego obiektu blob. Wartość może być adresem URL o długości do 2 kibibajtów (KiB), który określa obiekt blob. Wartość powinna być zakodowana w adresie URL, tak jak w identyfikatorze URI żądania. Źródłowy obiekt blob musi być publiczny lub autoryzowany za pośrednictwem sygnatury dostępu współdzielonego. Jeśli źródłowy obiekt blob jest publiczny, do wykonania operacji nie jest wymagana autoryzacja. Jeśli rozmiar źródłowego obiektu blob jest większy niż 256 MiB, żądanie zakończy się niepowodzeniem z powodu błędu 409 (konflikt). Typ obiektu blob źródłowego obiektu blob musi być blokowym obiektem blob. Oto kilka przykładów adresów URL obiektów źródłowych: - 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> |
Opcjonalny. Określa schemat autoryzacji i podpis dla źródła kopii. Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage. Tylko element nośny schematu jest obsługiwany dla firmy Microsoft Entra. Ten nagłówek jest obsługiwany w wersji 2020-10-02 lub nowszej. |
x-ms-requires-sync:true |
To jest wymagane. Wskazuje, że jest to operacja synchroniczna Copy Blob From URL , a nie asynchroniczna Copy Blob . |
x-ms-source-content-md5 |
Opcjonalny. Określa skrót MD5 zawartości obiektu blob z identyfikatora URI. Ten skrót służy do weryfikowania integralności obiektu blob podczas transportu danych z identyfikatora URI. Po określeniu tego nagłówka usługa magazynu porównuje skrót zawartości, która dotarła ze źródła kopiowania, z tą wartością nagłówka. Skrót MD5 nie jest przechowywany w obiekcie blob. Jeśli dwa skróty nie są zgodne, operacja zakończy się niepowodzeniem z kodem błędu 400 (nieprawidłowe żądanie). |
x-ms-lease-id:<ID> |
Wymagane, jeśli docelowy obiekt blob ma aktywną dzierżawę. Identyfikator dzierżawy określony dla tego nagłówka musi być zgodny z identyfikatorem dzierżawy docelowego obiektu blob. Jeśli żądanie nie zawiera identyfikatora dzierżawy lub jest nieprawidłowe, operacja zakończy się niepowodzeniem z kodem stanu 412 (Warunek wstępny nie powiódł się). Jeśli ten nagłówek zostanie określony, a docelowy obiekt blob nie ma obecnie aktywnej dzierżawy, operacja zakończy się niepowodzeniem z kodem stanu 412 (Warunek wstępny nie powiódł się). W wersji 2012-02-12 lub nowszej ta wartość musi określać aktywną, nieskończoną dzierżawę dla dzierżawionego obiektu blob. Identyfikator dzierżawy o skończonym czasie trwania kończy się niepowodzeniem z kodem stanu 412 (Warunek wstępny nie powiódł się). |
x-ms-client-request-id |
Opcjonalny. Zapewnia nieprzezroczystą wartość wygenerowaną przez klienta z limitem znaków 1-KiB rejestrowanym w dziennikach podczas konfigurowania rejestrowania. Zdecydowanie zalecamy używanie tego nagłówka do korelowania działań po stronie klienta z żądaniami odbieranymi przez serwer. |
x-ms-access-tier |
Opcjonalny. Określa warstwę, która ma zostać ustawiona w docelowym obiekcie blob. Ten nagłówek jest przeznaczony dla stronicowych obiektów blob na koncie Premium tylko w wersji 2017-04-17 lub nowszej. Aby uzyskać pełną listę obsługiwanych warstw, zobacz Magazyn premium o wysokiej wydajności i dyski zarządzane dla maszyn wirtualnych. Ten nagłówek jest obsługiwany w wersji 2018-11-09 i nowszych dla blokowych obiektów blob. Obsługa warstw blokowych obiektów blob jest obsługiwana na kontach usługi Blob Storage lub ogólnego przeznaczenia w wersji 2. Prawidłowe wartości to Hot , , Cool Cold i Archive .
Uwaga: warstwaCold jest obsługiwana w wersji 2021-12-02 lub nowszej. Aby uzyskać szczegółowe informacje na temat warstw blokowych obiektów blob, zobacz Warstwy magazynowania Gorąca, Chłodna i Archiwum. |
x-ms-file-request-intent |
Wymagane, jeśli x-ms-copy-source nagłówek jest adresem URL pliku platformy Azure, a x-ms-copy-source-authorization nagłówek określa token OAuth. Akceptowalna wartość to backup . Ten nagłówek określa, że Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action lub Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action należy przyznać, jeśli są one uwzględnione w zasadach RBAC przypisanych do tożsamości autoryzowanej przy użyciu nagłówka x-ms-copy-source-authorization . Dostępne dla wersji 2025-07-05 i nowszych. |
Ciało żądania
Żaden.
Odpowiedź
Odpowiedź zawiera kod stanu HTTP i zestaw nagłówków odpowiedzi.
Kod stanu
Pomyślna operacja zwraca kod stanu 202 (Zaakceptowane).
Aby uzyskać informacje o kodach stanu, zobacz Stan i kody błędów.
Nagłówki odpowiedzi
Odpowiedź dla tej operacji zawiera następujące nagłówki. Odpowiedź może również zawierać dodatkowe standardowe nagłówki HTTP. Wszystkie standardowe nagłówki są zgodne ze specyfikacją protokołu HTTP/1.1 .
Nagłówek odpowiedzi | Opis |
---|---|
ETag |
Jeśli kopia jest kompletna, zawiera ETag wartość docelowego obiektu blob. Jeśli kopia nie jest kompletna, zawiera ETag wartość pustego obiektu blob utworzonego na początku kopii.Wartość ETag jest w cudzysłowie. |
Last-Modified |
Zwraca datę/godzinę zakończenia operacji kopiowania do docelowego obiektu blob. |
x-ms-request-id |
Jednoznacznie identyfikuje żądanie, które zostało wykonane. Można go użyć do rozwiązywania problemów z żądaniem. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z operacjami interfejsu API. |
x-ms-version |
Wskazuje wersję usługi Blob Storage, która jest używana do wykonania żądania. |
Date |
Wartość daty/godziny UTC wskazująca godzinę, o której usługa wysłała odpowiedź. |
x-ms-copy-id: <id> |
Identyfikator ciągu dla tej operacji kopiowania. |
x-ms-copy-status: <success> |
Wskazuje stan operacji kopiowania. Wartość oznacza success , że operacja zakończyła się pomyślnie. |
x-ms-client-request-id |
Może służyć do rozwiązywania problemów z żądaniami i odpowiadającymi odpowiedziami. Wartość tego nagłówka jest równa wartości nagłówka x-ms-client-request-id , jeśli jest obecna w żądaniu, a wartość wynosi najwyżej 1024 widoczne znaki ASCII. Jeśli nagłówek x-ms-client-request-id nie znajduje się w żądaniu, ten nagłówek nie będzie obecny w odpowiedzi. |
x-ms-request-server-encrypted: true/false |
Ustaw na true , jeśli zawartość żądania została pomyślnie zaszyfrowana za pomocą określonego algorytmu. W przeciwnym razie wartość to false . |
x-ms-encryption-scope |
Zwracane, jeśli żądanie używało zakresu szyfrowania, dzięki czemu klient może upewnić się, że zawartość żądania została pomyślnie zaszyfrowana za pośrednictwem zakresu szyfrowania. |
Ciało odpowiedzi
Żaden.
Przykładowa odpowiedź
Poniżej przedstawiono przykładową odpowiedź na żądanie skopiowania obiektu blob:
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>
Autoryzacja
Autoryzacja jest wymagana podczas wywoływania dowolnej operacji dostępu do danych w usłudze Azure Storage. W poniższej tabeli opisano sposób autoryzacji obiektów docelowych i źródłowych dla operacji Copy Blob From URL
:
Typ obiektu | Autoryzacja Microsoft Entra ID | Autoryzacja sygnatury dostępu współdzielonego (SAS) | Autoryzacja klucza współdzielonego (lub Shared Key Lite) |
---|---|---|---|
Docelowy blokowy obiekt blob | Tak | Tak | Tak |
Źródłowy blokowy obiekt blob na tym samym koncie magazynu | Tak | Tak | Tak |
Źródłowy blokowy obiekt blob na innym koncie magazynu | Nie. | Tak | Nie. |
Jeśli żądanie określa tagi w nagłówku x-ms-tags
żądania, obiekt wywołujący musi spełniać wymagania dotyczące autoryzacji operacji Ustaw tagi obiektu blob .
Możesz autoryzować operację Copy Blob From URL
zgodnie z poniższym opisem. Należy pamiętać, że źródłowy obiekt blob na innym koncie magazynu musi być autoryzowany oddzielnie za pośrednictwem tokenu SAS z uprawnieniem Odczyt (r). Aby uzyskać więcej informacji na temat autoryzacji źródłowego obiektu blob, zobacz szczegóły nagłówka x-ms-copy-source
żądania.
Ważne
Firma Microsoft zaleca używanie identyfikatora Entra firmy Microsoft z tożsamościami zarządzanymi w celu autoryzowania żądań do usługi Azure Storage. Identyfikator Entra firmy Microsoft zapewnia lepsze zabezpieczenia i łatwość użycia w porównaniu z autoryzacją klucza współdzielonego.
- Microsoft Entra ID (zalecane)
-
sygnatur dostępu współdzielonego (SAS)
- klucz udostępniony
Usługa Azure Storage obsługuje używanie identyfikatora Entra firmy Microsoft do autoryzowania żądań do danych obiektów blob. Za pomocą identyfikatora Entra firmy Microsoft możesz użyć kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby udzielić uprawnień podmiotowi zabezpieczeń. Podmiot zabezpieczeń może być użytkownikiem, grupą, jednostką usługi aplikacji lub tożsamością zarządzaną platformy Azure. Podmiot zabezpieczeń jest uwierzytelniany przez Microsoft Entra ID, aby zwrócić token OAuth 2.0. Token może następnie służyć do autoryzowania żądania względem usługi Blob Service.
Aby dowiedzieć się więcej o autoryzacji przy użyciu identyfikatora Entra firmy Microsoft, zobacz Autoryzowanie dostępu do obiektów blob przy użyciu identyfikatora Entra firmy Microsoft.
Uprawnienia
Poniżej wymieniono akcję RBAC niezbędną dla użytkownika microsoft Entra, grupy, tożsamości zarządzanej lub jednostki usługi w celu wywołania operacji Copy Blob From URL
oraz najmniej uprzywilejowanej wbudowanej roli RBAC platformy Azure, która obejmuje tę akcję:
Docelowy obiekt blob
- Akcja RBAC platformy Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write (do zapisu w istniejącym obiekcie blob) lub Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action (do zapisywania nowego obiektu blob w miejscu docelowym)
- wbudowana rola Najmniej uprzywilejowana: współautor danych obiektu blob usługiStorage
Źródłowy obiekt blob w ramach tego samego konta magazynu
- Akcja RBAC platformy Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
- Najmniej uprzywilejowana rola wbudowana:Storage Blob Data Reader
Aby dowiedzieć się więcej na temat przypisywania ról przy użyciu kontroli dostępu opartej na rolach platformy Azure, zobacz Assign an Azure role for access to blob data.
Uwagi
Źródłowy i docelowy Copy Blob From URL
obiekt blob dla operacji musi być blokowym obiektem blob.
W wersji 2020-10-02 lub nowszej autoryzacja firmy Microsoft Entra jest obsługiwana dla źródła operacji kopiowania.
Operacja Copy Blob From URL
zawsze kopiuje cały blob źródłowy. Kopiowanie zakresu bajtów lub zestawu bloków nie jest obsługiwane.
Źródłowy obiekt blob można skopiować do docelowego obiektu blob o innej nazwie. Docelowy obiekt blob może być istniejącym blokowym obiektem blob lub może to być nowy obiekt blob tworzony przez operację kopiowania.
Podczas kopiowania z blokowego obiektu blob kopiowane są wszystkie zatwierdzone bloki i ich identyfikatory bloków. Niezatwierdzone bloki nie są kopiowane. Na końcu operacji kopiowania docelowy obiekt blob będzie miał taką samą zatwierdzoną liczbę bloków jak źródło.
Wartość ETag
blokowego obiektu blob zmienia się po Copy Blob From URL
rozpoczęciu operacji i po jej zakończeniu.
Kopiowanie właściwości i metadanych obiektu blob
Po skopiowaniu blokowego obiektu blob następujące właściwości systemu są kopiowane do docelowego obiektu blob z tymi samymi wartościami:
Content-Type
Content-Encoding
Content-Language
Content-Length
Cache-Control
Content-MD5
Content-Disposition
Zatwierdzona lista bloków źródłowego obiektu blob jest również kopiowana do docelowego obiektu blob. Wszelkie niezatwierdzone bloki nie są kopiowane.
Docelowy obiekt blob ma zawsze taki sam rozmiar jak źródłowy obiekt blob, więc wartość nagłówka Content-Length
docelowego obiektu blob jest zgodna z wartością tego nagłówka źródłowego obiektu blob.
x-ms-tags
Jeśli nagłówek zawiera tagi dla docelowego obiektu blob, muszą one być zakodowane w ciągu zapytania. Klucze i wartości tagów muszą być zgodne z wymaganiami dotyczącymi nazewnictwa i długości określonymi w operacji Ustaw tagi obiektów blob .
Nagłówek x-ms-tags
może zawierać do 2 kilobitów tagów. Jeśli potrzebujesz więcej tagów, użyj Set Blob Tags
operacji.
x-ms-tags
Jeśli nagłówek nie zawiera tagów, tagi nie są kopiowane ze źródłowego obiektu blob.
Kopiowanie dzierżawionego obiektu blob
Operacja Copy Blob From URL
odczytuje tylko ze źródłowego obiektu blob, więc stan dzierżawy źródłowego obiektu blob nie ma znaczenia.
Fakturowanie
Żądania cen mogą pochodzić od klientów korzystających z interfejsów API usługi Blob Storage bezpośrednio za pośrednictwem interfejsu API REST usługi Blob Storage lub z biblioteki klienta usługi Azure Storage. Te żądania naliczają opłaty za transakcję. Typ transakcji wpływa na sposób naliczania opłat za konto. Na przykład transakcje odczytu są naliczane do innej kategorii rozliczeniowej niż transakcje zapisu. W poniższej tabeli przedstawiono kategorię rozliczeń dla żądań Copy Blob From URL
na podstawie typu konta magazynu:
Operacja | Typ konta magazynowania | Kategoria rozliczeń |
---|---|---|
Kopiowanie obiektu blob z adresu URL (konto docelowe1) | Obiekt Blob typu Premium Standard ogólnego przeznaczenia v2 Standardowa wersja do ogólnego użytku 1 |
Operacje zapisu |
Kopiowanie obiektu blob z adresu URL (konto źródłowe2) | Obiekt Blob typu Premium Standard ogólnego przeznaczenia v2 Standardowa wersja do ogólnego użytku 1 |
Operacje odczytu |
1Konto docelowe jest obciążane opłatą za jedną transakcję w celu zainicjowania zapisu.
cyfra arabskaKonto źródłowe generuje jedną transakcję dla każdego żądania odczytu do obiektu źródłowego.
Aby dowiedzieć się więcej o cenach dla określonych kategorii rozliczeń, zobacz Cennik usługi Azure Blob Storage.
Ponadto, jeśli konta źródłowe i docelowe znajdują się w różnych regionach (na przykład Północne stany USA i Południowe stany USA), przepustowość używana do transferu żądania jest obciążana źródłowym kontem magazynu jako ruch wychodzący. Ruch wychodzący między kontami w tym samym regionie jest bezpłatny.
Podczas kopiowania źródłowego obiektu blob do docelowego obiektu blob, który ma inną nazwę w ramach tego samego konta, należy użyć dodatkowych zasobów magazynu dla nowego obiektu blob. Operacja kopiowania powoduje następnie naliczenie opłaty za użycie pojemności konta magazynu dla tych dodatkowych zasobów.
Zobacz także
autoryzowanie żądań do usługi Azure Storage
kody stanu i błędów
kody błędów usługi Blob Storage
Informacje o tym, w jaki sposób migawki naliczają opłaty