Auf dieser Seite werden die häufig verwendeten Metadatenfelder erläutert, die zusammen mit Objekten in Cloud Storage gespeichert werden.
Einführung
In Cloud Storage gespeicherte Objekte verfügen über Metadaten, die mit ihnen verknüpft sind.
Metadaten beschreiben die Attribute des Objekts und legen fest, was mit dem Objekt passiert, wenn es aufgerufen wird. Metadaten bestehen aus Schlüssel/Wert-Paaren. Die Speicherklasse eines Objekts wird beispielsweise durch den Metadateneintrag storageClass:STANDARD
dargestellt. storageClass
ist der Schlüssel für die Metadaten. Alle Objekte sind mit einem solchen Schlüssel verknüpft.
STANDARD
gibt den Wert des jeweiligen Objekts an. Dieser ist von Objekt zu Objekt unterschiedlich.
Die Änderbarkeit von Metadaten variiert: einige Metadaten können jederzeit bearbeitet werden, einige Metadaten können nur bei der Objekterstellung festgelegt werden und einige Metadaten können lediglich angezeigt werden. Sie können beispielsweise den Wert der Cache-Control
-Metadaten jederzeit bearbeiten, aber Sie können die storageClass
-Metadaten nur zuweisen, wenn das Objekt erstellt oder umgeschrieben wird. Ferner können Sie den Wert der generation
-Metadaten nicht direkt bearbeiten, aber der generation
-Wert ändert sich, wenn das Objekt ersetzt wird.
Editierbare Metadaten
Es gibt zwei Kategorien von Objektmetadaten, die durch Nutzer geändert werden können:
Metadaten mit festen Schlüsseln: Metadaten, deren Schlüssel festgelegt sind, aber für die Sie einen Wert angeben können.
Benutzerdefinierte Metadaten: Metadaten, die hinzugefügt werden, indem Sie einen Schlüssel und einen mit dem Schlüssel verknüpften Wert angeben.
Beim Bearbeiten von Metadaten sollten Sie generell auf Nicht-ASCII-Zeichen verzichten, da diese in HTTP-Headern, die in der XML API genutzt werden, nicht zulässig sind.
Metadaten mit festem Schlüssel
Sie können die folgenden Metadaten für Objekte bearbeiten, sofern Sie über die erforderliche Berechtigung verfügen:
- Zugriffssteuerungs-Metadaten
- Cachesteuerung
- Inhaltsanordnung
- Inhaltscodierung
- Inhaltssprache
- Inhaltstyp
- Benutzerdefinierte Dauer
- Objekt-Holds
- Konfiguration der Aufbewahrungsdauer
Zugriffssteuerungs-Metadaten
Cloud Storage steuert den Zugriff auf Objekte über die Identitäts- und Zugriffsverwaltung (IAM) und über Access Control Lists (ACLs). Klicken Sie auf die Links, um weitere Informationen zu diesen Zugriffssteuerungsmethoden und den zugehörigen Metadaten zu erhalten.
Cachesteuerung
Die Cache-Control
-Metadaten können zwei verschiedene Aspekte der Datenbereitstellung aus Cloud Storage angeben: ob die Daten zwischengespeichert und ob sie transformiert werden können.
Daten zwischenspeichern
Mit den Cache-Control
-Metadaten können Sie steuern, ob und wie lange Caches Ihre Objekte im Cache speichern dürfen. Diese können dann für zukünftige Anfragen bereitgestellt werden. Caches können Browser- und Internetcaches sowie das integrierte Caching von Cloud Storage umfassen.
Wenn ein anwendbares Objekt keinen Cache-Control
-Metadateneintrag hat, verwendet Cloud Storage den folgenden Standardwert:
public, max-age=3600
, wenn das Objekt nicht mit einem vom Kunden verwalteten Verschlüsselungsschlüssel verschlüsselt oder in einem Virtual Private Cloud-Dienstperimeter gespeichert ist.no-cache, no-store, max-age=0
, wenn das Objekt mit einem vom Kunden verwalteten Verschlüsselungsschlüssel verschlüsselt wird.private, max-age=0
, wenn das Objekt in einem Virtual Private Cloud-Dienstperimeter gespeichert ist.no-cache, no-store, max-age=0, must-revalidate
, wenn das Objekt in einem Virtual Private Cloud-Dienstperimeter und mit einemVom Kunden verwalteter Verschlüsselungsschlüssel verschlüsselt ist.
Wenn Sie Caching zulassen, können Downloads auch nach dem Hochladen einer neueren Version frühere Versionen eines Objekts erhalten. Dies liegt daran, dass solche früheren Versionen für einen von max-age
festgelegten Zeitraum im Cache „neu“ bleiben. Es gibt keine Möglichkeit, den Ablauf eines Objekts global zu erzwingen, da Objekte an verschiedenen Orten im Internet zwischengespeichert werden können. Wenn Sie den öffentlichen Zugriff auf ein Objekt aufheben, kann das Objekt weiterhin über einen Cache bereitgestellt werden, je nachdem, wann der letzte Zugriff erfolgte und wie die Einstellung Cache-Control
des Objekts lautet. Beispiel: Wenn das Objekt mit einer Cache-Control
von public, max-age=3600
bereitgestellt wurde, kann es eine Stunde lang in einem Cache beibehalten werden. Wenn Sie verhindern möchten, dass im Cache gespeicherte Versionen öffentlich lesbarer Objekte bereitgestellt werden, legen Sie Cache-Control: no-store
für das Objekt fest.
Wenn Sie das Cache-Verhalten genauer steuern möchten, können Sie Cloud CDN vor Ihrem Bucket konfigurieren.
Daten umwandeln
Cache-Control
-Metadaten ermöglichen Ihnen außerdem, Objekte so bereitzustellen, wie sie gespeichert sind. Das bedeutet, dass keine Datentransformationen erforderlich ist, etwa durch das Entfernen einer gzip-Inhaltscodierung für inkompatible Clients. Verwenden Sie die Einstellung Cache-Control:no-transform
, um ein Objekt unverändert bereitzustellen.
Inhaltsanordnung
Die Content-Disposition
-Metadaten geben Informationen zur Präsentation der übertragenen Daten an. Wenn Sie Content-Disposition
einstellen, können Sie den Präsentationsstil der Inhalte steuern. Zum Beispiel können Sie festlegen, ob Anhänge automatisch angezeigt werden oder ob zum Öffnen eine bestimmte Nutzeraktion erforderlich ist. Weitere Informationen zur Content-Disposition
-Spezifikation finden Sie unter https://datatracker.ietf.org/doc/html/rfc6266.
Content-Encoding
Mit den Content-Encoding
-Metadaten kann angezeigt werden, dass ein Objekt komprimiert ist, ohne den zugrunde liegenden Content-Type
des Objekts zu verändern.
Der Dateityp einer mit gzip komprimierten Textdatei kann z. B. unter Content-Type
angegeben werden. Die Tatsache, dass es sich um eine mit gzip komprimierte Datei handelt, kann unter Content-Encoding
angegeben werden. Sorgen Sie mithilfe des angegebenen Content-Encoding
-Werts dafür, dass die Dateien tatsächlich komprimiert sind, bevor Sie sie hochladen. Ansonsten kann das Herunterladen der Objekte unerwartetes Verhalten verursachen. Weitere Informationen finden Sie auf der Seite zur Transcodierung.
Bei komprimierbaren Inhalten wie Text können Sie mit Content-Encoding: gzip
Netzwerk- und Speicherkosten einsparen und die Bereitstellung von Inhalten verbessern. Bei Inhalten, die bereits standardmäßig komprimiert sind, z. B. Archive und viele Medienformate, kann es sich jedoch negativ auf die Objektgröße und die Leistung auswirken, wenn eine zusätzliche Komprimierung angewendet und in den Content-Encoding
-Metadaten ausgewiesen wird.
Inhaltssprache
Die Content-Language
-Metadaten geben die Sprachen an, für die das Objekt bestimmt ist. Typische Werte für diese Metadaten finden Sie in den ISO 639-1-Sprachcodes.
Cloud Storage unterstützt Content-Language
-Werte mit einer Länge von bis zu 100 Zeichen.
Content-Type
Die am häufigsten festgelegten Metadaten sind Content-Type
(auch als Medientyp bezeichnet), womit Browser das Objekt ordnungsgemäß rendern können. Alle Objekte weisen in ihren Content-Type
-Metadaten einen Wert auf. Dieser Wert muss aber nicht mit dem zugrunde liegenden Typ des Objekts übereinstimmen. Wenn die Person, die das Objekt hochgeladen hat, beispielsweise keinen Content-Type
angegeben hat und dieser Wert nicht ermittelt werden kann, wird er auf application/octet-stream
oder application/x-www-form-urlencoded
gesetzt. Dies hängt davon ab, wie Sie das Objekt hochgeladen haben. Eine Liste der gültigen Inhaltstypen finden Sie auf der Seite IANA-Medientypen.
Benutzerdefinierte Dauer
Die Custom-Time
-Metadaten sind ein benutzerdefiniertes Datum und eine Uhrzeit im RFC 3339-Format YYYY-MM-DD'T'HH:MM:SS.SS'Z'
oder YYYY-MM-DD'T'HH:MM:SS'Z'
, wenn Millisekunden null sind. Diese Metadaten werden normalerweise festgelegt, um in der Verwaltung des Objektlebenszyklus die Bedingung DaysSinceCustomTime
zu verwenden.
Sie können Custom-Time
nicht mehr entfernen, nachdem Sie es für ein Objekt festgelegt haben. Außerdem kann sich der Wert für Custom-Time
nicht mehr verkürzen. Das heißt, Sie können Custom-Time
nicht auf ein früheres Datum / eine frühere Uhrzeit als die vorhandene Custom-Time
festlegen. Sie können Custom-Time
jedoch effektiv entfernen oder zurücksetzen. Schreiben Sie dazu das Objekt um.
Objekt-Holds
Verwenden Sie Metadaten-Flags, um Objekt-Holds zu platzieren, wodurch Objekte nicht gelöscht oder ersetzt werden können. Weitere Informationen finden Sie auf der Seite "Objekt-Holds".
Konfiguration der Aufbewahrungsdauer
Wenn vorhanden, definiert die Aufbewahrungskonfiguration eines Objekts ein Datum und eine Uhrzeit, zu der das Objekt nicht gelöscht oder ersetzt werden kann. Weitere Informationen finden Sie unter Objektaufbewahrungssperre.
Benutzerdefinierte Metadaten
Benutzerdefinierte Metadaten sind Metadaten, für die Sie sowohl den Schlüssel als auch den Wert definieren. Zum Erstellen von benutzerdefinierten Metadaten geben Sie sowohl einen Schlüssel als auch einen Wert an. Wenn Sie ein benutzerdefiniertes key:value
-Metadatenpaar erstellt haben, können Sie den Schlüssel löschen oder den Wert ändern.
Benutzerdefinierte Metadaten unterliegen einem Größenlimit und es fallen Speicherkosten an.
Auf der Seite Metadaten anzeigen und bearbeiten finden Sie Informationen zum Festlegen benutzerdefinierter Metadaten.
Das Präfix x-goog-meta-
Die Seite XML API legt Objektmetadaten mithilfe von Anfrageheadern fest und ruft diese ab. Die JSON-API ermöglicht das Festlegen benutzerdefinierter Metadaten in der letzten Anfrage eines fortsetzbaren Uploads durch Verwendung von Anfrageheadern. Um benutzerdefinierte Metadaten-Header eindeutig von Standardanfrage-Headern zu unterscheiden, stellen beide APIs solchen benutzerdefinierten Metadaten-Headern das Präfix x-goog-meta-
voran.
Nicht editierbare Metadaten
Einige Metadaten können nicht direkt bearbeitet werden. Diese Metadaten werden zum Zeitpunkt der Erstellung oder Neuschreibung des Objekts festgelegt. Sie haben beim Erstellen oder Umschreiben von Objekten die Möglichkeit, einige dieser Metadaten wie die Speicherklasse des Objekts oder vom Kunden verwaltete Verschlüsselungsschlüssel festzulegen. Andere Metadaten werden automatisch hinzugefügt und können nur angezeigt werden. Dazu gehören unter anderem die Generierungsnummer des Objekts oder die Erstellungszeit.
Generierungs- und Metagenerierungsnummern
Zu den Metadaten eines jeden Cloud Storage-Objekts gehören eine numerische Property generation
und eine numerische Property metageneration
, durch die das Objekt eindeutig identifiziert wird:
Attribut | Beschreibung |
---|---|
generation |
Ermittelt die Version eines Objekts und existiert für jedes Objekt, unabhängig davon, ob ein Bucket die Objektversionsverwaltung verwendet.
|
metageneration |
Gibt die Metadatenversion an und wird jedes Mal erhöht, wenn die Metadaten einer bestimmten generation aktualisiert werden.
|
Die Attribute generation
und metageneration
werden unter folgenden Umständen verwendet:
Wenn Vorbedingungen in Anfragen verwendet werden: Vorbedingungen führen zum Fehlschlagen der Anfrage, wenn die Vorbedingung nicht erfüllt wird. Bei einem Fehlschlagen wird die Anfrage nicht auf eine unerwartete Version eines Objekts angewendet wird, z. B. Abrufen der falschen Objektdaten oder Ändern des falschen Status der Metadaten eines Objekts.
Beim Auflisten, Abrufen, Wiederherstellen und Löschen nicht aktueller Objektversionen: Nicht aktuelle Objektversionen sind insbesondere in Buckets relevant, die die Objektversionsverwaltung verwenden bzw. verwendet haben.
Prüfsummen
Prüfsummen sind Metadaten, die aus den Daten des zugehörigen Objekts berechnet werden. Prüfsummen werden verwendet, um zu prüfen, ob Objektdaten nicht beschädigt sind. Cloud Storage-Objekte haben mehrere Metadatenfelder für Prüfsummen.
CRC32C
Alle Cloud Storage-Objekte haben einen CRC32C-Hash. Zu den Bibliotheken für die Berechnung von CRC32C gehören:
- CRC32C von Google für C++.
- hash/crc32 für Go
- Google APIs Guava für Java
- google-crc32c für Python
- digest-crc für Ruby
Der mit Base64 codierte CRC32C wird in Big-Endian-Bytereihenfolge angeordnet.
MD5
Cloud Storage-Objekte haben einen MD5-Hash, wenn sie die folgenden Kriterien erfüllen:
- Das Objekt ist kein zusammengesetztes Objekt
- Das Objekt wurde nicht mit einem mehrteiligen XML API-Upload hochgeladen.
Dieser Hash gilt nur für ein vollständiges Objekt. Bei GET-Anfragen mit Anfragebereich kann er deshalb nicht für die Integritätsprüfung von Teil-Downloads verwendet werden.
ETags
Alle Cloud Storage-Objekte haben ein ETag. Dasselbe Objekt kann aber einen anderen ETag-Wert haben, wenn es von der XML API im Vergleich zur JSON API angefordert wird. In den meisten anderen Fällen sollten Nutzer keine Annahmen über den in einem ETag verwendeten Wert treffen, es sei denn, er ändert sich, wenn sich die zugrunde liegenden Daten oder Metadaten gemäß der Spezifikation ändern.
Der ETag-Header eines Objekts gibt den MD5-Wert des Objekts zurück, wenn alle folgenden Bedingungen erfüllt sind:
- Die Anfrage wird über die XML API gesendet.
- Das Objekt verwendet nur von Google eigene und von Google verwaltete Schlüssel für die serverseitige Verschlüsselung.
- Das Objekt ist kein zusammengesetztes Objekt und wurde nicht mit einem mehrteiligen XML API-Upload hochgeladen.
Änderungszeit.
Zu den Metadaten eines jeden Cloud Storage-Objekts gehört das Attribut updated
, das angibt, wann die Metadaten des Objekts zuletzt geändert wurden. Die updated
-Zeit wird anfänglich auf den Erstellungszeitpunkt des Objekts eingestellt und ändert sich, wenn sich die Metadaten des Objekts ändern. Hierzu gehören Änderungen, die von einem Anfragenden vorgenommen wurden, wie z. B. das Ändern von benutzerdefinierten Metadaten, sowie von Cloud Storage im Auftrag eines Anfragenden vorgenommene Änderungen, wie z. B. das Ändern der Speicherklasse basierend auf einer Konfiguration des Objektlebenszyklus.
Nächste Schritte
- Objektmetadaten ansehen und bearbeiten
- Speicherklassen
- Eine detaillierte Beschreibung aller in der JSON API verfügbaren Objektmetadatenfelder finden Sie in der JSON-Objektreferenzdokumentation.
- Erfahren Sie mehr über Storage Insights-Inventarberichte, mit denen Sie die Metadaten für alle Objekte in einem Bucket auf einmal abrufen können.