Metadata i Office‑filer: forfatter, tider og redigeringstid i core.xml og app.xml

Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen

En Word-, Excel- eller PowerPoint-fil i de moderne formater gemmer sine dokumentegenskaber i to små XML-filer inde i filen: core.xml med forfatter, sidst gemt af, oprettelses- og ændringstid og revisionsnummer, og app.xml med program, version, samlet redigeringstid og statistik. Felterne er nyttige, men de fleste af dem afspejler indstillinger og handlinger i det program, der sidst gemte filen, ikke nødvendigvis det, en person har gjort. Hvem der står som forfatter, er fx det navn, Office var sat op med, da dokumentet blev oprettet, og oprettelsesdatoen følger ofte dokumentet gennem kopiering og Gem som.

De tekniske tegn på forfalskning, herunder rsid-værdier, fonte, ZIP-strukturen og PDF, er gennemgået i Dokumentforfalskning: tekniske tegn. Brugerperspektivet på Office-filer som bevis findes på digitalbevissikring.dk. Her går vi i dybden med de enkelte felter. Hvordan felterne indgår i en samlet dokumentundersøgelse, står i Teknisk undersøgelse af dokumenter og metadata.

Hvor felterne ligger

Moderne Office-filer er ZIP-arkiver efter standarden Open Packaging Conventions. Egenskaberne ligger i mappen docProps:

core.xml: kerneegenskaber efter en fælles standard, med felter fra Dublin Core.
app.xml: udvidede egenskaber, som Office-programmet selv vedligeholder.
custom.xml: brugerdefinerede egenskaber, fx fra dokumentsystemer, skabeloner eller følsomhedsetiketter. Findes ikke altid.

Ældre binære formater (doc, xls, ppt) gemmer lignende oplysninger i særlige strømme i filen med tider i Windows’ FILETIME-format. Principperne er de samme, men værktøjerne er andre.

core.xml: felt for felt

dc:creator · Forfatter. Sættes ved oprettelse ud fra brugernavnet i Office eller den tilknyttede konto. Følger med ved Gem som og kopiering.
cp:lastModifiedBy · Sidst gemt af. Opdateres ved hver gemning til det aktuelle brugernavn.
dcterms:created · Oprettet. Sættes ved oprettelse og følger normalt dokumentet gennem Gem som. Et nyt dokument fra en skabelon får typisk et nyt tidspunkt.
dcterms:modified · Sidst ændret. Opdateres ved hver gemning.
cp:revision · Revisionsnummer. Øges ved gemninger, men ikke nødvendigvis med én pr. gemning i alle versioner og ved automatisk lagring.
cp:lastPrinted · Sidst udskrevet, hvis dokumentet er udskrevet og derefter gemt.
dc:title, dc:subject, cp:keywords, dc:description · Felter, brugeren eller en skabelon kan udfylde. Ofte arvet fra en skabelon eller et tidligere dokument.

Tiderne i core.xml skrives af Microsoft Office i UTC med et afsluttende Z. Andre programmer kan skrive lokal tid eller udelade zonen. Notér altid den rå værdi og omregn bevidst.

Brugernavnet i dc:creator og cp:lastModifiedBy er det navn, der var sat op i Office eller fulgte med den konto, Office var logget ind med. Det kan være et fuldt navn, initialer, et generisk navn som “Bruger” eller et navn fra den person, der installerede maskinen. Det er en indstilling, ikke en autentificeret identitet.

app.xml: felt for felt

Application og AppVersion · Programmet, der sidst gemte filen, og dets hovedversion. Viser ikke nødvendigvis det program, der oprettede dokumentet.
TotalTime · Samlet redigeringstid i minutter. Tæller den tid, dokumentet har været åbent til redigering.
Pages, Words, Characters, Lines, Paragraphs · Statistik beregnet ved sidste gemning. Kan være forældet, hvis programmet ikke har opdateret den.
Template · Den skabelon, dokumentet er baseret på, fx Normal.dotm eller en firmaskabelon.
Company og Manager · Typisk fra Office-installationen eller skabelonen.
TitlesOfParts · For Excel og PowerPoint fx navne på ark eller dias, også skjulte ark.

TotalTime er det felt, der oftest fejltolkes. Tiden måles, mens dokumentet er åbent og kan redigeres, uanset om nogen skriver. Et dokument, der har stået åbent over natten, får en høj værdi. Omvendt kan et dokument, der er kopieret ind fra et andet på få minutter, have en lav værdi, selv om teksten er lang. Feltet kan desuden nulstilles eller opføre sig anderledes ved samtidig redigering i cloud, automatisk lagring og redigering i andre programmer. Adfærden er ikke dokumenteret i detaljer, så ved tvivl bør den efterprøves med en testfil i samme programversion og arbejdsform.

For Excel er TitlesOfParts nyttig, fordi den lister ark, der kan være skjulte. Undersøgelse af skjulte ark og formler er beskrevet i Excel i undersøgelser.

custom.xml

Brugerdefinerede egenskaber kan rumme oplysninger, der er uafhængige af brugerens Office-indstillinger:

dokument-id’er og versionsfelter fra dokumentsystemer,
egenskaber fra SharePoint-indholdstyper,
følsomhedsetiketter med etiketnavn, og i mange tilfælde tidspunktet for, hvornår etiketten blev sat, og hvilken metode der blev brugt.

Et tidspunkt for en etiket kan være et nyttigt uafhængigt holdepunkt, fordi det skrives af etiketfunktionen og ikke af brugeren. I det ældre format hedder felterne MSIP_Label_ efterfulgt af etikettens id og fx _SetDate eller _Method. Har organisationen slået samtidig redigering af etiketterede filer til, gemmes etiketoplysningerne i stedet i docMetadata/LabelInfo.xml i pakken, og custom.xml indeholder dem ikke længere. Hvilke felter der findes, skal derfor aflæses i den konkrete fil.

Typiske fejlkilder

Gem som arver oprettelsesdatoen. Et dokument, der er gemt som et nyt dokument ud fra et gammelt, kan have en oprettelsesdato fra det gamle.
Skabeloner bærer egenskaber. Titel, firma, emne og nogle gange forfatter kommer fra skabelonen.
Andre programmer skriver anderledes. LibreOffice, Google Docs-eksport, dokumentgeneratorer og konverteringsværktøjer udfylder felterne forskelligt eller lader dem stå tomme.
Dokumentsystemer opdaterer egenskaber. Upload og download fra SharePoint eller andre dokumentsystemer kan skrive egne felter ind i filen. Versionshistorikken i systemet er ofte en bedre kilde; se SharePoint og OneDrive: versionshistorik.
Fjernelse af personlige oplysninger. Office har en funktion til at fjerne egenskaber, og mange organisationer kører den automatisk ved udsendelse. Tomme felter er ikke i sig selv mistænkelige. Om advokaters egne dokumenter, se digital-bevissikring.dk.

Felternes indbyrdes sammenhæng

Felterne bliver mere sigende, når de læses sammen. Nogle kombinationer, der ofte giver anledning til spørgsmål, har en helt normal forklaring:

Sidst udskrevet før oprettet. Opstår typisk, når et udskrevet dokument er gemt som et nyt, så udskriftstiden arves, mens oprettelsestiden er ny.
Forfatter og sidst gemt af er forskellige. Normalt, når et dokument er sendt rundt eller bygger på en kollegas skabelon.
AppVersion passer ikke med den påståede dato. Hovedversionen er grov. Den samme værdi kan dække mange års udgivelser, så den kan sjældent datere et dokument præcist, men en version, der først fandtes efter den påståede dato, er et reelt spørgsmål.
Application er ikke Microsoft Office. Filen er sidst gemt af et andet program, fx en konverter, en webeditor eller et dokumentsystem. Det forklarer ofte tomme eller usædvanlige felter.

Det afgørende er at beskrive, hvilke forløb der kan forklare den samlede kombination, og om den påståede historik er et af dem.

Sammenhold med filsystemet

Dokumentets egne tider skal sammenholdes med filsystemets tidsstempler på den computer eller det lager, hvor filen ligger. De to sæt har forskellig oprindelse og reagerer forskelligt på kopiering, download og mail. Metoden er beskrevet i Tilbagedaterede dokumenter.

Udlæsning og dokumentation

Udlæs felterne fra alle tilgængelige eksemplarer af dokumentet, ikke kun det fremlagte. Forskelle mellem eksemplarer, fx en anden værdi i sidst gemt af eller en højere revision, kan vise, hvor i forløbet en version er opstået.

Arbejd på en kopi med kendt hashværdi. Felterne kan læses ved at pakke en kopi af filen ud og åbne XML-filerne eller med metadataværktøjer, der viser de rå værdier. Undgå at åbne originalen i Office, fordi programmet kan opdatere felter ved gemning og nogle gange ved blot at åbne. Rapporten bør gengive de rå værdier med feltnavn og fil, angive, hvordan tider er omregnet, og for hvert felt forklare, hvad det kan og ikke kan vise. En enkelt værdi bør sjældent bære en konklusion alene.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Analyse og fortolkning

Læs også: Dokumentforfalskning: tekniske tegn i Office- og PDF-filer · Hvornår er billedet taget? EXIF, XMP og IPTC forklaret

→ Teknisk undersøgelse af dokumenter og metadata · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik