Một PDF hoặc đạt PDF/A-3, hoặc không đạt. Vậy tại sao phải chạy cùng một file qua hai validator?

Câu trả lời thực tế là: đặc tả PDF/A đủ lớn để hai implementation đúng vẫn có thể khác nhau ở edge case. Trong workflow cần audit, một kết quả “Pass” từ một engine chỉ là đèn vàng, không phải đèn xanh.

PDF/A không phải một thuật toán đơn giản

PDF/A nằm trong nhiều phần của ISO 19005: PDF/A-1, PDF/A-2, PDF/A-3, PDF/A-4, cùng các mức b, a, u, e, f. Bên dưới còn có đặc tả PDF gốc ISO 32000. Tổng bề mặt quy tắc là hàng nghìn trang.

Các điểm dễ lệch:

Transparency trong PDF/A-2/3: được phép trong điều kiện cụ thể, nhưng ranh giới điều kiện có thể được diễn giải khác nhau.
ICC color profile: bắt buộc hay chỉ khuyến nghị, mỗi engine có thể nghiêm khác nhau.
Metadata file đính kèm trong PDF/A-3: AFRelationship, tham chiếu /AF và XMP phải khớp.
Font subsetting: CID font và subset một phần thường tạo edge case.

Đây không nhất thiết là bug. Đó là kết quả tự nhiên khi một chuẩn phức tạp được các nhóm độc lập triển khai. Vì vậy các ngành chịu quản lý thường yêu cầu xác nhận độc lập thứ hai.

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

veraPDF là implementation tham chiếu do PDF Association duy trì. Nếu veraPDF báo “Pass”, đó là tín hiệu single-engine mạnh nhất cho PDF/A.

Nhưng tín hiệu đơn lẻ mạnh nhất vẫn chưa phải bằng chứng audit. Ngân hàng, kho hồ sơ y tế, cơ quan nhà nước và hệ thống lưu trữ dài hạn thường yêu cầu engine thứ hai vì:

Bên nhận có thể dùng validator khác.
Bug trong một engine không thể phát hiện bằng cách chạy lại chính engine đó.
Hai xác nhận độc lập là nguyên tắc quen thuộc trong compliance.

gPdf chạy veraPDF cùng engine riêng viết bằng Rust + WebAssembly. Đây là implementation độc lập của cùng specification. Nếu cả hai pass, kết luận mạnh hơn nhiều; nếu lệch nhau, bạn có điểm bắt đầu rõ ràng để điều tra.

Hai báo cáo trong một URL

Workflow này miễn phí tại gpdf.com/validator/. Không cần đăng nhập: upload file, veraPDF và gPdf edge engine chạy song song, rồi trả hai report cạnh nhau.

Các cách dùng phổ biến:

Trước khi giao PDF/A: upload, kiểm tra hai “Pass”, lưu JSON report làm QA evidence.
Một engine pass, một engine fail: so sánh report; thường vấn đề nằm ở XMP, tham chiếu /AF hoặc metadata attachment.
Cả hai fail: sửa ở nguồn sinh PDF.
Audit batch lưu trữ: validate mẫu ngẫu nhiên và đính kèm kết quả vào hồ sơ audit.

File không được lưu lại. Nó được xử lý in-memory trên Cloudflare Workers và bị loại bỏ sau khi report được tạo.

E-invoice cũng cần cách nghĩ này

Với Factur-X / ZUGFeRD, không chỉ kiểm tra PDF/A-3 shell; XML CII EN 16931 nhúng bên trong cũng phải được validate. gPdf validator dùng Mustang cho phần XML và hiển thị kết quả cùng report PDF/A.

Đây không phải chuyện không tin một công cụ, mà là xây bằng chứng bằng các implementation độc lập.

TL;DR

“Pass” từ một engine là đèn vàng. Hai “Pass” độc lập là bằng chứng mạnh hơn nhiều. Dùng validator, lấy hai report và gắn vào QA hoặc audit. Nếu PDF được tạo bởi gPdf API, validator là biên nhận công khai cho claim compliance đó.