Một file PDF hoặc tuân thủ PDF/A-3, hoặc không. Vậy tại sao lại cần chạy hai validator trên cùng một file?

Câu trả lời ngắn: vì đặc tả đủ rộng để hai implementation đúng vẫn có thể khác nhau ở vùng biên, và một workflow đạt mức audit nên xem kết quả “Pass” từ một engine là đèn vàng, không phải đèn xanh. Dưới đây là phần giải thích đầy đủ.

PDF/A là một chồng quy tắc được diễn giải, không phải một thuật toán đơn

PDF/A được định nghĩa qua nhiều phần ISO 19005 (PDF/A-1, PDF/A-2, PDF/A-3, PDF/A-4), mỗi phần có các mức conformance phụ (b, a, u, e, f), và toàn bộ lại xây trên đặc tả PDF nền tảng (ISO 32000). Bề mặt kết hợp là vài nghìn trang văn bản chuẩn hóa.

Một vài ví dụ nơi các implementation tuân thủ từng khác nhau trong lịch sử:

Transparency trong PDF/A-2/3: được cho phép trong một số điều kiện cụ thể; các điều kiện được viết theo dạng thủ tục, và validator khác nhau có thể triển khai check khác nhau.
Embedded color profiles: khi nào ICC profile là “bắt buộc” thay vì “khuyến nghị”? Có validator từng gọi cùng một file là “Pass”, validator khác lại gọi là “Fail” ở trục này.
Embedded file metadata trong PDF/A-3: AFRelationship, tham chiếu /AF, XMP nhúng. Quy tắc được mô tả rõ, nhưng mức độ enforce có thể khác.
Font subsetting: PDF/A yêu cầu tất cả font được embed kèm encoding thực. Các edge case quanh CID-keyed fonts với partial subsets từng gây bất đồng giữa validator.

Đó không phải lỗi kỳ lạ. Đó là hệ quả tự nhiên của một đặc tả phức tạp được nhiều đội độc lập triển khai từ văn bản chuẩn hóa. Lập trường thận trọng, và cũng là lập trường của phần lớn ngành bị quản lý, là cần nhiều xác nhận độc lập.

Engine tham chiếu và ý kiến thứ hai

veraPDF là reference implementation do PDF Association duy trì, tức tổ chức tiêu chuẩn công bố PDF/A. Nó open-source, được các working group trong ngành audit, và rule set của nó là cách diễn giải canonical của văn bản ISO 19005. Nếu veraPDF nói “Pass”, đó là tín hiệu mạnh nhất bạn có thể lấy từ một engine đơn.

Nhưng “tín hiệu mạnh nhất từ một engine” không đồng nghĩa với “bằng chứng đủ qua audit”. Auditor tại các tổ chức bị quản lý như ngân hàng, kho lưu trữ hồ sơ y tế và cơ quan lưu trữ nhà nước thường yêu cầu một xác nhận độc lập thứ hai vì:

Cách veraPDF diễn giải một rule có thể khác validator nội bộ mà bên được audit đang dùng, dẫn tới downstream rejection.
Bug trong bất kỳ engine đơn nào, kể cả engine tham chiếu, không thể bị phát hiện bằng cách chạy lại chính engine đó.
Nguyên tắc procurement “hai xác nhận độc lập” được áp dụng rộng trong nhiều miền compliance; PDF/A thừa hưởng kỳ vọng đó từ các use case lưu trữ.

Engine thứ hai tùy thuộc vào công cụ bạn có:

Adobe Acrobat Preflight là công cụ trả phí và closed-source; tốt để xác nhận nhưng giới hạn khả năng re-verify độc lập.
callas pdfaPilot trả phí và là lựa chọn enterprise de-facto, nhưng cũng giới hạn người có thể kiểm tra lại.
Một engine open-source thứ hai: có một số lựa chọn, đa phần chưa đầy đủ bằng veraPDF.

Điều gPdf làm là xây một engine riêng bằng Rust + WebAssembly như một “independent re-implementation” có chủ đích: cùng đặc tả, cùng quy tắc, được viết từ đầu bởi một đội khác. Khi cả hai engine đều pass cùng một file, kết luận mạnh hơn rất nhiều so với từng engine riêng lẻ. Khi chúng bất đồng, bạn có một bug rõ để điều tra: trong một engine, hoặc trong file.

Validator đặt cả hai trên một URL

Chúng tôi host cả hai tại gpdf.com/validator/: miễn phí, không cần login, chạy file qua veraPDF VÀ engine Edge của chúng tôi song song, rồi trả hai report cạnh nhau. Các use case:

Bạn tạo một PDF/A và muốn gửi nó vào production: thả file vào validator, cả hai đều pass, gắn JSON reports vào bằng chứng QA. Xong.
Một engine fail, engine kia pass: bạn có một bug cụ thể. So sánh report, tìm field gây lỗi. Thường đó là chi tiết nhỏ như timestamp XMP lệch hoặc thiếu tham chiếu /AF trong PDF/A-3.
Cả hai đều fail: file thật sự hỏng; sửa từ nguồn.
Audit một batch archive đầu vào: lấy mẫu ngẫu nhiên PDF, lưu URL report, đính kèm vào work paper. “Chúng tôi đã xác thực bằng veraPDF và một engine độc lập” là claim mạnh hơn “chúng tôi chạy checker của vendor.”

File bạn upload không rời khỏi request: các engine chạy in-memory trên Cloudflare Workers và file bị loại bỏ sau khi report được render. Không login, không persistence, không quota.

Cùng một pattern, mở rộng ra ngoài PDF/A

Pattern “hai xác nhận độc lập” không chỉ dành cho PDF/A. Nó còn áp dụng cho:

Factur-X / ZUGFeRD e-invoice: gpdf.com/validator/ chạy Mustang (mustangproject.org) cho EN 16931 CII XML nhúng, song song với kiểm tra PDF/A ở trên. Bài Validating ZUGFeRD with Mustang — what passes, what fails nói chi tiết workflow đó.
TLS certificates: mọi CA log hiện đại đều được nhiều monitor cross-check.
Build reproducibility: hai rebuild độc lập từ cùng source nên tạo output byte-identical.

Thế giới compliance đã làm việc này hàng chục năm. PDF/A chỉ đang bắt kịp.

TL;DR

“Pass” từ một engine là đèn vàng. “Pass” từ hai engine là đèn xanh. Cả hai engine đều miễn phí tại validator: thả file vào, nhận hai report, gắn vào bằng chứng QA. Nếu file do gPdf tạo ra, validator là biên nhận public rằng API đã thực hiện đúng claim compliance.

Nếu bạn đang xây trên gPdf API, E-invoice API reference (§5) cho thấy cách emit trực tiếp Factur-X / ZUGFeRD PDF/A-3. Validator sau đó xác nhận bên ngoài. Hai engine, một upload: đó là pattern đạt mức audit.