Når bedriftssystemet ditt aksepterer PDF-er fra upålitelige eksterne kilder, er det å behandle hver innkommende fil identisk en oppskrift på ødelagte arbeidsflyter, sikkerhetshendelser og dårlig samsvar med tilgjengelighet. Dokumenter kan inneholde ondsinnede skript, mangle innebygde skrifttyper som kreves for utskrift, eller bestå utelukkende av skannede bilder som forhindrer tekstekstrahering.
For å trygt innta dokumenter, trenger du en automatisert inntaksrevisjon og preflight-fase. I denne artikkelen ser vi på hvordan du bygger en robust revisjonsrørledning ved hjelp av Delphi og PDFium-motoren for å klassifisere, validere og rute innkommende PDF-er.
Arkitekturen til en inntaksrevisjon
En inntaksrevisjon skiller seg fra gjengivelse. Det er en rask, hodeløs prosess som skanner dokumentets interne metadata, ordbøker og sidestrukturer for å generere en risikoprofil. Basert på denne profilen utleder systemet en "anbefalt handling" for filen.
En robust revisjonsrørledning bør se etter:
- Manglende skrifttypeinnbygging: Dokumenter som mangler innebygde skrifttyper, kan gjengis perfekt på oppretterens maskin, men ødelegges under utskrift på serversiden.
- Skannede versus tekstsider: Hvis sidene bare inneholder store bilder og ingen tekstobjekter, må de rutes til en OCR-kø (Optical Character Recognition).
- Samsvar med tilgjengelighet: Mangler skjemafelt verktøytips? Mangler dokumentet et logisk strukturtre (Tagged PDF)? Disse krever utbedring før publisering på nettet.
- Aktivt innhold: Eksterne URI-handlinger, innebygd JavaScript eller funksjoner som ikke støttes utgjør sikkerhetsrisikoer og bør utløse en karanteneprotokoll.
Utledning av handlinger i stedet for bare å rapportere risikoer
Et vanlig anti-mønster i revisjonsverktøy er ganske enkelt å dumpe en massiv JSON-fil med tekniske brudd (for eksempel "Warning: XRef stream malformed", "Info: Has JavaScript"). Mens det er nyttig for feilsøking, er dette forferdelig for automatisert batch-prosessering.
I stedet bør revisjonen utlede en anbefalt handling basert på et prioritert hierarki. For eksempel:
- Hvis dokumentet kaster et unntak ved innlasting eller har funksjoner som ikke støttes, er handlingen
quarantine. - Hvis dokumentet krever et passord for å åpne, er handlingen
request-password. - Hvis dokumentet er en ren skanning, er handlingen
run-ocr. - Hvis dokumentet mangler tilgjengelighetstagger, er handlingen
remediate-tags. - Hvis det ikke finnes noen store brudd, er handlingen
pass-through.
Ved å håndheve dette konservative hierarkiet, kan back-end-tjenestene dine ganske enkelt bytte på strengen for anbefalt handling for å bestemme hvilken mikrotjeneste som håndterer filen neste gang.
Utførelse av hodeløse revisjoner
Fordi inntaksrørledningen må behandle tusenvis av dokumenter, må revisjonslogikken være strengt hodeløs. Den bør ikke instansiere noen UI-komponenter, visningstilstander eller kreve en aktiv skjermkontekst.
Videre, når du kjører batchrevisjoner, må parametere som MaxPages eksplisitt sendes ned gjennom hvert lag av API-en. Å skanne et 10 000 siders dokument for skrifttype-delmengder kan bli en flaskehals for hele køen din; å begrense revisjonen til de første 50 sidene er ofte tilstrekkelig for å bestemme dokumentets generelle hygiene.
Til slutt, sørg for at utdataformatet ditt er konsistent. Enten du genererer en enkeltfil JSON-rapport eller en batch-aggregert CSV, må utdataskjemaet speile den interne revisjonsposten perfekt. Dette sikrer at automatiseringsskript nedstrøms aldri støter på semantisk glidning.
Merk: Omfattende inntaksrevisjon og tilgjengelighetssjekker er innebygde funksjoner i PDFium VCL Component.
\n