Put Block List

Artikel
02/07/2024

Åtgärden Put Block List skriver en blob genom att ange listan över block-ID:t som utgör bloben. För att kunna skrivas som en del av en blob måste ett block ha skrivits till servern i en tidigare Put Block-åtgärd .

Du kan anropa Put Block List för att uppdatera en blob genom att bara ladda upp de block som har ändrats och sedan checka in de nya och befintliga blocken tillsammans. Du kan göra detta genom att ange om du vill checka in ett block från listan över bekräftade block eller från listan över ej bekräftade block, eller om du vill checka in den senast uppladdade versionen av blocket, beroende på vilken lista det tillhör.

Förfrågan

Du kan skapa begäran på Put Block List följande sätt. Vi rekommenderar att du använder HTTPS. Ersätt myaccount med namnet på ditt lagringskonto:

URI för PUT-metodbegäran	HTTP-version
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist`	HTTP/1.1

Emulerad lagringstjänstbegäran

När du gör en begäran mot den emulerade lagringstjänsten anger du emulatorns värdnamn och blobtjänstporten som 127.0.0.1:10000, följt av namnet på det emulerade lagringskontot:

URI för PUT-metodbegäran	HTTP-version
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist`	HTTP/1.1

Lagringsemulatorn stöder endast blobstorlekar på upp till 2 gibibyte (GiB).

Mer information finns i Använda Azurite-emulatorn för lokal Azure Storage-utveckling.

URI-parametrar

Du kan ange följande ytterligare parametrar för begärande-URI:n:

Parameter	Beskrivning
`timeout`	Valfritt. Parametern `timeout` uttrycks i sekunder. Mer information finns i Ange tidsgränser för blobtjänståtgärder.

Begärandehuvuden

De obligatoriska och valfria begäranderubrikerna beskrivs i följande tabell:

Begärandehuvud	Beskrivning
`Authorization`	Krävs. Anger auktoriseringsschema, kontonamn och signatur. Mer information finns i Auktorisera begäranden till Azure Storage.
`Date` eller `x-ms-date`	Krävs. Anger Coordinated Universal Time (UTC) för begäran. Mer information finns i Auktorisera begäranden till Azure Storage.
`x-ms-version`	Krävs för alla auktoriserade begäranden. Anger vilken version av åtgärden som ska användas för den här begäran. Mer information finns i Versionshantering för Azure Storage-tjänsterna.
`Content-Length`	Krävs. Längden på begärandeinnehållet i byte. Det här huvudet refererar till innehållslängden för listan över block, inte själva blobben.
`Content-MD5`	Valfritt. En MD5-hash för begärandeinnehållet. Denna hash används för att verifiera integriteten för begärandeinnehållet under transporten. Om de två hashvärdena inte matchar misslyckas åtgärden med felkoden 400 (felaktig begäran). Det här huvudet är associerat med begärandeinnehållet och inte med själva blobens innehåll.
`x-ms-content-crc64`	Valfritt. En CRC64-hash för begärandeinnehållet. Denna hash används för att verifiera integriteten för begärandeinnehållet under transporten. Om de två hashvärdena inte matchar misslyckas åtgärden med felkoden 400 (felaktig begäran). Det här huvudet är associerat med begärandeinnehållet och inte med själva blobens innehåll. Om både Content-MD5- och x-ms-content-crc64-huvuden finns misslyckas begäran med 400 (felaktig begäran). Det här huvudet stöds i version 2019-02-02 och senare.
`x-ms-blob-cache-control`	Valfritt. Anger blobens cachekontroll. Om den här egenskapen anges lagras den med bloben och returneras med en läsbegäran. Om egenskapen inte har angetts med begäran rensas den för bloben om begäran lyckas.
`x-ms-blob-content-type`	Valfritt. Anger blobens innehållstyp. Om den anges lagras den här egenskapen med bloben och returneras med en läsbegäran. Om innehållstypen inte har angetts anges den till standardtypen, som är `application/octet-stream`.
`x-ms-blob-content-encoding`	Valfritt. Anger blobens innehållskodning. Om den anges lagras den här egenskapen med bloben och returneras med en läsbegäran. Om egenskapen inte har angetts med begäran rensas den för bloben om begäran lyckas.
`x-ms-blob-content-language`	Valfritt. Anger blobens innehållsspråk. Om den anges lagras den här egenskapen med bloben och returneras med en läsbegäran. Om egenskapen inte har angetts med begäran rensas den för bloben om begäran lyckas.
`x-ms-blob-content-md5`	Valfritt. En MD5-hash för blobinnehållet. Den här hashen verifieras inte eftersom hashvärdena för de enskilda blocken verifierades när var och en laddades upp. Åtgärden Hämta blob returnerar värdet för det här huvudet i content-MD5-svarshuvudet. Om den här egenskapen inte har angetts med begäran rensas den för bloben om begäran lyckas.
`x-ms-meta-name:value`	Valfritt. Användardefinierade namn/värde-par som är associerade med bloben. Från och med version 2009-09-19 måste metadatanamn följa namngivningsreglerna för C#-identifierare.
`x-ms-encryption-scope`	Valfritt. Anger krypteringsomfånget som ska användas för att kryptera bloben. Det här värdet måste matcha krypteringsomfånget som används för att kryptera alla block som checkas in. Det här huvudet stöds i version 2019-02-02 och senare.
`x-ms-encryption-context`	Valfritt. Standardvärdet är "Tom". Om värdet anges anges blobsystemmetadata. Max längd-1024. Gäller endast när hierarkiskt namnområde är aktiverat för kontot. Det här huvudet stöds i versionerna 2021-08-06 och senare.
`x-ms-tags`	Valfritt. Anger de angivna frågesträngskodade taggarna på bloben. Mer information finns i avsnittet Kommentarer . Stöds i version 2019-12-12 och senare.
`x-ms-lease-id:<ID>`	Krävs om bloben har ett aktivt lån. Om du vill utföra den här åtgärden på en blob med ett aktivt lån anger du det giltiga låne-ID:t för det här huvudet.
`x-ms-client-request-id`	Valfritt. Tillhandahåller ett klientgenererat, täckande värde med en teckengräns på 1 kibibyte (KiB) som registreras i analysloggarna när loggning av lagringsanalys konfigureras. Vi rekommenderar starkt att du använder det här huvudet för att korrelera aktiviteter på klientsidan med begäranden som servern tar emot.
`x-ms-blob-content-disposition`	Valfritt. Anger blobens `Content-Disposition` sidhuvud. Tillgänglig för version 2013-08-15 och senare. Rubrikfältet `Content-Disposition` förmedlar ytterligare information om hur du bearbetar svarsnyttolasten och kan användas för att bifoga ytterligare metadata. Om det till exempel är inställt på `attachment`anger det här huvudet att användaragenten inte ska visa svaret, utan i stället visa en Spara som-dialogruta. Svaret från åtgärderna Hämta blobb - och Hämta blobegenskaper innehåller innehållsborttagningshuvudet.
`x-ms-access-tier`	Valfritt. Version 2018-11-09 och senare. Anger vilken nivå som ska anges på en blob. För blockblobar stöds det här huvudet endast på bloblagringskonton eller v2-konton för generell användning med version 2018-11-09 och senare. Giltiga värden för blockblobnivåer är `Hot`, `Cool`, `Cold`och `Archive`. `Cold` Obs! Nivån stöds för version 2021-12-02 och senare. Detaljerad information om blockblobnivåer finns i Lagringsnivåer för frekvent, lågfrekvent lagring och arkivlagring.
`x-ms-immutability-policy-until-date`	Version 2020-06-12 och senare. Anger det kvarhållningsdatum som ska anges på bloben. Det här är det datum då bloben kan skyddas från att ändras eller tas bort. Följer RFC1123 format.
`x-ms-immutability-policy-mode`	Version 2020-06-12 och senare. Anger det oföränderlighetsprincipläge som ska anges på bloben. Giltiga värden är `unlocked` och `locked`. Värdet `unlocked` anger att användare kan ändra principen genom att öka eller minska kvarhållningsdatumet. Värdet `locked` anger att dessa åtgärder är förbjudna.
`x-ms-legal-hold`	Version 2020-06-12 och senare. Anger det juridiska undantag som ska anges för bloben. Giltiga värden är `true` och `false`.
`x-ms-expiry-option`	Valfritt. Version 2023-08-03 och senare. Anger alternativet för förfallodatum för begäran, se ExpiryOption. Det här huvudet är giltigt för konton med hierarkiskt namnområde aktiverat.
`x-ms-expiry-time`	Valfritt. Version 2023-08-03 och senare. Anger den tid då blobben är inställd på att upphöra att gälla. Formatet för förfallodatum varierar beroende på `x-ms-expiry-option`. Mer information finns i ExpiryOption. Det här huvudet är giltigt för konton med hierarkiskt namnområde aktiverat. Den `expiryTime` som redan finns på en blob rensas inte om begäran inte innehåller ett nytt värde på `expiryTime`

Den här åtgärden stöder också användning av villkorsstyrda rubriker för att endast checka in blocklistan om ett angivet villkor uppfylls. Mer information finns i Ange villkorsstyrda rubriker för Blob Storage-åtgärder.

Begärandehuvuden (krypteringsnycklar som tillhandahålls av kunden)

Från och med version 2019-02-02 kan du ange följande rubriker på begäran för att kryptera en blob med en nyckel som tillhandahålls av kunden. Kryptering med en nyckel som tillhandahålls av kunden (och motsvarande uppsättning rubriker) är valfri.

Begärandehuvud	Beskrivning
`x-ms-encryption-key`	Krävs. Den Base64-kodade AES-256-krypteringsnyckeln.
`x-ms-encryption-key-sha256`	Krävs. Den Base64-kodade SHA256-hashen för krypteringsnyckeln.
`x-ms-encryption-algorithm: AES256`	Krävs. Anger vilken algoritm som ska användas för kryptering. Värdet för det här huvudet måste vara `AES256`.

Begärandetext

I begärandetexten kan du ange blocklistan som Blob Storage ska söka efter det begärda blocket. På så sätt kan du uppdatera en befintlig blob genom att infoga, ersätta eller ta bort enskilda block i stället för att ladda om hela bloben. När du har laddat upp blocket eller blocken som har ändrats kan du checka in en ny version av bloben genom att checka in de nya blocken tillsammans med de befintliga block som du vill behålla.

Om du vill uppdatera en blob kan du ange att tjänsten ska leta efter ett block-ID i listan över bekräftade block, i listan över ej bekräftade block eller i listan över ej bekräftade block först och sedan i listan över bekräftade block. Ange vilken metod som ska användas genom att ange det block-ID som finns inom lämpligt XML-element i begärandetexten enligt följande:

Ange block-ID:t i -elementet Committed för att ange att Blob Storage endast ska söka i listan över bekräftade block för det namngivna blocket. Om blocket inte hittas i listan över bekräftade block skrivs det inte som en del av bloben, och Blob Storage returnerar statuskod 400 (felaktig begäran).
Ange block-ID:t i -elementet Uncommitted för att ange att Blob Storage endast ska söka i listan över oangivna block för det namngivna blocket. Om blocket inte hittas i listan över oangivna block skrivs det inte som en del av bloben och Blob Storage returnerar statuskod 400 (felaktig begäran).
Ange block-ID:t i -elementet Latest för att ange att Blob Storage först ska söka i listan över ej tillåtna block. Om blocket hittas i listan som inte har angetts är den versionen av blocket den senaste och bör skrivas till bloben. Om blocket inte hittas i den ogenomförda listan bör tjänsten söka i listan över bekräftade block efter det namngivna blocket och skriva det blocket till bloben om det hittas.

Begärandetexten för den här versionen av Put Block List använder följande XML-format:

<?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>

Exempelbegäran

Anta att du har laddat upp tre block som du nu vill checka in för att demonstrera Put Block List. I följande exempel checkas en ny blob in genom att den senaste versionen av varje block i listan ska användas. Det är inte nödvändigt att veta om dessa block redan har checkats in.

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>

Nu ska vi anta att du vill uppdatera bloben. Den nya bloben har följande ändringar:

Ett nytt block med ID ANAAAA==. Det här blocket måste först laddas upp med ett anrop till Put Block och det visas i listan över ej tillåtna block tills anropet till Put Block List.
En uppdaterad version av blocket med ID AZAAAA==. Det här blocket måste först laddas upp med ett anrop till Put Block och det visas i listan över ej tillåtna block tills anropet till Put Block List.
Borttagning av blocket med ID AAAAAA==:t . Eftersom det här blocket inte ingår i nästa anrop till Put Block Listtas blocket effektivt bort från bloben.

I följande exempel visas anropet till Put Block List som uppdaterar bloben:

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>

Svarsåtgärder

Svaret innehåller en HTTP-statuskod och en uppsättning svarshuvuden.

Statuskod

En lyckad åtgärd returnerar statuskoden 201 (skapad).

Mer information om statuskoder finns i Status och felkoder.

Svarshuvuden

Svaret för den här åtgärden innehåller följande rubriker. Svaret kan också innehålla ytterligare HTTP-standardhuvuden. Alla standardhuvuden överensstämmer med HTTP/1.1-protokollspecifikationen.

Svarsåtgärder	Beskrivningar
`ETag`	Entitetstaggen innehåller ett värde som klienten kan använda för att utföra villkorsstyrda `GET/PUT` åtgärder med hjälp av begärandehuvudet `If-Match` . Om begärandeversionen är 2011-08-18 eller senare omges ETag-värdet av citattecken.
`Last-Modified`	Datum/tid då bloben senast ändrades. Datumformatet följer RFC 1123. Mer information finns i Representera datum/tid-värden i rubriker. Alla åtgärder som ändrar bloben, inklusive en uppdatering av blobens metadata eller egenskaper, ändrar blobens senast ändrade tid.
`Content-MD5`	Returneras så att klienten kan söka efter meddelandeinnehållsintegritet. Det här huvudet refererar till innehållet i begäran (i det här fallet listan över block och inte innehållet i själva bloben). För version 2019-02-02 och senare returneras det här huvudet endast när begäran har det här huvudet.
`x-ms-content-crc64`	För version 2019-02-02 och senare returneras det här huvudet så att klienten kan söka efter meddelandets innehållsintegritet. Det här huvudet refererar till innehållet i begäran (i det här fallet listan över block och inte innehållet i själva bloben). Det här huvudet returneras när `Content-md5` rubriken inte finns i begäran.
`x-ms-request-id`	Identifierar begäran som gjordes unikt och du kan använda den för att felsöka begäran. Mer information finns i Felsöka API-åtgärder.
`x-ms-version`	Den version av Blob Storage som används för att köra begäran. Det här huvudet returneras för begäranden som görs mot version 2009-09-19 och senare.
`Date`	Ett DATUM-/tidsvärde för UTC som genereras av tjänsten, vilket anger när svaret initierades.
`x-ms-request-server-encrypted: true/false`	Version 2015-12-11 och senare. Värdet för det här huvudet anges till `true` om innehållet i begäran har krypterats med den angivna algoritmen. Annars är värdet inställt på `false`.
`x-ms-encryption-key-sha256`	Version 2019-02-02 och senare. Det här huvudet returneras om begäran använde en nyckel från kunden för kryptering, så att klienten kan se till att innehållet i begäran krypteras med hjälp av den angivna nyckeln.
`x-ms-encryption-scope`	Version 2019-02-02 och senare. Det här huvudet returneras om begäran använde ett krypteringsomfång, så att klienten kan se till att innehållet i begäran krypteras med hjälp av krypteringsomfånget.
`x-ms-version-id: <DateTime>`	Version 2019-12-12 och senare. Returnerar ett täckande `DateTime` värde som unikt identifierar bloben. Värdet för den här rubriken anger blobens version och kan användas i efterföljande begäranden för att få åtkomst till bloben.
`x-ms-client-request-id`	Kan användas för att felsöka begäranden och deras motsvarande svar. Värdet för det här huvudet är lika med värdet `x-ms-client-request-id` för rubriken om det finns i begäran och värdet inte innehåller fler än 1 024 synliga ASCII-tecken. Om rubriken `x-ms-client-request-id` inte finns i begäran finns den inte i svaret.

Exempelsvar

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>

Auktorisering

Auktorisering krävs när du anropar en dataåtkomståtgärd i Azure Storage. Du kan auktorisera åtgärden enligt beskrivningen Put Block List nedan.

Om en begäran anger taggar med x-ms-tags begärandehuvudet måste anroparen uppfylla auktoriseringskraven för åtgärden Ange blobtaggar .

Viktigt

Microsoft rekommenderar att du använder Microsoft Entra ID med hanterade identiteter för att auktorisera begäranden till Azure Storage. Microsoft Entra ID ger överlägsen säkerhet och användarvänlighet jämfört med auktorisering med delad nyckel.

Azure Storage stöder användning av Microsoft Entra ID för att auktorisera begäranden till blobdata. Med Microsoft Entra ID kan du använda rollbaserad åtkomstkontroll i Azure (Azure RBAC) för att bevilja behörigheter till ett säkerhetsobjekt. Säkerhetsobjektet kan vara en användare, grupp, programtjänstens huvudnamn eller en hanterad Azure-identitet. Säkerhetsobjektet autentiseras av Microsoft Entra ID för att returnera en OAuth 2.0-token. Token kan sedan användas för att auktorisera en begäran mot Blob-tjänsten.

Mer information om auktorisering med Microsoft Entra ID finns i Auktorisera åtkomst till blobar med hjälp av Microsoft Entra ID.

Behörigheter

Nedan visas den RBAC-åtgärd som krävs för att en Microsoft Entra användare, grupp, hanterad identitet eller tjänstens huvudnamn ska anropa Put Block List åtgärden och den minst privilegierade inbyggda Azure RBAC-rollen som innehåller den här åtgärden:

Azure RBAC-åtgärd:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Minsta privilegierade inbyggda roll:Storage Blob Data-deltagare

Mer information om hur du tilldelar roller med hjälp av Azure RBAC finns i Tilldela en Azure-roll för åtkomst till blobdata.

En signatur för delad åtkomst (SAS) ger säker delegerad åtkomst till resurser i ett lagringskonto. Med en SAS har du detaljerad kontroll över hur en klient kan komma åt data. Du kan ange vilken resurs klienten får åtkomst till, vilka behörigheter de har till dessa resurser och hur länge SAS är giltig.

Åtgärden Put Block List stöder tre typer av signaturer för delad åtkomst: SAS för användardelegering, tjänst-SAS och konto-SAS.

Vi rekommenderar att du använder Microsoft Entra autentiseringsuppgifter i stället för lagringskontonyckeln, vilket är enklare att kompromettera. Om din programdesign kräver signaturer för delad åtkomst använder du Microsoft Entra autentiseringsuppgifter för att skapa en SAS för användardelegering när det är möjligt.

När åtkomst med delad nyckel inte tillåts för lagringskontot tillåts inte en SAS-token för tjänsten eller en SAS-token för kontot på en begäran till Blob Storage. Mer information finns i Förstå hur nekande av delad nyckel påverkar SAS-token.

SAS för användardelegering

En SAS för användardelegering skyddas med Microsoft Entra autentiseringsuppgifter och även av de behörigheter som anges för SAS.

Put Block List Att anropa åtgärden med hjälp av en SAS-token som delegerats till en container eller blobresurs kräver behörigheten Skriv (w) som en del av SAS-token för användardelegering.

Mer information om SAS för användardelegering finns i Skapa en SAS för användardelegering.

Tjänst-SAS

En tjänst-SAS skyddas med lagringskontonyckeln. En tjänst-SAS delegerar åtkomst till en resurs i en enda Azure Storage-tjänst, till exempel bloblagring.

Put Block List Att anropa åtgärden med en SAS-token som delegerats till en container eller blobresurs kräver skrivbehörigheten (w) som en del av tjänstens SAS-token.

Mer information om tjänstens SAS finns i Skapa en tjänst-SAS.

Konto-SAS

Ett konto-SAS skyddas med lagringskontonyckeln. En konto-SAS delegerar åtkomst till resurser i en eller flera av lagringstjänsterna. Alla åtgärder som är tillgängliga via en sas för tjänst- eller användardelegering är också tillgängliga via ett konto-SAS.

Följande tabell anger den signerade resurstypen och de signerade behörigheter som ska anges när åtkomst delegeras:

Åtgärd	Signerad tjänst	Signerad resurstyp	Signerad behörighet
Put Block List	Blob (b)	Objekt (o)	Skriva (w)

Mer information om kontots SAS finns i Skapa ett konto-SAS.

Kommentarer

Åtgärden Put Block List tillämpar den ordning i vilken block ska kombineras för att skapa en blob.

Samma block-ID kan anges mer än en gång i listan över block. Om ett block-ID anges mer än en gång representerar det byteintervallet på var och en av dessa platser i blockeringslistan för den slutliga bekräftade bloben. Om ett block-ID visas mer än en gång i listan måste båda instanserna av block-ID anges i samma blocklista. Med andra ord måste båda instanserna anges i -elementet Committed , -elementet Uncommitted eller -elementet Latest .

Med Put Block Listkan du ändra en befintlig blob genom att infoga, uppdatera eller ta bort enskilda block utan att behöva ladda upp hela bloben igen. Du kan ange block-ID:n från både den aktuella bekräftade blockeringslistan och den ogenomförda blocklistan för att skapa en ny blob eller uppdatera innehållet i en befintlig blob. På så sätt kan du uppdatera en blob genom att ange några nya block från listan över ej bekräftade block och resten från listan över bekräftade block, som redan är en del av den befintliga bloben.

Om ett block-ID anges i -elementet Latest och samma block-ID finns i både de allokerade och ogenomförda blockeringslistorna, Put Block List checkar blocket in från listan över ej bekräftade block. Om block-ID:t finns i listan över bekräftade block, men inte i listan över ej bekräftade blockeringar, Put Block List checkar blocket in från listan över bekräftade block.

Varje block i en blockblob kan ha olika storlek. En blockblob kan innehålla högst 50 000 bekräftade block. Det maximala antalet obekräftade block som kan associeras med en blob är 100 000.

I följande tabell beskrivs de högsta tillåtna block- och blobstorlekarna efter tjänstversion:

Tjänstversion	Maximal blockstorlek (via `Put Block`)	Maximal blobstorlek (via `Put Block List`)	Maximal blobstorlek via en enda skrivåtgärd (via `Put Blob`)
Version 2019-12-12 och senare	4 000 mebibyte (MiB)	Cirka 190,7 tebibyte (TiB) (4 000 MiB × 50 000 block)	5 000 MiB
Versioner 2016-05-31 till och med 2019-07-07	100 MiB	Cirka 4,75 TiB (100 MiB × 50 000 block)	256 MiB
Tidigare versioner än 2016-05-31	4 MiB	Cirka 195 GiB (4 MiB × 50 000 block)	64 MiB

När du anropar Put Block List för att uppdatera en befintlig blob skrivs blobens befintliga egenskaper och metadata över. Alla befintliga ögonblicksbilder behålls dock med bloben. Du kan bara använda huvudena för villkorlig begäran för att utföra åtgärden om ett angivet villkor uppfylls.

Om åtgärden Put Block List misslyckas på grund av ett block som saknas måste du ladda upp det saknade blocket.

Alla icke-utelämnade block samlas in om det inte finns några lyckade anrop till Put Block eller Put Block List på bloben inom en vecka efter den senaste lyckade Put Block åtgärden. Om Put Blob anropas på bloben samlas alla obekräftade block in.

Om taggar anges i x-ms-tags huvudet måste de vara frågesträngskodade. Taggnycklar och värden måste överensstämma med kraven för namngivning och längd, enligt vad som anges i Set Blob Tags. x-ms-tags Dessutom kan rubriken innehålla taggar på upp till 2 KiB i storlek. Om fler taggar krävs använder du åtgärden Ange blobtaggar .

Om bloben har ett aktivt lån måste klienten ange ett giltigt låne-ID för begäran om att checka in blockeringslistan. Om klienten antingen inte anger något låne-ID eller anger ett ogiltigt låne-ID returnerar Blob Storage statuskoden 412 (villkoret misslyckades). Om klienten anger ett låne-ID men bloben inte har något aktivt lån returnerar Blob Storage även statuskoden 412 (villkoret misslyckades). Om klienten anger ett låne-ID på en blob som ännu inte finns returnerar Blob Storage statuskod 412 (villkorsfel) för begäranden som görs mot version 2013-08-15 eller senare. För tidigare versioner returnerar Blob Storage statuskoden 201 (skapad).

Om bloben har ett aktivt lån och du anropar Put Block List för att uppdatera bloben underhålls lånet på den uppdaterade bloben.

Put Block List gäller endast för blockblobar. Anrop Put Block List på en sidblob resulterar i statuskod 400 (felaktig begäran).

Det går inte att skriva över en arkiverad blob och om du skriver över en hot eller cool en blob ärver du nivån från den gamla bloben om huvudet på x-ms-access-tier inte tillhandahålls.

Fakturering

Prisbegäranden kan komma från klienter som använder Blob Storage-API:er, antingen direkt via REST-API:et för Blob Storage eller från ett Azure Storage-klientbibliotek. Dessa begäranden ackumulerar avgifter per transaktion. Typen av transaktion påverkar hur kontot debiteras. Lästransaktioner till exempel tillfaller en annan faktureringskategori än skrivtransaktioner. I följande tabell visas faktureringskategorin för Put Block List begäranden baserat på lagringskontotypen:

Åtgärd	Typ av lagringskonto	Faktureringskategori
Put Block List	Premium-blockblob Standard generell användning v2 Standard generell användning v1	Skrivåtgärder

Mer information om priser för den angivna faktureringskategorin finns i Azure Blob Storage Prissättning.

Se även

Förstå blockblobar, tilläggsblobar och sidblobar
Auktorisera begäranden till Azure Storage
Status- och felkoder
Felkoder för blobtjänsten
Ange tidsgränser för blobtjänståtgärder

Dela via