DigitalForensics

70 13 63 23

Produktion af data: native filer, PDF, loadfiler og nummerering

Produktion af data: native filer, PDF, loadfiler og nummerering

Forside › eDiscovery teknisk · Gennemgået oktober 2026 · Af John Nielsen

En produktion er den pakke af dokumenter, der udleveres til modparten, retten eller en skønsmand. Den består af selve dokumenterne i et aftalt format, en fortløbende nummerering og en loadfil, der kobler hvert dokument til dets metadata. Formatvalget afgør, hvad modtageren kan efterprøve: Et native dokument bevarer formler, metadata og intern struktur, mens en PDF eller et billede kun viser overfladen.

Den praktiske side af selve overleveringen, kryptering og deling, er beskrevet i sikker deling af store datamængder. Her går vi i dybden med, hvordan produktionen bygges teknisk, og hvor den typisk går galt.

De tre grundformater

  • Native · Originalfilen, som den lå i kilden. Bevarer metadata, formler, skjulte ark og indlejrede objekter. Kan ikke maskeres uden at ændre filen, og hver side kan ikke nummereres.
  • Billede (TIFF eller JPG) med tekstfil · Hver side gengives som billede, teksten leveres separat. Kan nummereres og maskeres sikkert. Mister formler, dynamisk indhold og en del metadata.
  • Søgbar PDF · Billede og tekstlag i én fil. Let at åbne for alle parter. Samme tab af struktur som billeder, og maskering skal udføres korrekt for ikke at efterlade tekst under en sort boks.

I praksis bruges ofte en blanding: billeder eller PDF som hovedformat, og native for regneark, præsentationer, lyd, video og databaser, hvor et billede giver et misvisende eller ubrugeligt resultat. Et regneark med tusindvis af rækker bliver hundredvis af sider, der ikke kan sorteres, og en formel bliver til en værdi uden forklaring.

Nummerering

Hver side eller hvert dokument får et unikt løbenummer, ofte med et præfiks, der angiver parten og produktionen, fx ABC-000001. I angelsaksisk praksis kaldes det Bates-nummerering. Nummeret stemples på hver side i billed- og PDF-produktioner. For native filer får dokumentet ét nummer, og filnavnet ændres til nummeret, så filen kan findes ud fra henvisningen.

Native filer leveres ofte sammen med en pladsholderside (slipsheet) i billedproduktionen. Siden bærer nummeret og en tekst om, at dokumentet er leveret native. Så hænger nummerrækken sammen, og den, der læser billedproduktionen, ved, at der mangler noget visuelt.

Nummereringen skal fastlægges, før der produceres, og må ikke genbruges. Skal et dokument erstattes, fx fordi en maskering var forkert, får det et nyt nummer eller et versionssuffiks, og det gamle markeres som trukket tilbage. Ellers kan to parter henvise til samme nummer og mene to forskellige dokumenter.

Loadfilen

Loadfilen er en struktureret tekstfil, der beskriver produktionen. Der findes typisk to slags:

  • Metadatafil: én række pr. dokument med felter som startnummer, slutnummer, familiens første og sidste nummer, kilde (custodian), filnavn, filsti, sendt- og modtagetidspunkt, afsender, modtagere, emne, hashværdi og stier til native fil og tekstfil. Formatet er ofte afgrænset tekst med særlige skilletegn, der sjældent forekommer i almindelig tekst.
  • Billedfil: angiver, hvilke billedfiler der hører til hvilket dokument, og hvor et nyt dokument begynder.

De konkrete formater stammer fra udbredte reviewplatforme og er blevet en uformel standard. Det mest kendte par er en DAT-fil med metadata og en OPT-fil med billedreferencer. Som standard bruger DAT-filen tegn, der næsten aldrig forekommer i tekst, fx þ som tekstafgrænser, men platformene kan sætte andre skilletegn og andre tegnsæt, fx ASCII eller UTF-8. Skilletegn, tegnsæt og feltnavne bør derfor aftales med modtageren i stedet for at blive antaget.

Tegnsættet er en klassisk fejlkilde for danske data. Gemmes loadfilen i et andet tegnsæt end det, modtagerens system forventer, bliver æ, ø og å til uforståelige tegn i navne og emnelinjer, og søgninger på dem rammer ikke. UTF-8 er det sikre valg, når modtageren kan læse det.

Familier

En mail med vedhæftninger er en familie. Produktionen skal bevare relationen, så modtageren kan se, hvilken vedhæftning der fulgte med hvilken mail. Det gøres med felterne for familiens første og sidste nummer, og ved at forælder og børn nummereres fortløbende.

Der skal tages stilling til, hvad der sker, når kun en del af familien er relevant eller fortrolig. Den almindelige praksis er at producere hele familien og maskere eller erstatte det fortrolige med en pladsholderside, så hullet er synligt. Relationerne bag familier og tråde er beskrevet i mailtråde og familierelationer.

Bevarelse af metadata

Metadata i loadfilen er ikke det samme som metadata i filen. Felterne er udtrukket af behandlingsværktøjet, og de afhænger af, hvordan værktøjet har tolket kilden. Tre forhold skal styres:

  1. Tidszone: Alle tidspunkter i loadfilen skal være i én angivet tidszone, typisk UTC, og det skal stå i følgebrevet. Ellers kan to produktioner fra samme kilde vise forskellige tidspunkter for samme mail. Se sommertid og tidszoner i rapporten.
  2. Datoformat: Et entydigt format som år-måned-dag undgår forveksling mellem dansk og amerikansk datoorden.
  3. Hashværdi: Hashværdien skal være beregnet på det oprindelige element, ikke på den producerede kopi. For mails skal det angives, hvilken metode der er brugt, fordi en mail ikke har én naturlig fil at hashe.

Native filer, der kopieres ud af behandlingsplatformen, får ofte nye filsystemtidsstempler. De oprindelige værdier findes derfor kun i loadfilen. Det skal fremgå tydeligt, så ingen fortolker filens egne tidsstempler som kildens.

Kontrol før udlevering

En produktion bør kontrolleres som et selvstændigt produkt:

  • ☐ Antal dokumenter i loadfilen svarer til antal native filer, tekstfiler og billedsæt.
  • ☐ Nummerrækken er ubrudt, og der er ingen dubletter.
  • ☐ Alle stier i loadfilen peger på filer, der findes.
  • ☐ Stikprøver af maskerede dokumenter viser, at teksten er væk i både billede, tekstfil og metadata.
  • ☐ Tegnsættet er korrekt; danske tegn vises rigtigt.
  • ☐ Familier er intakte, og pladsholdersider står, hvor de skal.
  • ☐ Der er et hashmanifest over hele leverancen, så modtageren kan kontrollere, at alt er modtaget uændret.

Hashmanifestet er forskelligt fra hashværdierne i loadfilen. Det dokumenterer selve leverancen, mens loadfilens hashværdier dokumenterer kilden. Se hashmanifest for filsamlinger og produktioner.

Typiske fejlkilder

  • Maskering i PDF uden fjernelse af tekstlaget. Den sorte boks ligger oven på teksten, som stadig kan kopieres eller søges frem. Maskeringen skal brænde billedet og fjerne den underliggende tekst. Teknikken og faldgruberne gennemgås i pseudonymisering og maskering.
  • Dokumenter, der ikke kunne gengives. Krypterede filer, ukendte formater og beskadigede filer kan ikke billedgøres. De skal fremgå af en undtagelsesliste og ikke bare forsvinde. Se behandling af data.
  • Deduplikering, der fjerner kontekst. Er der deduplikeret globalt, skal loadfilen angive alle kilder, der havde dokumentet, ellers mister modtageren oplysningen om, hvem der havde det. Se deduplikering.
  • Ændrede filnavne uden sporbarhed. Når native filer omdøbes til løbenumre, skal det oprindelige navn og den oprindelige sti stå i loadfilen.
  • Skjult indhold, der vises i den ene version og ikke i den anden. Kommentarer, sporede ændringer, skjulte rækker og talenoter skal gengives efter en aftalt regel.

Hvad en produktion kan og ikke kan dokumentere

En korrekt produktion viser, hvilke dokumenter der er udleveret, i hvilken form og med hvilke metadata. Den viser ikke i sig selv, at udvælgelsen var fuldstændig. Det kræver dokumentation af kilder, søgninger, filtre og deduplikering forud for produktionen. Den viser heller ikke, at metadata er korrekte i forhold til kilden; de er kun så gode som det værktøj, der udtrak dem.

Modtageren kan efterprøve en produktion ved at kontrollere hashmanifestet, sammenligne loadfilens felter med de native filer og bede om native versioner af udvalgte dokumenter, hvor billedet rejser spørgsmål.

Dokumentation

Ledsag produktionen af et kort følgebrev eller en teknisk note: nummerinterval, antal dokumenter og sider, formater, tidszone, datoformat, tegnsæt, feltliste med forklaring, hashmetode, behandling af undtagelser og maskeringer samt hashmanifestets egen hashværdi. Gem den nøjagtige produktion, som den blev udleveret, så det senere kan vises, hvad modtageren fik.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: eDiscovery teknisk

Læs også: Filtrering af advokatkorrespondance og fortrolige dokumenter · Behandling af data (processing): udpakning, filtyper og fejlfiler

→ eDiscovery teknisk · 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

John Nielsen, IT-sagkyndig

Brug for en forensisk undersøgelse?

Skriv kort, hvilke systemer eller enheder det drejer sig om, og om noget haster, så vender jeg tilbage. Kun civile sager.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.