- I Drive er det bare etiketter som kan fjernes; indekserbar tekst og miniatyrbilder administreres ved å oppdatere innholdet.
- Systemegenskaper (størrelse, tidsstempler) slettes ikke; forstå deres begrensninger og funksjon.
- Hvis du overfører til Cloud Storage, bevares noen metadata og noen ikke. Planlegg deretter.
- VM-metadata i Compute Engine har spesifikke begrensninger og tillatelser, forskjellig fra Drive.
Eliminer metadatos på Google Disk
Hvis du er bekymret for hvilken ekstra informasjon som følger med filene dine i skyen, har du sannsynligvis lurt på hvordan du kan rydde opp i eller kontrollere disse usynlige dataene. I Google Disk spenner metadata fra tagger og indekserbar tekst til miniatyrbilder og filegenskaper. Nøkkelen er å forstå hva som kan fjernes, hva som bare kan oppdateres og hva som ikke kan røres , slik at du kan handle presist uten å ødelegge noe.
Gjennom hele denne veiledningen har vi samlet informasjon som er spredt utover diverse offisielle Google-dokumentasjoner og hjelpeartikler på ett sted. Du lærer hvordan du fjerner tag-metadata fra en fil, administrerer indekserbar tekst og miniatyrbilder, og forstår begrensninger og unntak . Vi forklarer også lignende scenarier (overføringer av skylagring og VM-metadata i Compute Engine) for å unngå forvirring hvis du jobber med Google Cloud.
Hva er metadata i Drive, og hvor langt går begrepet?
I Google Drive inkluderer metadata informasjon som navn, MIME-type, antatt filtype, etiketter, indekserbar tekst og tilhørende miniatyrbilder. Noen deler kan redigeres eller slettes (f.eks. etiketter), andre oppdateres indirekte (indekserbar tekst og miniatyrbilder), og andre kan ikke slettes fordi de er en del av systemet (for eksempel filstørrelse eller interne opprettelses- og oppdateringsdatoer).
Du vil også se referanser til metadata i andre Google Cloud-produkter, for eksempel Cloud Storage eller Compute Engine. Du bør ikke forveksle metadataene til en virtuell maskin eller et objekt i Cloud Storage med metadataene til en Drive-fil.de deler konseptet, men håndteringen og begrensningene deres er forskjellige.
Administrer metadata i Drive
Hva som faktisk kan fjernes i Drive
Fra et praktisk synspunkt er det som oftest anses som å "fjerne metadata" i Drive å fjerne etiketter som er brukt på en fil. Etiketter kan inneholde felt (tekst, bruker osv.), og å fjerne dem sletter den tilhørende informasjonen fra filen . Denne slettingen utføres via API ved hjelp av atomoperasjoner.
Den indekserbare teksten (contentHints.indexableText) blir ikke bare «slettet» med en knapp; den overskrives eller blir stående tom når du oppdaterer filressursen . Den er utformet for å forbedre synligheten av filtyper som Drive ikke indekserer innebygd.
Tilpassede miniatyrbilder håndteres på samme måte: du kan laste opp et annet miniatyrbilde eller slutte å levere et . Hvis Drive kan generere et standard miniatyrbilde, vil det bruke sitt eget; hvis ikke, vil det bruke det du leverer.
Enkelte metadata i Drive, som filstørrelse og interne tidsstempler, kan ikke slettes. Disse systemegenskapene oppdateres av selve tjenesten og kan ikke slettes direkte.
Fjern etiketter fra en fil i Google Disk
Drive API lar deg endre eller fjerne etiketter ved hjelp av metoden files.modifyLabels. Forespørselen inneholder et objekt av typen ModifyLabelsRequest med én eller flere modifikasjoner som brukes atomisk. (hvis noen av dem ikke er gyldige, gjelder ingenting).
For å fjerne en tagg fullstendig fra en fil, send en LabelModification med etikettidentifikatoren og sletteinstruksjonen. Denne prosessen fjerner alle feltene fra den taggen i filen.Hvis du bare trenger å deaktivere et bestemt felt, kan du «fjerne innstillinger» for det feltet uten å fjerne hele taggen.
Konseptuelle trinn for å fjerne en tagg fra en bestemt fil: 1) identifiserer labelId-en til etiketten som finnes i filen (du kan liste dem opp med files.listLabels), 2) Send inn endringen med removeLabel aktivert, 3) validerer at svaret inkluderer den endelige tilstanden til de oppdaterte etikettene.
Indekserbar tekst: kontroll, grenser og god praksis
Hvis appen din lagrer filtyper som ikke bare indekseres av Drive (tegninger, videoer, snarveier osv.), kan du øke søkbarheten ved å fylle ut contentHints.indexableText. Denne teksten behandles som HTML, indekseres og kan vises i resultatsammendrag. på flere søkeflater.
Viktige anbefalinger og begrensninger: Maksimal størrelse på indexableText er 128 KB ; registrer termer og konsepter som virkelig beskriver innholdet; ikke forsøk å sortere teksten etter relevans, indekseringsprogrammet prioriterer allerede; oppdater teksten ved hver lagring ; unngå "fylling" med urelaterte nøkkelord (det ender opp med å frustrere brukere og kan oppmuntre til sletting).
Husk at siden det behandles som HTML, er det tekstinnholdet som indekseres, ikke attributter . Hvis for eksempel strengen din inneholder tagger med attributter, vil den synlige teksten bli indeksert, ikke verdiene til disse attributtene.
Miniatyrbilder: Last opp, erstatt og gjenopprett
Disk genererer automatisk miniatyrbilder for Dokumenter, Regneark, Presentasjoner og andre typer. Hvis filtypen din ikke genererer et standard miniatyrbilde, kan du legge ved et. konfigurering contentHints.thumbnail når du oppretter eller oppdaterer filen.
Krav for tilpassede miniatyrbilder: Bruk PNG, GIF eller JPG; anbefalt bredde 1600 piksler (minimum 220 piksler); maksimal filstørrelse 2 MB; gir det URL-sikre base64-kodede bildet og mimeType riktig. Miniatyrbildet må oppdateres hver gang du lagrer, fordi den blir ugyldig når filinnholdet endres (metadataendringer alene gjør den ikke ugyldig).
For å hente miniatyrbildet, kryss av i feltet thumbnailLink av ressursen files. Det er en kortvarig lenke og vises bare hvis appen din har tilgang til innholdet.Hvis filen ikke er offentlig, trenger du påloggingsinformasjon for å bruke lenken.
Eksempler på spørring av metadata med miniatyrbilder via REST:
GET https://www.googleapis.com/drive/v3/files/FILE_ID?fields=id,name,mimeType,thumbnailLink
GET https://www.googleapis.com/drive/v3/files?q=mimeType='application/vnd.google-apps.spreadsheet'&fields=files(id,name,mimeType,thumbnailLink)
Filnavn og filtyper: hva du bør vite
Når du setter inn en fil via API, anbefales det å spesifisere filtypen i egenskapen. name (for eksempel, cat.jpg). Drive vil spre den utvidelsen som fileExtension skrivebeskyttet i påfølgende svar, og når brukeren laster ned filen eller synkroniserer med skrivebordsklienten, genereres hele navnet basert på tittelen.
Hvis du ikke oppgir en filtype, vil Drive prøve å bestemme den fra MIME-typen . Spesifiser den når det er mulig for å unngå overraskelser.
Ikke forveksle fjerning av metadata med sletting av filer.
Å fjerne metadata og å slette filer er forskjellige handlinger. Hvis du eier en fil og sender den til papirkurven, sletter du ikke metadata; du fjerner filen fra harddisken din . Slettealternativet (når du ikke er eieren) skjuler den ganske enkelt for deg, men andre vil fortsatt se den.
Slik sender du en fil til papirkurven på nettet: gå til drive.google.com, høyreklikk og velg Flytt til papirkurv . Hvis noen andre eier filen, ser du Fjern. For å slette filen permanent, tøm papirkurven. Ingen av disse trinnene fjerner metadata fra den lagrede filen: du sletter enten filen eller administrerer metadataene ved hjelp av alternativene som er forklart.
Overføringer og oppbevaring av metadata i skylagring (i tilfelle du flytter data)
Når du jobber med Storage Transfer Service til/fra Cloud Storage, finnes det regler for hvilke metadata som beholdes og hvilke som ikke beholdes. Dette er viktig hvis du bruker Drive med buckets eller migrerer data mellom skyer.
Fra Amazon S3 eller kompatibel med Cloud Storage
- De er bevart metadatafelt med fast nøkkel (f.eks. Cache-Control, Content-Disposition, Content-Type).
- Brukerdefinerte metadata sendes til tilpassede metadata i skylagring (redigerbar).
- El
ETagDen lagres som personlig tilpasset med nøkkelenx-goog-source-etag. - Objektstørrelsen bevares som
size. - S3-tilgangskontrolllister og objektkoder: er ikke bevart.
- S3-tidsstempelmetadata: er ikke bevartI skylagring,
timeCreatedyupdatedgjenspeile opprettelses-/oppdateringsøyeblikket på destinasjonen. - Lagringsklasse: konfigurerbar under overføring (som standard den for målbøtten).
Fra Microsoft Azure Blob til skylagring
- Faste felt for viktige metadata: de er bevart.
- Brukerdefinerte metadata: er lagret som egendefinerte i skylagring.
ETagDen er bevart somx-goog-source-etag.- Størrelse som
sizeADLS Gen2 POSIX-tillatelser og spesifikk tilgangskontroll: er ikke bevart. - Azure Timestamp-metadata: er ikke bevart.
timeCreated/updatedberegnes på nytt ved destinasjonen. - Lagringsklasse: konfigurerbar som i tilfellet med S3.
Mellom Cloud Storage-bøtter
- Faste og tilpassede nøkkelmetadata: de er bevart.
- Objektgenerering: lagret som tilpassede metadata
x-goog-reserved-source-generation. - Oppbevaringer: Midlertidige oppbevaringer beholdes som standard; hendelsesbaserte oppbevaringer blir ikke det. Vær oppmerksom på LCADu kan beholde dem, men unngå å opprette utilgjengelige objekter.
- Lagringsklasse: Behold, angi en ny, eller bruk den fra målbøtten.
- CMEK-kryptering: valgfritt å beholde; som standard brukes destinasjonsbøttemetoden.
timeCreatedkan oppbevares icustomTime;updatednei.- Andre ikke-redigerbare metadata (f.eks.
etag,componentCount): Nei..
Lister over URL-er til skylagring
- Faste felt for viktige metadata: redigerbar på destinasjonen.
Content-LengthyMD5: ikke redigerbar og er bevart hvis kilden oppgir dem.- Kildetidsstempler: Nei.Lagringsklasse: konfigurerbar.
POSIX til skylagring (og omvendt)
mtimebevart som tilpassede metadatagoog-reserved-file-mtime.- Størrelsen er bevart som
sizeUID, GID, MODE og symbolske lenker: valgfri avmetadataOptions. - I POSIX til POSIX kan UID/GID/MODE bevares på filer og mapper;
mtimeDen lagres for filer (i mapper brukes opprettelsestidspunktet på destinasjonen).
Disse detaljene er viktige når du flytter data mellom tjenester. Ikke forvent at sletting av metadata i ett system magisk vil få dem til å forsvinne i et annet ; respekter oppbevaringsreglene for hver overføring.
Metadata for Compute Engine (VM): Begrensninger og sletting, hvis du bruker Google Cloud
Selv om det ikke er Drive, har mange team tilgang til VM-metadata i Compute Engine. For å administrere dette trenger du de nødvendige IAM-tillatelsene og kunnskap om størrelses- og omfangsgrenser.
Først av alt: Installer Google Cloud CLI og kjør det for første gang med gcloud init (Hvis du bruker en ekstern identitetsleverandør, logg inn i føderasjonsmodus.) Hold CLI-en oppdatert gcloud components update og angi standardregion og -sone for å unngå omfangsfeil.
Typiske nødvendige tillatelser: Hvis de virtuelle maskinene bruker tjenestekontoer, er nødvendig iam.serviceAccounts.actAsFor metadata på prosjektnivå: compute.projects.get y compute.projects.setCommonInstanceMetadata. For sonemetadata: compute.instanceSettings.get y compute.instanceSettings.updateFor metadata på en bestemt virtuell maskin: compute.instances.get y compute.instances.setMetadata.
Viktige begrensninger: Metadatasettet per virtuell maskin har et samlet maksimum på 512 KBhver tast opp til 128 bytes og hver verdi opp til 256 KBSSH-nøkler lagres i ssh-keys; hvis du overskrider grensen, Det er på tide å rydde opp i ubrukte nøklerHvis du legger oppstarts-/avslutningsskript som direkte innhold, teller de mot grensen. Lagre i stedet skriptet i Cloud Storage og oppgir bare URL-en.
Store/små bokstaver: tastene skiller mellom store og små bokstaver; verdier også, bortsett fra boolske verdier. For sonale metadata: kun administrert med gcloud eller REST; Du kan ikke duplisere nøkler med samme tekst ved å endre store og små bokstaver (f.eks. opprett ZONAL-METADATA-KEY hvis zonal-metadata-key allerede finnes); og du kan ikke definere soneverdier for ssh-keys.
Boolske verdier godtar ekvivalenter: SANN/USANN og alternativer som J/Ja/1 og N/Nei/0, uten å skille mellom store eller små bokstaver.
Omfang og prioritet: Det samme nøkkelnavnet kan finnes på både prosjekt- og sonenivå, men soneverdien har prioritet i sonen . Hvis du legger til en soneverdi, brukes den for virtuelle maskiner i den sonen, selv om det finnes en verdi på prosjektnivå. Å legge til en prosjektverdi overstyrer ikke eksisterende soneverdier.
Vanlige operasjoner: Du kan konfigurere prosjektmetadata (gjelder alle virtuelle maskiner), sonemetadata (påvirker alle virtuelle maskiner i en sone innenfor det prosjektet) og forekomstmetadata (bare for én virtuell maskin). For å fjerne metadata lar gcloud eller REST deg slette prosjekt-, sone- eller forekomstmetadata etter behov.
Bruk av REST lokalt: REST API-eksemplene bruker legitimasjonen du oppga til gcloud CLI. Autentiser miljøet ditt og bruk denne legitimasjonen på nytt for å teste kall fra maskinen din.
Praktiske tips for bedre metadatahygiene i Drive
Hvis du vil redusere fotavtrykket ditt i Drive, fokuser på det du kan kontrollere: etiketter (fjern dem hvis de ikke tilfører verdi), indekserbar tekst (juster eller tøm den hvis du ikke trenger den) og miniatyrbilder (erstatt dem eller unngå å laste dem opp) . Systemegenskaper er for revisjon, ikke sletting.
Når en fil deles og du ikke er eieren, husk at det å fjerne den fra visningen din ikke sletter noe for andre. Koordiner med eieren hvis målet er å fjerne tilknyttet innhold eller metadata fullstendig.
Hvis du integrerer Drive med flyter i Cloud Storage eller med virtuelle maskiner, må du dokumentere forventningene. Mange metadata endres eller overføres ikke mellom systemer . Unngå automatiseringer som er avhengige av tidsstempler eller tilgangskontrollister som ikke bevares.
Med disse retningslinjene har du kontroll over hva som virkelig utgjør en forskjell. Administrer tagger presist, kontroller hva som er indekserbart, og bestem når og hvordan du skal bruke miniatyrbilder for å finne en balanse mellom personvern, søkbarhet og brukeropplevelse.
