Wdrażanie listy zablokowanych

  • Artykuł

Operacja Put Block List zapisuje obiekt blob, określając listę identyfikatorów blokowych tworzących obiekt blob. Aby można je było zapisać w ramach obiektu blob, blok musi zostać pomyślnie zapisany na serwerze we wcześniejszej operacji Put Block .

Możesz wywołać aktualizację Put Block List obiektu blob, przekazując tylko te bloki, które uległy zmianie, a następnie zatwierdzając nowe i istniejące bloki razem. Można to zrobić, określając, czy zatwierdzić blok z zatwierdzonej listy bloków, czy z niezatwierdzonej listy bloków, albo zatwierdzić ostatnio przekazaną wersję bloku, niezależnie od listy, do której należy.

Żądanie

Żądanie można skonstruować Put Block List w następujący sposób. Zalecamy używanie protokołu HTTPS. Zastąp ciąg myaccount nazwą konta magazynu:

IDENTYFIKATOR URI żądania PUT Wersja PROTOKOŁU HTTP
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1

Żądanie usługi magazynu emulowanego

Podczas wysyłania żądania względem emulowanej usługi magazynu określ nazwę hosta emulatora i port usługi Blob Service jako 127.0.0.1:10000, a następnie nazwę emulowanego konta magazynu:

IDENTYFIKATOR URI żądania PUT Wersja PROTOKOŁU HTTP
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist HTTP/1.1

Emulator magazynu obsługuje tylko rozmiary obiektów blob o rozmiarach maksymalnie 2 gibibajtów (GiB).

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

W identyfikatorze URI żądania można określić następujące dodatkowe parametry:

Parametr Opis
timeout Opcjonalny. Parametr jest wyrażony timeout w sekundach. Aby uzyskać więcej informacji, zobacz Ustawianie limitów czasu dla operacji usługi Blob Service.

Nagłówki żądań

Wymagane i opcjonalne nagłówki żądań opisano w poniższej tabeli:

Nagłówek żądania Opis
Authorization 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 Wymagane. Określa dla żądania godzinę w formacie uniwersalnego czasu koordynowanego (UTC). Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage.
x-ms-version Wymagane dla wszystkich autoryzowanych żądań. Określa wersję operacji do użycia dla tego żądania. Aby uzyskać więcej informacji, zobacz Przechowywanie wersji usług Azure Storage.
Content-Length Wymagane. Długość zawartości żądania w bajtach. Ten nagłówek odnosi się do długości zawartości listy bloków, a nie samego obiektu blob.
Content-MD5 Opcjonalny. Skrót MD5 zawartości żądania. Ten skrót służy do weryfikowania integralności zawartości żądania podczas transportu. Jeśli dwa skróty nie są zgodne, operacja kończy się niepowodzeniem z kodem błędu 400 (Nieprawidłowe żądanie).

Ten nagłówek jest skojarzony z zawartością żądania, a nie z zawartością samego obiektu blob.
x-ms-content-crc64 Opcjonalny. Skrót CRC64 zawartości żądania. Ten skrót służy do weryfikowania integralności zawartości żądania podczas transportu. Jeśli dwa skróty nie są zgodne, operacja kończy się niepowodzeniem z kodem błędu 400 (Nieprawidłowe żądanie).

Ten nagłówek jest skojarzony z zawartością żądania, a nie z zawartością samego obiektu blob.

Jeśli istnieją nagłówki Content-MD5 i x-ms-content-crc64, żądanie kończy się niepowodzeniem z błędem 400 (nieprawidłowe żądanie).

Ten nagłówek jest obsługiwany w wersji 2019-02-02 i nowszej.
x-ms-blob-cache-control Opcjonalny. Ustawia kontrolkę pamięci podręcznej obiektu blob. Jeśli ta właściwość jest określona, jest ona przechowywana w obiekcie blob i zwracana z żądaniem odczytu.

Jeśli właściwość nie zostanie określona z żądaniem, zostanie wyczyszczone dla obiektu blob, jeśli żądanie zakończy się pomyślnie.
x-ms-blob-content-type Opcjonalny. Ustawia typ zawartości obiektu blob. Jeśli jest określona, ta właściwość jest przechowywana w obiekcie blob i zwracana z żądaniem odczytu.

Jeśli typ zawartości nie jest określony, jest on ustawiony na typ domyślny, czyli application/octet-stream.
x-ms-blob-content-encoding Opcjonalny. Ustawia kodowanie zawartości obiektu blob. Jeśli jest określona, ta właściwość jest przechowywana w obiekcie blob i zwracana z żądaniem odczytu.

Jeśli właściwość nie zostanie określona z żądaniem, zostanie wyczyszczone dla obiektu blob, jeśli żądanie zakończy się pomyślnie.
x-ms-blob-content-language Opcjonalny. Ustawia język zawartości obiektu blob. Jeśli jest określona, ta właściwość jest przechowywana w obiekcie blob i zwracana z żądaniem odczytu.

Jeśli właściwość nie zostanie określona z żądaniem, zostanie wyczyszczone dla obiektu blob, jeśli żądanie zakończy się pomyślnie.
x-ms-blob-content-md5 Opcjonalny. Skrót MD5 zawartości obiektu blob. Ten skrót nie jest weryfikowany, ponieważ skróty poszczególnych bloków zostały zweryfikowane po przekazaniu każdego z nich.

Operacja Get Blob zwraca wartość tego nagłówka w nagłówku odpowiedzi Content-MD5.

Jeśli ta właściwość nie zostanie określona z żądaniem, zostanie wyczyszczone dla obiektu blob, jeśli żądanie zakończy się pomyślnie.
x-ms-meta-name:value Opcjonalny. Pary nazwa-wartość zdefiniowana przez użytkownika, które są skojarzone z obiektem blob.

Od wersji 2009-09-19 nazwy metadanych muszą być zgodne z regułami nazewnictwa identyfikatorów języka C#.
x-ms-encryption-scope Opcjonalny. Wskazuje zakres szyfrowania używany do szyfrowania obiektu blob. Ta wartość musi być zgodna z zakresem szyfrowania używanym do szyfrowania wszystkich zatwierdzonych bloków. Ten nagłówek jest obsługiwany w wersji 2019-02-02 i nowszej.
x-ms-encryption-context Opcjonalny. Wartość domyślna to "Empty" (Puste). Jeśli wartość zostanie ustawiona, ustawi metadane systemu obiektów blob. Maksymalna długość-1024. Prawidłowe tylko wtedy, gdy hierarchiczna przestrzeń nazw jest włączona dla konta. Ten nagłówek jest obsługiwany w wersjach 2021-08-06 i nowszych.
x-ms-tags Opcjonalny. Ustawia określone tagi zakodowane w ciągu zapytania w obiekcie blob. Aby uzyskać dodatkowe informacje, zobacz sekcję Uwagi . Obsługiwane w wersji 2019-12-12 lub nowszej.
x-ms-lease-id:<ID> Wymagane, jeśli obiekt blob ma aktywną dzierżawę. Aby wykonać tę operację na obiekcie blob z aktywną dzierżawą, określ prawidłowy identyfikator dzierżawy dla tego nagłówka.
x-ms-client-request-id Opcjonalny. Udostępnia nieprzezroczystą wartość wygenerowaną przez klienta z limitem znaków 1-kibibyte (KiB), który jest rejestrowany w dziennikach analitycznych podczas konfigurowania rejestrowania analizy magazynu. Zdecydowanie zalecamy używanie tego nagłówka do korelowania działań po stronie klienta z żądaniami odbieranymi przez serwer.
x-ms-blob-content-disposition Opcjonalny. Ustawia nagłówek obiektu blob Content-Disposition . Dostępne dla wersji 2013-08-15 lub nowszej.

Pole nagłówka Content-Disposition przekazuje dodatkowe informacje na temat przetwarzania ładunku odpowiedzi i może służyć do dołączania dodatkowych metadanych. Jeśli na przykład ustawiono attachmentwartość , ten nagłówek wskazuje, że agent-użytkownik nie powinien wyświetlać odpowiedzi, ale zamiast tego powinien wyświetlić okno dialogowe Zapisz jako.

Odpowiedź z operacji Pobierz obiekt blob i Pobierz właściwości obiektu blob zawiera nagłówek content-disposition.
x-ms-access-tier Opcjonalny. Wersja 2018-11-09 lub nowsza. Wskazuje warstwę, która ma zostać ustawiona na obiekcie blob. W przypadku blokowych obiektów blob ten nagłówek jest obsługiwany na kontach magazynu obiektów blob lub ogólnego przeznaczenia w wersji 2 tylko w wersji 2018-11-09 lub nowszej. Prawidłowe wartości dla warstw blokowych obiektów blob to Hot, Cool, Coldi Archive. Uwaga: Cold warstwa 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-immutability-policy-until-date Wersja 2020-06-12 lub nowsza. Określa okres przechowywania do daty ustawienia obiektu blob. Jest to data, do której obiekt blob może być chroniony przed modyfikacją lub usunięciem. Jest zgodny z formatem RFC1123.
x-ms-immutability-policy-mode Wersja 2020-06-12 lub nowsza. Określa tryb zasad niezmienności, który ma być ustawiony na obiekcie blob. Prawidłowe wartości to unlocked i locked. Wartość unlocked wskazuje, że użytkownicy mogą zmieniać zasady, zwiększając lub zmniejszając okres przechowywania do daty. Wartość locked wskazuje, że te działania są zabronione.
x-ms-legal-hold Wersja 2020-06-12 lub nowsza. Określa blokadę prawną, która ma zostać ustawiona na obiekcie blob. Prawidłowe wartości to true i false.
x-ms-expiry-option Opcjonalny. Wersja 2023-08-03 lub nowsza. Określa opcję daty wygaśnięcia żądania, zobacz WygaśnięcieOption. Ten nagłówek jest prawidłowy dla kont z włączoną hierarchiczną przestrzenią nazw.
x-ms-expiry-time Opcjonalny. Wersja 2023-08-03 lub nowsza. Określa godzinę wygaśnięcia obiektu blob. Format daty wygaśnięcia różni się w zależności od x-ms-expiry-option. Aby uzyskać więcej informacji, zobacz WygaśnięcieOption. Ten nagłówek jest prawidłowy dla kont z włączoną hierarchiczną przestrzenią nazw.

Obiekt expiryTime blob już obecny nie jest czyszczone, jeśli żądanie nie zawiera nowej wartości expiryTime

Ta operacja obsługuje również używanie nagłówków warunkowych do zatwierdzania listy bloków tylko wtedy, gdy zostanie spełniony określony warunek. Aby uzyskać więcej informacji, zobacz Określanie nagłówków warunkowych dla operacji usługi Blob Storage.

Nagłówki żądań (klucze szyfrowania dostarczone przez klienta)

Od wersji 2019-02-02 można określić następujące nagłówki na żądanie szyfrowania obiektu blob przy użyciu klucza dostarczonego przez klienta. Szyfrowanie przy użyciu klucza dostarczonego przez klienta (i odpowiedniego zestawu nagłówków) jest opcjonalne.

Nagłówek żądania Opis
x-ms-encryption-key Wymagane. Klucz szyfrowania AES-256 zakodowany w formacie Base64.
x-ms-encryption-key-sha256 Wymagane. Skrót SHA256 zakodowany w formacie Base64 klucza szyfrowania.
x-ms-encryption-algorithm: AES256 Wymagane. Określa algorytm do użycia do szyfrowania. Wartość tego nagłówka musi mieć wartość AES256.

Treść żądania

W treści żądania można określić listę bloków, którą usługa Blob Storage powinna sprawdzić pod kątem żądanego bloku. W ten sposób można zaktualizować istniejący obiekt blob, wstawiając, zastępując lub usuwając poszczególne bloki, zamiast ponownie ładować cały obiekt blob. Po przekazaniu bloków lub bloków, które uległy zmianie, możesz zatwierdzić nową wersję obiektu blob, zatwierdzając nowe bloki wraz z istniejącymi blokami, które chcesz zachować.

Aby zaktualizować obiekt blob, możesz określić, że usługa powinna szukać identyfikatora bloku na liście zatwierdzonych bloków, na liście niezatwierdzonych bloków lub na liście niezatwierdzonych bloków, a następnie na liście zatwierdzonych bloków. Aby wskazać, które podejście ma być używane, określ identyfikator bloku, który znajduje się w odpowiednim elemecie XML w treści żądania, w następujący sposób:

  • Określ identyfikator bloku w elemecie Committed , aby wskazać, że usługa Blob Storage powinna wyszukiwać tylko zatwierdzoną listę bloków dla nazwanego bloku. Jeśli blok nie zostanie znaleziony na liście zatwierdzonych bloków, nie jest zapisywany jako część obiektu blob, a usługa Blob Storage zwraca kod stanu 400 (nieprawidłowe żądanie).

  • Określ identyfikator bloku w elemecie Uncommitted , aby wskazać, że usługa Blob Storage powinna wyszukiwać tylko niezatwierdzone listy bloków dla nazwanego bloku. Jeśli blok nie zostanie znaleziony na liście niezatwierdzonych bloków, nie jest zapisywany jako część obiektu blob, a usługa Blob Storage zwraca kod stanu 400 (nieprawidłowe żądanie).

  • Określ identyfikator bloku w elemecie Latest , aby wskazać, że usługa Blob Storage powinna najpierw przeszukać niezatwierdzone listy bloków. Jeśli blok zostanie znaleziony na liście niezatwierdzonych, ta wersja bloku jest najnowsza i powinna zostać zapisana w obiekcie blob. Jeśli blok nie zostanie znaleziony na liście niezatwierdzonych, usługa powinna wyszukać zatwierdzoną listę bloków dla nazwanego bloku i zapisać ten blok do obiektu blob, jeśli zostanie znaleziony.

Treść żądania dla tej wersji używa następującego Put Block List formatu XML:

<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Committed>first-base64-encoded-block-id</Committed>  
  <Uncommitted>second-base64-encoded-block-id</Uncommitted>  
  <Latest>third-base64-encoded-block-id</Latest>  
  ...  
</BlockList>

Przykładowe żądanie

Aby zademonstrować Put Block List, załóżmy, że przekazano trzy bloki, które chcesz teraz zatwierdzić. Poniższy przykład zatwierdza nowy obiekt blob, wskazując, że powinna być używana najnowsza wersja każdego bloku. Nie trzeba wiedzieć, czy te bloki zostały już zatwierdzone.

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Latest>AAAAAA==</Latest>  
  <Latest>AQAAAA==</Latest>  
  <Latest>AZAAAA==</Latest>  
</BlockList>

Następnie załóżmy, że chcesz zaktualizować obiekt blob. Nowy obiekt blob ma następujące zmiany:

  • Nowy blok o identyfikatorze ANAAAA==. Ten blok musi najpierw zostać przekazany za pomocą wywołania funkcji Put Block i pojawi się na liście niezatwierdzonych bloków do momentu wywołania polecenia Put Block List.

  • Zaktualizowana wersja bloku o identyfikatorze AZAAAA==. Ten blok musi najpierw zostać przekazany za pomocą wywołania funkcji Put Block i pojawi się na liście niezatwierdzonych bloków do momentu wywołania polecenia Put Block List.

  • Usunięcie bloku z identyfikatorem AAAAAA==. Ponieważ ten blok nie jest uwzględniony w następnym wywołaniu metody Put Block List, blok jest skutecznie usuwany z obiektu blob.

W poniższym przykładzie pokazano wywołanie aktualizacji Put Block List obiektu blob:

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2009 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
x-ms-expiry-option: RelativeToNow
x-ms-expiry-time: 30000
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Uncommitted>ANAAAA==</Uncommitted>  
  <Committed>AQAAAA==</Committed>  
  <Uncommitted>AZAAAA==</Uncommitted>  
</BlockList>

Reakcja

Odpowiedź zawiera kod stanu HTTP i zestaw nagłówków odpowiedzi.

Kod stanu

Operacja zakończona powodzeniem zwraca kod stanu 201 (utworzono).

Aby uzyskać więcej informacji na temat kodów stanu, zobacz Kody stanu i błędów.

Nagłówki odpowiedzi

Odpowiedź na tę operację zawiera następujące nagłówki. Odpowiedź może również zawierać dodatkowe standardowe nagłówki HTTP. Wszystkie nagłówki standardowe są zgodne ze specyfikacją protokołu HTTP/1.1.

Reakcja Opisy
ETag Tag jednostki zawiera wartość, za pomocą którą klient może wykonywać operacje warunkowe GET/PUT przy użyciu nagłówka If-Match żądania. Jeśli wersja żądania to 2011-08-18 lub nowsza, wartość ETag jest ujęta w cudzysłów.
Last-Modified Data/godzina ostatniej modyfikacji obiektu blob. Format daty jest zgodny z RFC 1123. Aby uzyskać więcej informacji, zobacz Reprezentacja wartości daty/godziny w nagłówkach.

Każda operacja modyfikując obiekt blob, w tym aktualizację metadanych lub właściwości obiektu blob, zmienia czas ostatniej modyfikacji obiektu blob.
Content-MD5 Zwrócono, aby klient mógł sprawdzić integralność zawartości komunikatu. Ten nagłówek odnosi się do zawartości żądania (w tym przypadku lista bloków, a nie zawartość samego obiektu blob). W przypadku wersji 2019-02-02 i nowszej ten nagłówek jest zwracany tylko wtedy, gdy żądanie ma ten nagłówek.
x-ms-content-crc64 W przypadku wersji 2019-02-02 i nowszej ten nagłówek jest zwracany, aby klient mógł sprawdzić integralność zawartości komunikatu. Ten nagłówek odnosi się do zawartości żądania (w tym przypadku lista bloków, a nie zawartość samego obiektu blob).

Ten nagłówek jest zwracany, gdy Content-md5 nagłówek nie jest obecny w żądaniu.
x-ms-request-id Unikatowo identyfikuje wykonane żądanie i 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 Wersja usługi Blob Storage używana do wykonania żądania. Ten nagłówek jest zwracany dla żądań wysyłanych w wersji 2009-09-19 i nowszych.
Date Wartość daty/godziny UTC wygenerowana przez usługę, która wskazuje, kiedy zainicjowano odpowiedź.
x-ms-request-server-encrypted: true/false Wersja 2015-12-11 lub nowsza. Wartość tego nagłówka jest ustawiana na true wartość , jeśli zawartość żądania zostanie pomyślnie zaszyfrowana przy użyciu określonego algorytmu. W przeciwnym razie wartość jest ustawiona na false.
x-ms-encryption-key-sha256 Wersja 2019-02-02 lub nowsza. Ten nagłówek jest zwracany, jeśli żądanie użyło klucza dostarczonego przez klienta do szyfrowania, aby klient mógł upewnić się, że zawartość żądania została pomyślnie zaszyfrowana przy użyciu podanego klucza.
x-ms-encryption-scope Wersja 2019-02-02 lub nowsza. Ten nagłówek jest zwracany, jeśli żądanie użyło zakresu szyfrowania, aby klient mógł upewnić się, że zawartość żądania została pomyślnie zaszyfrowana przy użyciu zakresu szyfrowania.
x-ms-version-id: <DateTime> Wersja 2019-12-12 lub nowsza. Zwraca nieprzezroczystą DateTime wartość, która jednoznacznie identyfikuje obiekt blob. Wartość tego nagłówka wskazuje wersję obiektu blob i może być używana w kolejnych żądaniach dostępu do obiektu blob.
x-ms-client-request-id Może służyć do rozwiązywania problemów z żądaniami i odpowiadającymi im odpowiedziami. Wartość tego nagłówka jest równa wartości x-ms-client-request-id nagłówka, jeśli znajduje się w żądaniu, a wartość nie zawiera więcej niż 1024 widocznych znaków ASCII. x-ms-client-request-id Jeśli nagłówek nie znajduje się w żądaniu, nie jest obecny w odpowiedzi.

Przykładowa odpowiedź

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sun, 25 Sep 2011 00:17:44 GMT  
ETag: “0x8CB172A360EC34B”  
Last-Modified: Sun, 25 Sep 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-version-id: <DateTime>

Autoryzacja

Autoryzacja jest wymagana podczas wywoływania dowolnej operacji dostępu do danych w usłudze Azure Storage. Możesz autoryzować operację zgodnie z Put Block List poniższym opisem.

Jeśli żądanie określa tagi z nagłówkiem x-ms-tags żądania, obiekt wywołujący musi spełniać wymagania autoryzacji operacji Ustawianie tagów obiektów blob .

Usługa Azure Storage obsługuje używanie Tożsamość Microsoft Entra do autoryzacji żądań do danych obiektów blob. Za pomocą Tożsamość Microsoft Entra 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 Tożsamość Microsoft Entra w celu zwrócenia tokenu 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 na temat autoryzacji przy użyciu Tożsamość Microsoft Entra, zobacz Autoryzowanie dostępu do obiektów blob przy użyciu Tożsamość Microsoft Entra.

Uprawnienia

Poniżej wymieniono akcję RBAC niezbędną do wywołania Put Block List operacji przez użytkownika, grupę lub jednostkę usługi Microsoft Entra oraz najmniej uprzywilejowaną wbudowaną rolę RBAC platformy Azure, która obejmuje tę akcję:

Aby dowiedzieć się więcej na temat przypisywania ról przy użyciu kontroli dostępu opartej na rolach platformy Azure, zobacz Przypisywanie roli platformy Azure w celu uzyskania dostępu do danych obiektów blob.

Uwagi

Operacja Put Block List wymusza kolejność łączenia bloków w celu utworzenia obiektu blob.

Ten sam identyfikator bloku można określić więcej niż jeden raz na liście bloków. Jeśli identyfikator bloku jest określony więcej niż jeden raz, reprezentuje zakres bajtów w każdej z tych lokalizacji na liście bloków dla końcowego zatwierdzonego obiektu blob. Jeśli identyfikator bloku pojawia się więcej niż raz na liście, oba wystąpienia identyfikatora bloku muszą być określone na tej samej liście bloków. Innymi słowy, oba wystąpienia muszą być określone w elemecie Committed , Uncommitted elemecie lub elemecie Latest .

Za pomocą Put Block Listpolecenia można zmodyfikować istniejący obiekt blob, wstawiając, aktualizując lub usuwając poszczególne bloki bez konieczności ponownego przekazywania całego obiektu blob. Identyfikatory bloków można określić zarówno z bieżącej zatwierdzonej listy bloków, jak i niezatwierdzonej listy bloków, aby utworzyć nowy obiekt blob lub zaktualizować zawartość istniejącego obiektu blob. W ten sposób można zaktualizować obiekt blob, określając kilka nowych bloków z niezatwierdzonej listy bloków, a pozostałe z zatwierdzonej listy bloków, które są już częścią istniejącego obiektu blob.

Jeśli identyfikator bloku jest określony w Latest elemecie, a ten sam identyfikator bloku istnieje zarówno na zatwierdzonych, jak i niezatwierdzonych listach bloków, Put Block List zatwierdza blok z niezatwierdzonej listy bloków. Jeśli identyfikator bloku istnieje na liście zatwierdzonych bloków, ale nie na liście niezatwierdzonych bloków, Put Block List zatwierdza blok z zatwierdzonej listy bloków.

Każdy blok w blokowym obiekcie blob może mieć inny rozmiar. Blokowy obiekt blob może zawierać maksymalnie 50 000 zatwierdzonych bloków. Maksymalna liczba niezatwierdzonych bloków, które mogą być skojarzone z obiektem blob, wynosi 100 000.

W poniższej tabeli opisano maksymalne dozwolone rozmiary bloków i obiektów blob według wersji usługi:

Wersja usługi Maksymalny rozmiar bloku (za pośrednictwem Put Block) Maksymalny rozmiar obiektu blob (za pośrednictwem Put Block List) Maksymalny rozmiar obiektu blob za pośrednictwem operacji pojedynczego zapisu (za pośrednictwem Put Blob)
Wersja 2019-12-12 lub nowsza 4000 mebibajtów (MiB) Około 190,7 tebibajtów (TiB) (4000 miB × 50 000 bloków) 5000 MiB
Wersje 2016-05-31 do 2019-07-07 100 MiB Około 4,75 TiB (100 MiB × 50 000 bloków) 256 MiB
Wersje starsze niż 2016-05-31 4 MiB Około 195 GiB (4 MiB × 50 000 bloków) 64 MiB

Podczas wywoływania Put Block List aktualizacji istniejącego obiektu blob istniejące właściwości i metadane obiektu blob są zastępowane. Jednak wszystkie istniejące migawki są zachowywane za pomocą obiektu blob. Nagłówki żądania warunkowego umożliwiają wykonanie operacji tylko wtedy, gdy zostanie spełniony określony warunek.

Put Block List Jeśli operacja nie powiedzie się z powodu brakującego bloku, musisz przekazać brakujący blok.

Wszystkie niezatwierdzone bloki są odśmiecane, jeśli nie ma pomyślnych wywołań do Put Block obiektu blob lub Put Block List w ciągu tygodnia po ostatniej pomyślnej Put Block operacji. Jeśli obiekt Blob Put jest wywoływany w obiekcie blob, wszystkie niezatwierdzone bloki są zbierane.

Jeśli tagi są podane w nagłówku x-ms-tags , muszą być zakodowane w ciągu zapytania. Klucze i wartości tagów muszą być zgodne z wymaganiami dotyczącymi nazewnictwa i długości, jak określono w temacie Set Blob Tags. x-ms-tags Ponadto nagłówek może zawierać tagi o rozmiarze do 2 kiB. Jeśli wymagane jest więcej tagów, użyj operacji Ustaw tagi obiektów blob .

Jeśli obiekt blob ma aktywną dzierżawę, klient musi określić prawidłowy identyfikator dzierżawy na żądaniu zatwierdzenia listy zablokowanych. Jeśli klient nie określi identyfikatora dzierżawy lub określi nieprawidłowy identyfikator dzierżawy, usługa Blob Storage zwraca kod stanu 412 (Niepowodzenie warunku wstępnego). Jeśli klient określa identyfikator dzierżawy, ale obiekt blob nie ma aktywnej dzierżawy, usługa Blob Storage zwraca również kod stanu 412 (Niepowodzenie warunku wstępnego). Jeśli klient określa identyfikator dzierżawy obiektu blob, który jeszcze nie istnieje, usługa Blob Storage zwraca kod stanu 412 (Niepowodzenie warunku wstępnego) dla żądań wysyłanych w wersji 2013-08-15 lub nowszej. W przypadku wcześniejszych wersji usługa Blob Storage zwraca kod stanu 201 (Utworzono).

Jeśli obiekt blob ma aktywną dzierżawę i wywołujesz Put Block List polecenie w celu zaktualizowania obiektu blob, dzierżawa jest utrzymywana w zaktualizowanym obiekcie blob.

Put Block List dotyczy tylko blokowych obiektów blob. Wywołanie Put Block List stronicowego obiektu blob powoduje wyświetlenie kodu stanu 400 (nieprawidłowe żądanie).

Zastępowanie zarchiwizowanego obiektu blob kończy się niepowodzeniem i zastąpienie obiektu hot lub cool obiektu blob dziedziczy warstwę ze starego obiektu blob, jeśli nagłówek x-ms-access-tier nie jest podany.

Rozliczenia

Żą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 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 w innej kategorii rozliczeniowej niż transakcje zapisu. W poniższej tabeli przedstawiono kategorię rozliczeń dla Put Block List żądań na podstawie typu konta magazynu:

Operacja Typ konta magazynu Kategoria rozliczeń
Wdrażanie listy zablokowanych Blokowy obiekt blob w warstwie Premium
Standardowa ogólnego przeznaczenia, wersja 2
Standardowa ogólnego przeznaczenia, wersja 1		 Operacje zapisu

Aby dowiedzieć się więcej o cenach dla określonej kategorii rozliczeniowej, zobacz Azure Blob Storage Cennik.

Zobacz też

Omówienie blokowych obiektów blob, uzupełnialnych obiektów blob i stronicowych obiektów blob
Autoryzowanie żądań do usługi Azure Storage
Kody stanu i błędów
Kody błędów usługi Blob Service
Ustawianie limitów czasu dla operacji usługi Blob Service