Partilhar via


Colocar Bloco

A Put Block operação cria um novo bloco a ser consolidado como parte de um blob.

Pedir

Pode construir o pedido da Put Block seguinte forma. Recomendamos que utilize HTTPS. Substitua myaccount pelo nome da sua conta de armazenamento:

URI do pedido do método PUT Versão HTTP
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=id HTTP/1.1

Pedido de serviço de armazenamento emulado

Quando estiver a fazer um pedido relativamente ao serviço de armazenamento emulado, especifique o nome do anfitrião do emulador e a porta do serviço Blob como 127.0.0.1:10000, seguido do nome da conta de armazenamento emulada:

URI do pedido do método PUT Versão HTTP
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=block&blockid=id HTTP/1.1

Para obter mais informações, veja Utilizar o emulador do Azurite para o desenvolvimento local do Armazenamento do Azure.

Parâmetros do URI

Parâmetro Description
blockid Obrigatório. Um valor de cadeia Base64 válido que identifica o bloco. Antes de ser codificada, a cadeia tem de ter um tamanho inferior ou igual a 64 bytes.

Para um blob especificado, o comprimento do valor para o blockid parâmetro tem de ter o mesmo tamanho para cada bloco.

Nota: a cadeia Base64 tem de ter codificação de URL.
timeout Opcional. O timeout parâmetro é expresso em segundos. Para obter mais informações, veja Set time-outs for Blob service operations (Definir tempos limite para operações do serviço Blob).

Cabeçalhos do pedido

Os cabeçalhos de pedido obrigatórios e opcionais estão descritos na tabela seguinte:

Cabeçalho do pedido Description
Authorization Obrigatório. Especifica o esquema de autorização, o nome da conta e a assinatura. Veja Autorizar pedidos para o Armazenamento do Azure para obter mais informações.
Date ou x-ms-date Obrigatório. Especifica a Hora Universal Coordenada (UTC) do pedido. Para obter mais informações, veja Autorizar pedidos para o Armazenamento do Azure.
x-ms-version Necessário para todos os pedidos autorizados. Especifica a versão da operação a utilizar para este pedido. Para obter mais informações, veja Controlo de versões dos Serviços de Armazenamento do Azure.
Content-Length Obrigatório. O comprimento do conteúdo do bloco em bytes. O bloco tem de ter um tamanho inferior ou igual a 4000 mebibytes (MiB) para a versão 2019-12-12 e posterior. Consulte a secção Observações para obter limites em versões mais antigas.

Quando o comprimento não é fornecido, a operação falha com o código de estado 411 (Comprimento Necessário).
Content-MD5 Opcional. Um Hash MD5 do conteúdo do bloco. Este Hash é utilizado para verificar a integridade do bloco durante o transporte. Quando este cabeçalho é especificado, o serviço de armazenamento compara o hash do conteúdo que chegou com este valor do cabeçalho.

Nota: este hash MD5 não está armazenado com o blob.

Se os dois hashes não corresponderem, a operação falha com o código de erro 400 (Pedido Incorreto).
x-ms-content-crc64 Opcional. Um Hash CRC64 do conteúdo do bloco. Este Hash é utilizado para verificar a integridade do bloco durante o transporte. Quando este cabeçalho é especificado, o serviço de armazenamento compara o hash do conteúdo que chegou com este valor do cabeçalho.

Nota: este hash CRC64 não está armazenado com o blob.

Se os dois hashes não corresponderem, a operação falha com o código de erro 400 (Pedido Incorreto).

Se os cabeçalhos Content-MD5 e x-ms-content-crc64 estiverem presentes, o pedido falha com um 400 (Pedido Incorreto).

Este cabeçalho é suportado nas versões 2019-02-02 e posteriores.
x-ms-encryption-scope Opcional. Indica o âmbito de encriptação a utilizar para encriptar o conteúdo do pedido. Este cabeçalho é suportado nas versões 2019-02-02 e posteriores.
x-ms-lease-id:<ID> Necessário se o blob tiver uma concessão ativa. Para executar esta operação num blob com uma concessão ativa, especifique o ID de concessão válido para este cabeçalho.
x-ms-client-request-id Opcional. Fornece um valor opaco gerado pelo cliente com um limite de carateres de 1 kibibyte (KiB) que é registado nos registos quando o registo é configurado. Recomendamos vivamente que utilize este cabeçalho para correlacionar as atividades do lado do cliente com os pedidos que o servidor recebe. Para obter mais informações, veja Monitorizar o Armazenamento de Blobs do Azure.

Cabeçalhos de pedido (chaves de encriptação fornecidas pelo cliente)

A partir da versão 2019-02-02, podem ser especificados os seguintes cabeçalhos no pedido para encriptar um blob com uma chave fornecida pelo cliente. A encriptação com uma chave fornecida pelo cliente (e o conjunto de cabeçalhos correspondente) é opcional.

Cabeçalho do pedido Description
x-ms-encryption-key Obrigatório. A chave de encriptação AES-256 codificada com Base64.
x-ms-encryption-key-sha256 Obrigatório. O hash SHA256 codificado com Base64 da chave de encriptação.
x-ms-encryption-algorithm: AES256 Obrigatório. Especifica o algoritmo a utilizar para encriptação. O valor deste cabeçalho tem de ser AES256.

Corpo do pedido

O corpo do pedido contém o conteúdo do bloco.

Pedido de exemplo

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=AAAAAA%3D%3D HTTP/1.1  
  
Request Headers:  
x-ms-version: 2011-08-18  
x-ms-date: Sun, 25 Sep 2011 14:37:35 GMT  
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 1048576  

Resposta

A resposta inclui um código de estado HTTP e um conjunto de cabeçalhos de resposta.

Código de estado

Uma operação bem-sucedida devolve o código de estado 201 (Criado).

Para obter informações sobre códigos de estado, veja Códigos de Estado e erro.

Cabeçalhos de resposta

A resposta para esta operação inclui os seguintes cabeçalhos. A resposta também pode incluir cabeçalhos HTTP padrão adicionais. Todos os cabeçalhos padrão estão em conformidade com a especificação do protocolo HTTP/1.1.

Cabeçalho de resposta Descrição
Content-MD5 Devolvido para que o cliente possa verificar a integridade do conteúdo da mensagem. O valor deste cabeçalho é calculado pelo Armazenamento de Blobs e não é necessariamente o mesmo valor especificado nos cabeçalhos do pedido. Para as versões 2019-02-02 e posterior, este cabeçalho só é devolvido quando o pedido tem este cabeçalho.
x-ms-content-crc64 Para as versões 2019-02-02 e posterior, este cabeçalho é devolvido para que o cliente possa verificar a integridade do conteúdo da mensagem. O valor deste cabeçalho é calculado pelo Armazenamento de Blobs e não é necessariamente o mesmo valor especificado nos cabeçalhos do pedido.

Este cabeçalho é devolvido quando Content-md5 o cabeçalho não está presente no pedido.
x-ms-request-id Identifica exclusivamente o pedido que foi feito e pode utilizá-lo para resolver o pedido. Para obter mais informações, veja Resolver problemas de operações da API.
x-ms-version Indica a versão do Armazenamento de Blobs que foi utilizada para executar o pedido. Este cabeçalho é devolvido para pedidos efetuados na versão 2009-09-19 ou posterior.
Date Um valor de data/hora UTC gerado pelo serviço, que indica quando a resposta foi iniciada.
x-ms-request-server-encrypted: true/false Versão 2015-12-11 e posterior. O valor deste cabeçalho está definido como true se os conteúdos do pedido forem encriptados com êxito com o algoritmo especificado. Caso contrário, o valor está definido como false.
x-ms-encryption-key-sha256 Versão 2019-02-02 e posterior. Este cabeçalho é devolvido se o pedido tiver utilizado uma chave fornecida pelo cliente para encriptação, para que o cliente possa garantir que os conteúdos do pedido são encriptados com êxito através da chave fornecida.
x-ms-encryption-scope Versão 2019-02-02 e posterior. Este cabeçalho é devolvido se o pedido tiver utilizado um âmbito de encriptação, para que o cliente possa garantir que os conteúdos do pedido são encriptados com êxito através do âmbito de encriptação.
x-ms-client-request-id Pode ser utilizado para resolver problemas de pedidos e respostas correspondentes. O valor deste cabeçalho é igual ao valor do x-ms-client-request-id cabeçalho se estiver presente no pedido e o valor não contiver mais de 1024 carateres ASCII visíveis. Se o x-ms-client-request-id cabeçalho não estiver presente no pedido, não está presente na resposta.

Resposta de amostra

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sun, 25 Sep 2011 23:47:09 GMT  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  

Autorização

A autorização é necessária ao chamar qualquer operação de acesso a dados no Armazenamento do Azure. Pode autorizar a Put Block operação conforme descrito abaixo.

Importante

A Microsoft recomenda a utilização do ID do Microsoft Entra com identidades geridas para autorizar pedidos para o Armazenamento do Azure. O ID do Microsoft Entra fornece segurança e facilidade de utilização superiores em comparação com a autorização de Chave Partilhada.

O Armazenamento do Azure suporta a utilização do Microsoft Entra ID para autorizar pedidos para dados de blobs. Com o Microsoft Entra ID, pode utilizar o controlo de acesso baseado em funções do Azure (RBAC do Azure) para conceder permissões a um principal de segurança. O principal de segurança pode ser um utilizador, grupo, principal de serviço de aplicação ou identidade gerida do Azure. O principal de segurança é autenticado pelo Microsoft Entra ID para devolver um token OAuth 2.0. Em seguida, o token pode ser utilizado para autorizar um pedido contra o serviço Blob.

Para saber mais sobre a autorização com o Microsoft Entra ID, veja Autorizar o acesso a blobs com o Microsoft Entra ID.

Permissões

Abaixo estão listadas as ações RBAC necessárias para que um utilizador, grupo, identidade gerida ou principal de serviço da Microsoft Entra chame a Put Block operação e a função RBAC do Azure com menos privilégios que inclua esta ação:

Para saber mais sobre como atribuir funções com o RBAC do Azure, veja Atribuir uma função do Azure para acesso a dados de blobs.

Observações

Put Block carrega um bloco para inclusão futura num blob de blocos. Cada bloco num blob de blocos pode ter um tamanho diferente. Um blob de blocos pode incluir um máximo de 50 000 blocos consolidados.

A tabela seguinte descreve os tamanhos máximos permitidos de blocos e blobs, por versão de serviço:

Versão do serviço Tamanho máximo do bloco (via Put Block) Tamanho máximo do blob (via Put Block List) Tamanho máximo do blob através de uma operação de escrita única (via Put Blob)
Versão 2019-12-12 e posterior 4000 MiB Aproximadamente 190,7 tebibytes (TiB) (4000 MiB × 50.000 blocos) 5000 MiB
Versões 2016-05-31 até 2019-07-07 100 MiB Aproximadamente 4,75 TiB (100 MiB × 50.000 blocos) 256 MiB
Versões anteriores a 2016-05-31 4 MiB Aproximadamente 195 gibibytes (GiB) (4 MiB × 50.000 blocos) 64 MiB

O número máximo de blocos não comprometidos que podem estar associados a um blob é 100 000. Se este número for excedido, o serviço devolve o código de estado 409 (RequestEntityTooLargeBlockCountExceedsLimit).

Depois de carregar um conjunto de blocos, pode criar ou atualizar o blob no servidor a partir deste conjunto ao chamar a operação Colocar Lista de Blocos . Cada bloco no conjunto é identificado por um ID de bloco exclusivo nesse blob. Os IDs de bloco estão no âmbito de um blob específico, pelo que os blobs diferentes podem ter blocos com os mesmos IDs.

Se chamar Put Block um blob que ainda não existe, é criado um novo blob de blocos com um comprimento de conteúdo de 0. Este blob é enumerado pela List Blobs operação se a opção include=uncommittedblobs for especificada. O bloco ou blocos que carrega não são consolidados até chamar Put Block List o novo blob. Um blob criado desta forma é mantido no servidor durante uma semana. Se não tiver adicionado mais blocos ou blocos consolidados ao blob nesse período de tempo, o blob é lixo recolhido.

Um bloco que tenha sido carregado com êxito com a Put Block operação não faz parte de um blob até ser consolidado com Put Block List. Antes Put Block List de ser chamado para consolidar o blob novo ou atualizado, quaisquer chamadas para Obter Blob devolvem os conteúdos do blob sem a inclusão do bloco não comprometido.

Se carregar um bloco com o mesmo ID de bloco que outro bloco que ainda não foi consolidado, o último bloco carregado com esse ID será consolidado na próxima operação bem-sucedida Put Block List .

Depois de Put Block List ser chamado, todos os blocos não comprometidos especificados na lista de blocos são consolidados como parte do novo blob. Todos os blocos não comprometidos que não foram especificados na lista de blocos do blob são recolhidos e removidos do Armazenamento de Blobs. Todos os blocos não comprometidos também são recolhidos se não houver chamadas bem-sucedidas para Put Block ou Put Block List para o mesmo blob no prazo de uma semana após a última operação bem-sucedida Put Block . Se Colocar Blob for chamado no blob, todos os blocos não comprometidos são recolhidos.

Se o blob tiver uma concessão ativa, o cliente tem de especificar um ID de concessão válido no pedido para escrever um bloco no blob. Se o cliente não especificar um ID de concessão ou especificar um ID de concessão inválido, o Armazenamento de Blobs devolve o código de estado 412 (Falha na Pré-condição). Se o cliente especificar um ID de concessão, mas o blob não tiver uma concessão ativa, o Armazenamento de Blobs também devolve o código de estado 412 (Falha na Pré-condição).

Para um blob especificado, todos os IDs de bloco têm de ter o mesmo comprimento. Se um bloco for carregado com um ID de bloco com um comprimento diferente dos IDs de bloco para quaisquer blocos não comprometidos existentes, o serviço devolve o código de resposta de erro 400 (Pedido Incorreto).

Se tentar carregar um bloco com mais de 4000 MiB para a versão 2019-12-12 ou posterior, superior a 100 MiB para a versão 2016-05-31 ou posterior, ou superior a 4 MiB para versões mais antigas, o serviço devolve o código de estado 413 (Entidade de Pedido Demasiado Grande). O serviço também devolve informações adicionais sobre o erro na resposta, incluindo o tamanho máximo de bloco permitido, em bytes.

As chamadas Put Block não atualizam a última hora modificada de um blob existente.

Chamar Put Block num blob de página devolve um erro.

Chamar Put Block um blob arquivado devolve um erro e chamá-lo num hot blob ou cool não altera a camada de blobs.

Faturação

Os pedidos de preços podem ter origem em clientes que utilizam APIs de Armazenamento de Blobs, diretamente através da API REST do Armazenamento de Blobs ou a partir de uma biblioteca de cliente do Armazenamento do Azure. Estes pedidos acumulam custos por transação. O tipo de transação afeta a forma como a conta é cobrada. Por exemplo, as transações de leitura acumulam-se numa categoria de faturação diferente das transações de escrita. A tabela seguinte mostra a categoria de faturação dos Put Block pedidos com base no tipo de conta de armazenamento:

Operação Tipo de conta de armazenamento Categoria de faturação
Colocar Bloco Blob de bloco premium
Standard para fins gerais v2
Standard para fins gerais v1
Operações deescrita 1

1Put Block operações escrevem blocos no armazenamento temporário com a camada de acesso predefinida da conta de armazenamento. Por exemplo, se estiver a carregar um blob para a camada de arquivo, todas Put Block as operações que fazem parte do carregamento são cobradas como operações de escrita com base na camada de acesso predefinida da conta de armazenamento e não na camada de destino. Put Block List no entanto Put Blob , as operações são cobradas como operações de escrita com base no escalão de destino do blob.

Para saber mais sobre os preços da categoria de faturação especificada, veja Preços do Armazenamento de Blobs do Azure.

Ver também

Autorizar pedidos para o Armazenamento do Azure
Códigos de estado e de erro
Códigos de erro do serviço blob
Definir tempos limite para operações do serviço Blob