跳到內容
getnextpdf.com

可以交給稽核人員的符合性

Spec: ISO 19005-4 (PDF/A-4)Spec: ISO 32000-2Spec: ETSI EN 319 142-1Spec: EN 16931-1

稽核人員不想聽到一份文件「符合規範」這句話。他們想拿到的是兩樣東西:那份文件,以及一份檢核結果來如此宣告。本頁談的,就是如何用 NextPDF 把這兩樣都產出來——符合規範的輸出,以及一份你能擺到提問者面前的驗證結果。

開源核心會產生封存用的 PDF/A 輸出與 PAdES 基準簽章,並驗證符合性——PDF/A、PDF/UA 與簽章。進階版本則把觸及範圍延伸到長期驗證與電子發票。自始至終,一條原則不變:符合性是檢核工具的裁定,而不是產生器可以自行給出的承諾。

符合性工作有個破綻。有人說「對,它符合規範」,接著全場便陷入沉默,因為沒有人能拿出證明它的那樣東西。文件看起來沒問題。函式庫信譽良好。但這些都不是證據。

這道落差的代價並不對等。一份僅僅看似符合規範的檔案,今天通過了審查,幾個月後卻在某次外部檢核中失敗——在稅務機關、在長期封存庫中,或是在法庭上——此時原始情境已不復存在,要解釋失敗的代價也變得高昂。標準正是為此預作準備。一份 PDF/A 檔案會在其中繼資料裡記錄它的目標設定檔,但那項標識說明的是產生器的意圖;符合性的判定,是由產生軟體之外的一道驗證程序所做出的(Spec: ISO 19005-4 (PDF/A-4), §6.7.3)。格式本身就告訴你:產生器並不擁有最終發言權。

  • 你既能產生符合規範的輸出,也能取得一份宣告它符合的結果。 那不是一項主張——而是一件產物加上一道檢核。
  • 核心涵蓋常見情境。 它產生 PDF/A 封存輸出與 PAdES B-B / B-T 簽章,並為 PDF/A、PDF/UA 與簽章驗證符合性。
  • 符合性是驗證器的裁定,並界定於某個標準、條款與層級。 NextPDF 會載明它所鎖定的設定檔與層級,絕不給出未經限定的「符合規範」(Spec: ETSI EN 319 142-1, §6.1)。
  • 進階版本延伸觸及範圍。 長期驗證(PAdES B-LT / B-LTA)與電子發票(ZUGFeRD / Factur-X,對照 EN 16931)屬於商業層級的能力。
  • 引擎拒絕偽造裁定。 它產生一份候選檔並執行檢核;它絕不會憑自身權威把一份檔案標記為符合規範。

這套做法是一道乾淨的區隔,並處處套用:產生某個標準所定義的產物,是一種能力;裁定該產物符合規範,則是一項裁定。NextPDF 給你前者,並讓你從一個檢核工具取得後者。它絕不混淆兩者。

正是這道區隔,讓輸出成為「可以交出去」的東西。簽章是最清楚的例子。它的值是針對一段刻意排除簽章本身的所載明位元組範圍計算出來的(Spec: ISO 32000-2, §12.8),這正是為什麼有效性是第三方能從檔案重新計算出來、而非只能憑信任接受的東西。產生器的工作是把那個結構寫對。驗證器的工作是加以確認。兩種工作、兩方人馬,而第二方才是稽核人員所信任的那一方。

所以你交出去的工作流程有四個步驟,而第三步正是把「應當符合」轉為「確實符合」的那一步。

  1. Produce a candidateGenerate PDF/A archival output or a PAdES signature with the conformance-relevant structure in place — embedded fonts, declared profile, a signature over a correct byte range.
  2. Refuse the impossibleThe engine rejects conformance-breaking combinations (an encrypted PDF/A, a signature level it cannot honor) rather than emitting a file that silently does not conform.
  3. Validate independentlyRun a conformance checker — PDF/A, PDF/UA, signature. A passing report is the evidence; the producing library is not.
  4. Hand over bothGive the auditor the document and the validation result together. The verdict travels with the artifact.
從義務到證據:NextPDF 產生一份符合規範的候選檔並拒絕會破壞符合性的操作,由獨立的驗證器交出裁定,而那份報告——而非產生它的函式庫——才是你交給稽核人員的東西。

中間那一步並非裝飾。當封存模式開啟,又有人嘗試一項不相容的操作時——例如開啟加密——引擎會丟出一個具型別的錯誤,而不是把檔案降級成一份不符合規範的「封存」文件。大聲拒絕,正是讓候選檔保持夠誠實、能通過後續檢核的關鍵。

而那道檢核是分級的,從來不是單一位元。PAdES 在設計上就是分層的:B-B、B-T、B-LT 與 B-LTA,每一層都在前一層之上再添加內容(Spec: ETSI EN 319 142-1, §6.1)。一個 B-T 簽章帶有一個 B-B 所沒有的受信任時間戳記。一項指名層級的宣稱是誠實的宣稱;一句空泛的「已簽署」則不是。NextPDF 要求你指名層級,因此你交出去的結果,恰恰說明了實際達成了什麼。

一個簡短而完整的形態。它產生一份候選檔、加以驗證,並把驗證器的答案當成證據——絕不是那個產生用的呼叫。

<?php
declare(strict_types=1);
use NextPDF\Contracts\PdfDocumentInterface;
use NextPDF\Conformance\ConformanceValidator;
use NextPDF\Conformance\ConformanceTarget;
use NextPDF\Conformance\ValidationReport;
/**
* Produce a candidate, then prove it with an independent check.
*
* The producing call returns bytes that SHOULD conform. Only the
* validator's report turns "should" into something an auditor accepts.
*
* @param PdfDocumentInterface $candidate A document composed for archival
* (fonts embedded, profile declared)
*/
function archivalEvidence(
PdfDocumentInterface $candidate,
ConformanceValidator $validator,
): ValidationReport {
// 1. The producing call states intent; it does not certify.
$bytes = $candidate->getPdfData();
// 2. The check is the verdict. Conformance is decided here, by the
// validator, against the named target — not by the line above.
$report = $validator->validate($bytes, ConformanceTarget::PdfA);
// 3. Hand BOTH over: the bytes plus the report. The report names the
// target, the level, and every requirement that was checked.
return $report;
}

變數命名為 $candidate 是刻意的,而報告作為回傳值也是刻意的。文件是你所產生的東西;報告則是證明它的東西。稽核人員要求你示範符合性——所以你給他們的是那場示範,而不是產生器的一面之詞。

那個讓封存庫塞滿未被保存的檔案、讓收件匣塞滿被退回發票的誤解很簡單:「函式庫說它是 PDF/A,所以這份檔案就是 PDF/A。」 這個裁定並非函式庫所能給予。一個產生器可以產出一份意圖符合規範的檔案,卻仍然漏掉某項規範性要求;唯有一道驗證程序,才能把意圖變成判定。把產生用的呼叫當成證明,是這裡的核心錯誤,而這也正是稽核人員受過訓練要抓出來的錯誤。

第二個更隱微的陷阱,是把「NextPDF 符合標準」聽成一句總括的保證。並沒有這種東西,任何誠實的引擎也不會提供它。符合性是按標準、按條款、按層級而論的。正確的宣稱會指名是哪一個設定檔、哪一個層級,並出示那道檢核。一句缺少這些的宣稱只是行銷話術,而 Insider_ 不會把它印出來。

  • NextPDF 產生一份符合規範的候選檔並加以驗證;它不認證符合性。 驗證器的報告才是證據。產生用的函式庫絕不會核發自己的證書。
  • 驗證是一項檢核工具的結果,而非絕對保證。 一次乾淨的執行,意味著該檔案符合了驗證器所檢核的各項要求,對照的是它所實作的那一版標準。它是現有最強的證據,而非形上學意義上的證明。
  • 核心的觸及範圍是 PDF/A 封存輸出與 PAdES B-B / B-T 簽章,外加 PDF/A、PDF/UA 與簽章的符合性驗證。 它不會暗中提供進階版本的能力。
  • 長期驗證(B-LT / B-LTA)與電子發票(ZUGFeRD / Factur-X,對照 EN 16931)屬於進階版本的能力。 EN 16931-1 定義了載體所對照驗證的語意發票模型(Spec: EN 16931-1, Scope);履行它屬於商業層級,而非核心。
  • 法律效力是與技術符合性分開的另一個問題。 一個簽章在某個司法管轄區是否具法律充分性,是由法律與受理機關裁定的,而非由驗證器裁定。NextPDF 談的是技術結果;其法律分量,由你的合規團隊來談。
Conformance reach across editions — edition availability
EditionAvailability
Core

產生 PDF/A 封存輸出與 PAdES B-B / B-T 簽章,並為 PDF/A、PDF/UA 與簽章驗證符合性。輸出與驗證結果兩者皆可交出。

Pro

新增長期驗證——PAdES B-LT / B-LTA——內嵌撤銷證據與文件時間戳記,讓簽章在憑證到期後仍可驗證。

Enterprise

新增電子發票(ZUGFeRD / Factur-X,對照 EN 16931)以及一套結構化的符合性政策與報告——仍然是一道結構檢核,最終判定屬於驗證器與你的合規團隊。

更深入的符合性工具,以及每一項進階版本能力所引用的符合性邊界,都收錄於符合性與一致性頁面。當你需要執行那道檢核時,PDF/A 與 PDF/UA 驗證疑難排解指南會帶你逐步閱讀並修正一份失敗的報告。

  • 封存與 PDF/A——PDF/A 保證什麼,以及為什麼證明符合性是與產生它分開的另一項工作。
  • 正確驗證簽章——「簽章有效」背後的完整檢核項目。
  • 標準全貌——標準制定機構的地圖,以及一條條款如何成為受測行為。
  • PAdES 基準設定檔——把 B-B、B-T、B-LT 與 B-LTA 視為一段遞進,以及如何挑選你的義務所需的層級。
  • 發票與電子發票——對照 EN 16931 的混合式 PDF/結構化資料發票,從頭到尾。
  • 符合性(Conformance)——一份檔案與某標準規範性要求之間的一致,由一道驗證程序所判定,並界定於某個特定標準、條款與層級。
  • 候選檔(Candidate)——一份意圖符合規範而產出的檔案,尚待獨立驗證器確認其確實符合。
  • 驗證器/符合性檢核工具(Validator / conformance checker)——獨立軟體,依某標準的要求評斷一份檔案,並產出稽核人員所倚賴的結果。
  • PDF/A——ISO 19005 系列:一套用於長期保存的受限 PDF 設定檔,設計用以隨時間重現一份文件的靜態外觀。
  • PDF/UA——ISO 14289 系列:可及性設定檔,定義一份標記化 PDF 如何把結構傳達給輔助技術。
  • PAdES——PDF Advanced Electronic Signatures,ETSI EN 319 142 系列的簽章設定檔(B-B、B-T、B-LT、B-LTA),ISO 32000-2 在 PDF 簽署中引用它。
  • EN 16931——歐洲標準,定義一份核心電子發票的語意資料模型,是混合式電子發票載體所對照檢核的義務。