Udostępnij za pośrednictwem

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 zawiera dodatkowe informacje o sposobie 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 obejmuje nagłówek content-disposition.
x-ms-access-tier Opcjonalny. Wersja 2018-11-09 lub nowsza. Wskazuje warstwę, która ma zostać ustawiona na obiekt blob. W przypadku blokowych obiektów blob ten nagłówek jest obsługiwany na kontach usługi Blob Storage lub ogólnego przeznaczenia w wersji 2 tylko w wersji 2018-11-09 lub nowszej. Prawidłowe wartości 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, który ma zostać ustawiony w obiekcie 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 w obiekcie blob. Prawidłowe wartości to unlocked i locked. Wartość unlocked wskazuje, że użytkownicy mogą zmieniać zasady przez zwiększenie lub zmniejszenie okresu przechowywania do daty. Wartość locked wskazuje, że te działania są zabronione.
x-ms-legal-hold Wersja 2020-06-12 lub nowsza. Określa archiwizację prawną, która ma zostać ustawiona w 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 dla żądania, zobacz ExpirationyOption. 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 czas 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 ExpiryOption. Ten nagłówek jest prawidłowy dla kont z włączoną hierarchiczną przestrzenią nazw.

Obiekt expiryTime już obecny w obiekcie blob 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)

Począwszy od wersji 2019-02-02, można określić następujące nagłówki w żądaniu szyfrowania obiektu blob przy użyciu klucza dostarczonego przez klienta. Szyfrowanie przy użyciu klucza dostarczonego przez klienta (i odpowiadającego mu 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 na potrzeby 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 zmienionych bloków lub bloków 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 zatwierdzonej liście bloków, na liście niezatwierdzonych bloków lub najpierw na liście niezatwierdzonych bloków, a następnie na zatwierdzonej liście bloków. Aby wskazać, które podejście ma być używane, określ identyfikator bloku, który należy do odpowiedniego elementu 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 zatwierdzonej liście blokowej, nie zostanie on zapisany jako część obiektu blob, a usługa Blob Storage zwróci kod stanu 400 (nieprawidłowe żądanie).

  • Określ identyfikator bloku w elemecie Uncommitted , aby wskazać, że usługa Blob Storage powinna przeszukiwać tylko niezatwierdzone listy bloków dla nazwanego bloku. Jeśli blok nie zostanie znaleziony na liście niezatwierdzonych bloków, nie zostanie on zapisany jako część obiektu blob, a usługa Blob Storage zwróci 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 blokowej. 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 w obiekcie blob, jeśli zostanie znaleziony.

Treść żądania dla tej wersji programu 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 Listprogram , 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 należy najpierw przekazać za pomocą wywołania funkcji Put Block i pojawia się na liście niezatwierdzonych bloków do momentu wywołania metody Put Block List.

  • Zaktualizowana wersja bloku o identyfikatorze AZAAAA==. Ten blok należy najpierw przekazać za pomocą wywołania funkcji Put Block i pojawia się na liście niezatwierdzonych bloków do momentu wywołania metody Put Block List.

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

W poniższym przykładzie pokazano wywołanie obiektu blob, które Put Block List aktualizuje obiekt 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

Pomyślna operacja zwraca kod stanu 201 (Utworzony).

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 standardowe nagłówki są zgodne ze specyfikacją protokołu HTTP/1.1.

Reakcja Opisy
ETag Tag jednostki zawiera wartość, która może być używana przez klienta do wykonywania operacji warunkowych GET/PUT przy użyciu nagłówka If-Match żądania. Jeśli wersja żądania to 2011-08-18 lub nowsza, wartość elementu ETag jest ujęta w cudzysłów.
Last-Modified Data/godzina ostatniej modyfikacji obiektu blob. Format daty jest zgodny z dokumentem 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ócone, 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 lub 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 nowszych 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 żądanie, które zostało wykonane, 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 w przypadku żądań wysyłanych w wersji 2009-09-19 lub nowszej.
Date Wartość daty/godziny UTC wygenerowana przez usługę, która wskazuje, kiedy została zainicjowana 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 została 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żywa klucza dostarczonego przez klienta do szyfrowania, dzięki czemu klient może 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żywa zakresu szyfrowania, dzięki czemu klient może 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 jest obecna w żądaniu, a wartość zawiera nie więcej niż 1024 widoczne znaki 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ę Put Block List zgodnie z 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 .

Ważne

Firma Microsoft zaleca używanie Tożsamość Microsoft Entra z tożsamościami zarządzanymi w celu autoryzowania żądań do usługi Azure Storage. Tożsamość Microsoft Entra zapewnia doskonałe zabezpieczenia i łatwość użycia w porównaniu z autoryzacją klucza wspólnego.

Usługa Azure Storage obsługuje autoryzację żądań do danych obiektów blob przy użyciu Tożsamość Microsoft Entra. Dzięki 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 przedstawiono akcję RBAC niezbędną dla użytkownika Microsoft Entra, grupy, tożsamości zarządzanej lub jednostki usługi w celu wywołania Put Block List operacji oraz najmniej uprzywilejowanej wbudowanej roli 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 zablokowanych. 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. Możesz określić identyfikatory bloków zarówno z bieżącej zatwierdzonej listy bloków, jak i niezatwierdzonych 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 w elemecie określono Latest identyfikator bloku, a ten sam identyfikator bloku istnieje zarówno na listach zablokowanych zatwierdzonych, jak i niezatwierdzonych, 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 Blobmetody )
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

Po wywołaniu aktualizacji Put Block List istniejącego obiektu blob istniejące właściwości i metadane obiektu blob zostaną zastąpione. Jednak wszystkie istniejące migawki są zachowywane za pomocą obiektu blob. Możesz użyć nagłówków żądania warunkowego, aby wykonać operację tylko wtedy, gdy zostanie spełniony określony warunek.

Put Block List Jeśli operacja zakończy się niepowodzeniem z powodu brakującego bloku, musisz przekazać brakujący blok.

Wszystkie niezatwierdzone bloki są odśmiecane, jeśli nie ma żadnych pomyślnych wywołań do Put Block lub Put Block List do obiektu blob 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 w pamięci.

Jeśli tagi są podane w nagłówku x-ms-tags , muszą być zakodowane w ciągu zapytania. Klucze tagów i wartości muszą być zgodne z wymaganiami dotyczącymi nazewnictwa i długości, jak określono w pliku Set Blob Tags. x-ms-tags Ponadto nagłówek może zawierać tagi o rozmiarze do 2 KiB. Jeśli wymagana 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 bloków. Jeśli klient nie określi identyfikatora dzierżawy lub określa nieprawidłowy identyfikator dzierżawy, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiodło się). 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 (Warunek wstępny nie powiodło się). Jeśli klient określa identyfikator dzierżawy obiektu blob, który jeszcze nie istnieje, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiodło się) 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łasz aktualizację Put Block List obiektu blob, dzierżawa jest utrzymywana w zaktualizowanym obiekcie blob.

Put Block List dotyczy tylko blokowych obiektów blob. Wywoływanie 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 blob cool dziedziczy warstwę ze starego obiektu blob, jeśli nie podano nagłówka x-ms-access-tier.

Rozliczenia

Żądania cenowe 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 do 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 rozliczeń, 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