En PDF er ikke én enkelt ting. Det er en binær beholder med en spesifikk struktur på disk, et sett med innholdslag stablet inni den beholderen, og en familie av ISO-standarder bygget oppå grunnspesifikasjonen. Åpne en i en hex-editor, og strukturen er synlig i klartekst på de første linjene. Åpne en i en seer, og lagene gjengis sammen som én enkelt side.

Denne veiledningen er en merket referanse: den fysiske filstrukturen, innholdslagene en kropp inneholder, metadataene som omgir alt, og standardene (PDF/A, PDF/X, PDF/UA, PDF/E, PDF/VT) som begrenser den for spesifikke bruksområder.

Anatomy of a PDF file: header, body objects, cross-reference table, trailer, content layers, and metadata

Vil du bruke dette diagrammet på bloggen din? Kopier denne innbyggingskoden:

De fire fysiske delene

Enhver PDF på disk har den samme firedelte strukturen, i denne rekkefølgen:

1. Header

Den første linjen i filen. Starter alltid med %PDF- etterfulgt av et versjonsnummer:

%PDF-1.7

Versjoner spenner fra 1.0 (utgitt 1993) til 2.0 (utgitt 2017, gjeldende). Headeren etterfølges av en kommentarlinje med binære bytes som signaliserer til FTP og andre transportverktøy at dette er en binærfil.

2. Body - Indirekte objekter

Hoveddelen av filen. Hver side, font, bilde, annotasjon og skjema-felt er et nummerert indirekte objekt:

1 0 obj
<< /Type /Catalog /Pages 2 0 R >>
endobj
 
2 0 obj
<< /Type /Pages /Kids [3 0 R] /Count 1 >>
endobj
 
3 0 obj
<< /Type /Page /Parent 2 0 R /Contents 4 0 R /Resources << ... >> >>
endobj

Hvert objekt har en ID (nummeret før 0 obj), et generasjonsnummer (0, brukt for inkrementelle oppdateringer), og en nyttelast mellom << og >> for ordbøker eller stream og endstream for binære strømmer (bildedata, fontdata, komprimert innhold).

Objekter refererer til hverandre med syntaksen <id> <gen> R (f.eks. 3 0 R betyr "objekt 3, generasjon 0"). Slik refererer en side til fonten den bruker, eller hvordan en katalog refererer til roten av sidesettet.

3. Kryssreferansetabell (xref)

En byte-offset oppslagstabell. For hvert objekt i bodyen, registrerer xref den absolutte byteposisjonen i filen:

xref
0 6
0000000000 65535 f
0000000017 00000 n
0000000089 00000 n
0000000172 00000 n
0000000299 00000 n
0000000453 00000 n

Dette er det som gjør PDF-er tilfeldig tilgjengelige. En seer kan lese xref, hoppe direkte til byte-offset for objekt 3, og gjengi den siden uten å parse resten av filen. Det er grunnen til at PDF-er av et enkelt kapittel åpnes umiddelbart selv når kilde-filen er 500 sider.

4. Trailer

Den siste delen. Forteller parseren hvor den skal finne xref og hvilket objekt som er roten:

trailer
<< /Size 6 /Root 1 0 R /Info 7 0 R >>
startxref
1893
%%EOF

startxref-verdien er byte-offset for xref-tabellen. %%EOF-markøren er den bokstavelige slutten på filen. Trailere er det som gjør inkrementelle oppdateringer mulig: å legge til en ny xref + trailer på slutten lar deg legge til objekter uten å skrive om hele filen.

De seks innholdslagene

Inni bodyen lagres innholdet på tvers av seks lagtyper. Hver gjengitte PDF-side er en sammensetning av disse lagene:

1. Tekst

Glyf-posisjonskommandoer og fontreferanser, ikke tekststrenger. En PDF lagrer instruksjoner som "tegn glyf 42 fra font F3 på posisjon (120, 540)" i stedet for "tegn bokstaven A her." Dette er grunnen til at tekst er valgbar og søkbar: seeren revers-mapper glyf-ID-er til Unicode-kodepunkter via en ToUnicode-mapping (eller en CMap for CJK-fonter).

Når tekst mangler en ToUnicode-mapping, får du det klassiske problemet med "PDF med valgbar tekst som kopieres som søppel." Teksten er synlig, men glyf-til-Unicode-mappingen er ødelagt eller fraværende.

2. Bilder

Lagret som innebygde strømmer i ett av flere formater:

JPEG (DCTDecode filter): fotografier, vanligst
JPEG2000 (JPXDecode): høyere komprimering, mindre vanlig
PNG-lignende (FlateDecode + Predictor): skjermbilder, strektegninger
CCITT Group 4 (CCITTFaxDecode): svart-hvitt skannede tekster, brukt i arkivskanninger
JBIG2 (JBIG2Decode): to-nivå bilder, vanlig i OCR-ede dokumenter

Bilder kan nedskaleres, rekomprimeres eller erstattes uten å påvirke annet innhold.

3. Fonter

Innebygd som fulle fontprogrammer, delsett (kun brukte glyfer inkludert), eller referert ved navn (må være installert på seerens system). Delsett er standard - det kutter filstørrelsen dramatisk. Støttede fontformater: Type1, TrueType, OpenType og CIDFont (for CJK).

Når en font er referert, men ikke innebygd og ikke installert på seerens system, erstatter seeren en lignende font - noe som vanligvis ser feil ut. PDF/A krever at alle fonter er innebygd for å forhindre dette.

4. Annotasjoner

Høydepunkter, kommentarer, lenker, stempler, vannmerker og skjema-felt er alle annotasjoner. De legges over sideinnholdet og kan legges til, redigeres eller fjernes uten å endre den underliggende siden.

Skjema-felt er et spesialtilfelle: en interaktiv widget-annotasjon (den synlige delen) pluss en felt-ordbok (datadelen). Når du fyller ut et skjema og lagrer, endres kun felt-ordbøkene - selve siden er uberørt.

5. Vektorgrafikk

Linjer, former, kurver og baner tegnet med PostScript-lignende operatorer (moveto, lineto, curveto). Skalerer uendelig uten kvalitetstap. De fleste CAD-eksport, diagrammer og illustrasjoner i PDF-er er vektorgrafikk.

6. Digitale signaturer

PKI-baserte signaturer knyttet til byte-områder av filen. Signatur-ordboken spesifiserer "bytes 0 til 12 547 og 14 200 til slutten av filen er signert" - et lite område i midten er reservert for selve signaturverdien. Enhver endring i de signerte byte-områdene ugyldiggjør signaturen, noe som er hvordan PDF oppdager tukling etter signering.

Noen PDF-er har flere signaturer, lagt som inkrementelle oppdateringer - hver signatar signerer filen slik den eksisterte da de mottok den, og bevarer kjeden.

Metadata: To parallelle systemer

PDF har to metadatasystemer som ofte er uenige:

Standard /Info-ordbok

Lagret i traileren. Felt: Title, Author, Subject, Keywords, Creator (appen brukeren opprettet dokumentet i), Producer (appen som genererte PDF-en), CreationDate, ModDate. Klartekststrenger, lett å lese med ethvert PDF-verktøy.

XMP Metadata Stream

En separat XML-strøm (Adobe XMP, basert på RDF/XML) som støtter rikere skjemaer: Dublin Core, IPTC, egendefinerte domenespesifikke skjemaer (fargeprofiler, copyright-registreringer, manuskriptversjonering).

Moderne PDF-generatorer skriver til begge. Gamle PDF-er har kun /Info. Noen PDF-er har utdatert /Info fra en tidligere versjon og nøyaktig XMP fra en nylig redigering - eller omvendt. Ved revisjon av PDF-er for samsvar eller rettsmedisin, sjekk begge.

ISO-standarder bygget på PDF

Grunnsspesifikasjonen for PDF er ISO 32000. Flere avledede standarder begrenser PDF for spesifikke bruksområder:

Standard	Bruk	Begrensninger
PDF/A	Langtidsarkivering	Alle fonter innebygd, ingen JavaScript, ingen lyd/video, fargerom enhetsuavhengige. Samsvarsnivåer: PDF/A-1, A-2, A-3 (tillater filvedlegg)
PDF/X	Printproduksjon	CMYK-farge, innebygde fonter og fargeprofiler, ingen gjennomsiktighet (PDF/X-1a) eller kontrollert gjennomsiktighet (PDF/X-4)
PDF/UA	Tilgjengelighet	Merket strukturtre, språkmetadata, alt-tekst for bilder, logisk leserekkefølge
PDF/E	Ingeniørfag	3D-modeller (U3D, PRC-formater), CAD-spesifikke metadata
PDF/VT	Variabel transaksjonell utskrift	Optimalisert for personlige utskrifter i stort volum

En PDF kan samsvare med flere standarder samtidig - PDF/A-2u (arkivering med Unicode-mapping) pluss PDF/UA (tilgjengelighet) er vanlig for offentlige og juridiske arkiver.

Lineariserte PDF-er (Web-optimaliserte)

En "linearisert" eller "web-optimalisert" PDF omorganiserer bodyen slik at objektene for den første siden vises tidlig i filen. En nettleser kan gjengi side 1 etter å ha lastet ned bare de første ~50 KB i stedet for å vente på hele filen. Traileren dupliseres foran, pluss en hint-tabell som forteller seeren hvor hver side starter.

De fleste moderne PDF-generatorer støtter linearisering som et "Lagre for web"-alternativ. Formatet legger til 2-5% til filstørrelsen i bytte mot rask gjengivelse av første side over trege forbindelser.

Kryptering og tillatelser

PDF-er kan krypteres med et passord (eller sertifikater) og gis granulære tillatelser: skrive ut, kopiere tekst, endre, fylle ut skjemaer, trekke ut for tilgjengelighet. Krypteringen lagres i trailerens /Encrypt-ordbok.

Krypteringsstyrker har utviklet seg: RC4 40-bit (tidlige PDF-er, trivielt knekt i dag), RC4 128-bit (fortsatt svak), AES-128, AES-256. Den opprinnelige Acrobat 5 RC4-implementasjonen ble offentlig knekt i 2001; moderne PDF-kryptering (AES-256, PDF 2.0) er solid når den brukes med sterke passord.

Merk: "Tillatelser" er rådgivende. En seer som respekterer dem, vil håndheve dem. En seer som ignorerer dem (eller et verktøy som fjerner krypteringen) gjør ikke det.

Slik leser PDFSub PDF-er

PDFSub behandler PDF-er ved hjelp av Rusts PDFium-binding (samme motor som driver Chromiums PDF-seer) pluss PaddleOCR for skannede dokumenter. For full arkitekturdetaljer og en sammenligning med skybaserte verktøy, se Nettleser vs Sky PDF-sikkerhet.

For å konvertere PDF-er til andre formater mens strukturen beskrevet ovenfor bevares:

PDF til Excel - trekker ut tekst + tabeller, bevarer koordinater
OCR PDF - legger til et søkbart tekstlag til skannede PDF-er
PDF til Word - omflyter tekst til redigerbare avsnitt
Komprimer PDF - nedskalerer bilder, delsett fonter

For arkiveringsarbeidsflyter spesifikt, se Slik konverterer du PDF til PDF/A.

Videre lesning

ISO 32000-2 (PDF 2.0-spesifikasjon) - autoritativ referanse, betalingsmur
Adobe PDF Reference Archives - gratis referanse for PDF 1.7
PDF Association - bransjearbeidsgruppe, gratis artikler og samsvarstestfiler

For PDF-spesifikke emner: PDF Compliance Guide for Lawyers, PDF/A Konverteringsveiledning.