Metadados do objeto

Faça a gestão

Esta página aborda os campos de metadados usados frequentemente que são armazenados juntamente com os objetos no Cloud Storage.

Introdução

Os objetos armazenados no Cloud Storage têm metadados associados. Os metadados identificam as propriedades do objeto, bem como especificam como o objeto deve ser processado quando lhe é acedido. Os metadados existem como pares chave:valor. Por exemplo, a classe de armazenamento de um objeto é representada pela entrada de metadados storageClass:STANDARD. storageClass é a chave dos metadados, e todos os objetos têm uma chave associada. STANDARD especifica o valor que este objeto específico tem e o valor varia de objeto para objeto.

A capacidade de alteração dos metadados varia: pode editar alguns metadados em qualquer altura, só pode definir alguns metadados no momento em que o objeto é criado e só pode ver alguns metadados. Por exemplo, pode editar o valor dos metadados Cache-Control em qualquer altura, mas só pode atribuir os metadados storageClass quando o objeto é criado ou reescrito, e não pode editar diretamente o valor dos metadados generation, embora o valor generation mude quando o objeto é substituído.

Metadados editáveis

Existem duas categorias de metadados que os utilizadores podem alterar para objetos:

  • Metadados de chave fixa: metadados cujas chaves estão definidas, mas para os quais pode especificar um valor.

  • Metadados personalizados: metadados que adiciona especificando uma chave e um valor associado à chave.

Ao editar metadados, deve geralmente evitar carateres não ASCII, porque não são permitidos em cabeçalhos HTTP, que a API XML usa.

Metadados de chave fixa

Pode editar os seguintes metadados de objetos, mas tem de ter autorização suficiente para o fazer:

Metadados de controlo de acesso

O Cloud Storage usa a gestão de identidade e de acesso (IAM) e as listas de controlo de acesso (ACLs) para controlar o acesso a objetos. Use estes links para saber mais sobre estes métodos de controlo de acesso e os metadados associados.

Cache-Control

Os metadados Cache-Control podem especificar dois aspetos diferentes de como os dados são publicados a partir do Cloud Storage: se os dados podem ser colocados em cache e se podem ser transformados.

Colocar dados em cache

Os metadados Cache-Control permitem-lhe controlar se e durante quanto tempo as caches podem armazenar em cache os seus objetos, que podem ser usados para satisfazer pedidos futuros. As caches podem incluir caches do navegador e da Internet, bem como a armazenagem em cache integrada do Cloud Storage.

Se um objeto aplicável não tiver uma entrada de metadados Cache-Control, o Cloud Storage usa o valor predefinido de:

Se permitir o armazenamento em cache, as transferências podem continuar a receber versões anteriores de um objeto, mesmo depois de carregar uma versão mais recente. Isto deve-se ao facto de essas versões anteriores permanecerem "atualizadas" nas caches durante um período determinado pela max-age. Além disso, uma vez que os objetos podem ser colocados em cache em vários locais na Internet, não existe forma de forçar a expiração global de um objeto em cache. Isto significa que, se revogar o acesso público a um objeto, o objeto continua a poder ser servido a partir de uma cache, consoante a data do último acesso e a respetiva definição Cache-Control. Por exemplo, se o seu objeto tiver sido publicado com um Cache-Control de public, max-age=3600, pode persistir numa cache durante uma hora. Se quiser impedir a publicação de versões em cache de objetos legíveis publicamente, defina Cache-Control: no-store no objeto.

Se precisar de um maior controlo sobre o comportamento da cache, pode configurar o Cloud CDN à frente do seu contentor.

Transformar dados

Os metadados Cache-Control também permitem publicar objetos tal como estão armazenados, sem aplicar transformações aos dados, como remover a codificação de conteúdo gzip para clientes incompatíveis. Para publicar um objeto tal como está, defina Cache-Control:no-transform.

Content-Disposition

Os metadados Content-Disposition especificam informações de apresentação sobre os dados que estão a ser transmitidos. A definição de Content-Disposition permite-lhe controlar o estilo de apresentação do conteúdo, por exemplo, determinar se um anexo deve ser apresentado automaticamente ou se é necessária alguma forma de ação por parte do utilizador para o abrir. Consulte https://datatracker.ietf.org/doc/html/rfc6266 para ver a especificação Content-Disposition.

Content-Encoding

Os metadados Content-Encoding podem ser usados para indicar que um objeto está comprimido, mantendo o Content-Type subjacente do objeto. Por exemplo, um ficheiro de texto comprimido com gzip pode ter o facto de ser um ficheiro de texto indicado em Content-Type e o facto de estar comprimido com gzip indicado em Content-Encoding. Deve garantir que os ficheiros são, de facto, comprimidos com o formato especificado Content-Encoding antes de os carregar. Caso contrário, pode ocorrer um comportamento inesperado ao tentar transferir os objetos. Para mais informações, consulte a página Transcodificação.

Para conteúdo comprimível, como texto, a utilização de Content-Encoding: gzip poupa custos de rede e armazenamento, e melhora o desempenho do fornecimento de conteúdo. No entanto, para conteúdo que já está inerentemente comprimido, como arquivos e muitos formatos de multimédia, aplicar outro nível de compressão e marcá-lo nos metadados Content-Encoding é normalmente prejudicial para o tamanho do objeto e o desempenho, e deve ser evitado.

Content-Language

Os metadados Content-Language indicam os idiomas a que o objeto se destina. Consulte os códigos de idioma ISO 639-1 para ver os valores típicos destes metadados.

O Cloud Storage suporta valores Content-Language com um comprimento máximo de 100 carateres.

Tipo de conteúdo

Os metadados definidos mais frequentemente são Content-Type (também conhecido como tipo de suporte), que permite aos navegadores renderizar o objeto corretamente. Todos os objetos têm um valor especificado nos respetivos metadados Content-Type, mas este valor não tem de corresponder ao tipo subjacente do objeto. Por exemplo, se o Content-Type não for especificado pelo remetente e não puder ser determinado, é definido como application/octet-stream ou application/x-www-form-urlencoded, consoante a forma como carregou o objeto. Para ver uma lista de tipos de conteúdo válidos, consulte a página Tipos de suportes da IANA.

Custom-Time

Os metadados Custom-Time são uma data e uma hora especificadas pelo utilizador representadas no formato RFC 3339 YYYY-MM-DD'T'HH:MM:SS.SS'Z' ou YYYY-MM-DD'T'HH:MM:SS'Z' quando os milissegundos são zero. Normalmente, estes metadados são definidos para usar a condição DaysSinceCustomTime na gestão do ciclo de vida de objetos.

Não pode remover o atributo Custom-Time depois de o definir num objeto. Além disso, o valor de Custom-Time não pode diminuir. Ou seja, não pode definir Custom-Time para uma data/hora anterior à Custom-Time existente. No entanto, pode remover ou repor eficazmente o Custom-Time reescrevendo o objeto.

Retenções de objetos

Use flags de metadados para aplicar retenções de objetos, que impedem que os objetos sejam eliminados ou substituídos. Para mais informações, consulte a página de retenções de objetos.

Configuração da retenção

Quando presente, a configuração de retenção de um objeto define uma data e uma hora anteriores às quais o objeto não pode ser eliminado nem substituído. Para mais informações, consulte o artigo Bloqueio de retenção de objetos.

Metadados personalizados

Os metadados personalizados são metadados para os quais define a chave e o valor. Para criar metadados personalizados, especifica uma chave e um valor. Depois de criar um par de metadados personalizados key:value, pode eliminar a chave ou alterar o valor.

Os metadados personalizados estão sujeitos a um limite de tamanho e incorrem em custos de armazenamento.

A página Ver e editar metadados inclui informações sobre a definição de metadados personalizados.

O prefixo x-goog-meta-

A API XML define e obtém metadados de objetos através de cabeçalhos de pedidos, e a API JSON permite definir metadados personalizados no pedido final de um carregamento retomável através de cabeçalhos de pedidos. Para distinguir claramente os cabeçalhos de metadados personalizados dos cabeçalhos de pedidos padrão, ambas as APIs prefixam esses cabeçalhos de metadados personalizados com x-goog-meta-.

Metadados não editáveis

Não é possível editar diretamente alguns metadados. Estes metadados são definidos no momento da criação ou reescrita do objeto. Como parte da criação ou reescrita de objetos, pode definir alguns metadados, como a classe de armazenamento do objeto ou as chaves de encriptação geridas pelo cliente. Outros metadados são adicionados automaticamente e só podem ser vistos, como o número de geração do objeto ou a hora de criação.

Números de geração e metageração

Como parte dos respetivos metadados, cada objeto do Cloud Storage tem uma propriedade numérica generation e uma propriedade numérica metageneration que identifica o objeto de forma exclusiva:

Propriedade Descrição
generation Identifica a versão de um objeto e existe para todos os objetos, independentemente de um contentor usar a versão de objetos.
  • O valor generation de uma versão do objeto nunca é alterado. Um novo objeto com o mesmo nome pode substituir um objeto existente, mas o novo objeto tem sempre um generation diferente atribuído.
  • Não existe garantia de que os números de geração aumentem para versões sucessivas, apenas que cada nova versão tem um número de geração único.
  • Não existe relação entre os números de geração de objetos não relacionados, mesmo que os objetos estejam no mesmo contentor.
metageneration Identifica a versão dos metadados e aumenta sempre que os metadados de um determinado generation são atualizados.
  • O metageneration começa em 1 para cada novo generation de um objeto.
  • A propriedade metageneration não tem significado sem a propriedade generation e deve ser usada apenas em conjunto com esta; não faz sentido comparar gerações de metadados de duas versões de objetos.

As propriedades generation e metageneration são usadas nas seguintes circunstâncias:

Somas de verificação

As checksums são metadados calculados a partir dos dados do objeto associado. As somas de verificação são usadas para validar se os dados dos objetos não estão danificados. Os objetos do Cloud Storage têm vários campos de metadados de soma de verificação.

CRC32C

Todos os objetos do Cloud Storage têm um hash CRC32C. As bibliotecas para calcular o CRC32C incluem:

O CRC32C codificado em Base64 está na ordem de bytes big-endian.

MD5

Os objetos do Cloud Storage têm um hash MD5 se cumprirem os seguintes critérios:

Este hash só se aplica a um objeto completo, pelo que não pode ser usado para verificar a integridade de transferências parciais causadas pela execução de um GET de intervalo.

ETags

Todos os objetos do Cloud Storage têm uma ETag. No entanto, o mesmo objeto pode ter um valor ETag diferente quando é pedido à API XML em comparação com a API JSON. Na maioria dos casos, os utilizadores não devem fazer suposições sobre o valor usado numa ETag, exceto que este muda sempre que os dados ou os metadados subjacentes mudam, de acordo com a especificação.

O cabeçalho ETag de um objeto devolve o valor MD5 do objeto se todas as seguintes condições forem verdadeiras:

Hora da modificação

Como parte dos respetivos metadados, cada objeto do Cloud Storage tem uma propriedade updated que indica a última vez que os metadados do objeto foram modificados. A hora é inicialmente definida para a hora de criação do objeto e, em seguida, é alterada sempre que os metadados do objeto são alterados.updated Isto inclui alterações feitas por um requerente, como a modificação de metadados personalizados, bem como alterações feitas pelo Cloud Storage em nome de um requerente, como a alteração da classe de armazenamento com base numa configuração do ciclo de vida dos objetos.

O que se segue?