標準版圖

Spec: ISO 32000-2 Spec: ETSI EN 319 142-1 Spec: RFC 3161 Spec: WCAG 2.2 Evidence: Standard-backed

一覽

PDF 引擎並不是只對單一文件負責；它還要面對一小組由不同機構撰寫、彼此交互引用的標準聯邦。本頁就是 NextPDF 所追蹤的那個聯邦地圖，也是一條條款從「某標準如此規定」走到「引擎如此實作，並有測試證明」的路徑。

本頁寫給資深工程師：你需要先知道是哪一份文件在規範某項行為，再判斷 NextPDF 對它的解讀是否站得住腳。

為何重要

「支援 PDF」這項主張背後藏著一個問題：到底支援的是什麼？核心語法由 ISO 32000-2 規範，簽章經由 ETSI 路由，時間戳記是一套 IETF 協定，引擎所算繪的 HTML 與 CSS 屬於 W3C，底層密碼學則屬於 NIST；輸出的無障礙性又回到 W3C。

如果一套程式庫把這些都視為無從區分的一整團，你就無法針對某次失敗進行推理。當驗證器拒絕一份已簽署的發票時，最有用的第一個問題不是「這份 PDF 是不是壞了」，而是「沒被滿足的是哪一份標準的哪一條款，又是哪一方的問題」。要提出這個問題，你需要一張為各機構命名的地圖，以及一份誠實說明條款如何成為行為的記述。

簡短版本

NextPDF 追蹤五個標準機構。ISO 擁有格式本身。ETSI 擁有歐洲的簽章設定檔。IETF 擁有線路協定（時間戳記，以及以引用方式納入的密碼學原語）。W3C 擁有 HTML、CSS 與無障礙準則。NIST 擁有經核可的密碼學演算法。
這些文件構成的是軌跡，而不是清單：單一項已簽署 PDF 能力會依序走過 ISO → ETSI → IETF → NIST，每一層都以規範方式引用下一層。
條款不會只因被讀過就變成行為；它必須透過改寫並引用、對應到需求、實作、再以測試釘住才會成為行為。描述該行為的頁面會依其證據等級如實標明。
凡屬強制的條款都會帶有規範關鍵字（一個 shall、一個 must）。NextPDF 把那些關鍵字視為契約。至於 should，它會將其記載為建議，而非保證。

NextPDF 的處理方式

是聯邦，而非一團整體

ISO 32000-2 是核心。它定義何謂相容檔案。相容檔案必須遵守該文件的每一項需求，同時可自由省略該文件未明確要求的任何功能 Spec: ISO 32000-2, §6 。它同時也對寫入方訂下義務：NextPDF 在檔案中建立或修改的任何內容，都必須符合格式，並與既有元素保持一致 Spec: ISO 32000-2, §6 。正是這一條款，使得引擎拒絕產出結構不一致的增量更新。這不是 NextPDF 的偏好，而是格式本身的規則。

從這個核心出發，ISO 32000-2 向外指引。它的簽章處理是以「引用方式」定義，指向用於 PAdES 的 ETSI EN 319 142 系列。ETSI 接著為時間戳記權杖引用 IETF RFC 3161，並為雜湊與簽章演算法引用 NIST FIPS 系列。因此，一項能力其實是一條穿越數份文件的路徑，每一份文件在各自層級上都是規範性的。

Step 1 of 5: ISO 32000-2 §12.8 signatures
Step 2 of 5: ETSI EN 319 142-1 PAdES baseline
Step 3 of 5: RFC 3161 timestamp token
Step 4 of 5: NIST FIPS 180-4 hash strength
Step 5 of 5: WCAG 2.2 tagged output

單一份可長期驗證的已簽署 PDF 所經過的標準軌跡：ISO 定義容器並指向 ETSI 取得簽章設定檔；ETSI 要求一個 IETF 時間戳記；密碼學原語經 NIST 核可；算繪輸出則受 W3C 無障礙標準約束。每一個箭頭都是一項規範性引用，而非鬆散的關聯。

條款如何成為行為

在標準工作中，危險的作法是讀完某條款後就憑記憶寫程式。NextPDF 刻意採取較長的路徑，因為那才是你能稽核的路徑：

Retrieve The clause is read from the standard, not from memory.
Cite It is paraphrased and pinned with a chunk digest, never quoted.
Classify Its keyword (shall / should / may) sets whether it is a contract or a recommendation.
Map The obligation becomes a concrete engine requirement.
Implement The requirement is built into the pipeline.
Pin A test holds the behaviour against drift.
Tag The page that describes it declares its evidence level.

從規範條款到經過測試的引擎行為的路徑：取得並引用該條款、依其規範關鍵字將其義務分類、對應到引擎需求、實作、以測試釘住，再為記載頁面標上其證據依據。一條在測試之前就止步的條款，只是主張，而非行為。

「分類」這一步，正是多數模稜兩可之處被釐清的地方。規格以關鍵字編碼其需求等級：也就是眾所周知的 MUST、SHALL、SHOULD、MAY 這一家族。這些關鍵字的意義由 IETF 需求關鍵字慣例固定，並經更新以釐清只有大寫形式才具規範性，再層疊於各規格的描述性文字之上 Spec: RFC 2119 Spec: RFC 8174 。 NextPDF 把 shall 讀作引擎絕不跨越的硬性邊界；把 should 讀作它會遵循、並以建議形式記載的建議，絕不當作承諾。這項區分，正是誠實的能力陳述與過度宣稱之間的差別。

相容性是分級的，而非二元的

「相容」很少只是一個位元。簽章標準是分級的；舉例來說，歐洲的「長期含封存」設定檔正是為了加入時間戳記權杖而存在，讓簽章在建立後很久仍可驗證 Spec: ETSI EN 319 122-1, §6 。這是一項比僅有基準簽章嚴格得多的主張。無障礙標準也是同樣的形態：唯有滿足某等級的每一項成功準則，才算達到該相容等級，而一項主張須陳述其實際達到的等級 Spec: WCAG 2.2, §5.2.1 。因此 NextPDF 會陳述設定檔與等級，而非未經限定的「相容」。

證據怎麼說

本頁屬於 Evidence: Standard-backed ：每一項主張都錨定到某條款、經過改寫，並附上摘要引用，讓下一位審查者能對照原始來源重新驗證。

層級	機構	錨定條款（改寫）	在 NextPDF 中規範什麼
格式	ISO	寫入方所建立或修改的元素必須相容並保持一致 Spec: ISO 32000-2, §6	引擎產出的 PDF
相容性	ISO	相容檔案須滿足所有需求；額外功能為選用 Spec: ISO 32000-2, §6	「有效輸出」的意義
簽章設定檔	ETSI	「長期含封存」等級加入時間戳記，供日後驗證 Spec: ETSI EN 319 122-1, §6	簽章所鎖定的 PAdES 設定檔
可信時間	IETF	時間戳記服務證明某項資料在某一時間之前即已存在 Spec: RFC 3161, §2	文件時間戳記權杖
密碼學	NIST	經核可的雜湊在所賦予的安全強度上各有不同 Spec: NIST FIPS 180-4, §1	簽章所依賴的摘要演算法
輸出存取	W3C	某相容等級要求滿足該等級的每一項準則 Spec: WCAG 2.2, §5.2.1	針對算繪 PDF 的無障礙主張

引用摘要記錄在本頁的 citations frontmatter 中。此處並未重現任何標準的原文。規範該選擇的規則本身也是一個頁面。請參閱引用紀律。

實際範例

你不會去「執行」標準版圖；你會閱讀它，藉此決定要向引擎要求什麼。具體而言，一次可長期驗證的簽署呼叫，就是在陳述你需要軌跡上的哪一個點：

<?php

declare(strict_types=1);

use NextPDF\Core\Document;
use NextPDF\Security\Signature\CertificateInfo;
use NextPDF\Security\Signature\DigitalSigner;
use NextPDF\Security\Signature\SignatureLevel;

// The signature level is a coordinate on the ISO -> ETSI -> RFC trail.
// PAdES B-B is the ETSI baseline CMS SignedData the Core engine produces;
// B-T adds an RFC 3161 timestamp, and B-LT/B-LTA add the DSS and document
// timestamps that keep a signature validatable after the certificate
// expires. The level you name is the point on the trail you are asking for.
$certInfo = CertificateInfo::fromFiles(
    certPath: 'signer-cert.pem',
    keyPath: 'signer-key.pem',
);

// The functional signing path is the direct two-phase signing engine.
// (Document::setSignature() records intent but its writer seam is not yet
// wired and fail-fasts on output — see the PadesOrchestrator docblock.)
$signer = new DigitalSigner(
    certInfo: $certInfo,
    level: SignatureLevel::PAdES_B_B,
);

$result = $signer->sign(file_get_contents('agreement.pdf'));

printf(
    "PAdES %s CMS: %d bytes, timestamp=%s\n",
    SignatureLevel::PAdES_B_B->value,
    $result->getSize(),
    $result->hasTimestamp() ? 'yes' : 'no',
);

指定 PAdES_B_LTA 而非僅指定基準，並不是一個效能旋鈕。它是一項決定：義務要沿標準軌跡延伸到多深。B-LT 與 B-LTA 會拉入 DSS 與封存時間戳記層，並在執行階段需要企業版 LTV 套件。引擎不會默默降級，而是拒絕假裝較低的等級能交付較高的等級。

常見誤解

陷阱在於把「NextPDF 符合標準」讀成單一、全面的保證。事實並非如此，任何誠實的引擎也都不會這樣承諾。相容性是逐標準、逐條款、逐等級而論的。NextPDF 鎖定 PDF 2.0 基準、具名的 PAdES 設定檔，以及所陳述的無障礙等級；每一項都有範圍，每一項都有引用。一項缺少條款與等級支撐的主張只是行銷，而 Insider_ 不會刊出它。

第二個更隱微的陷阱，是把規範性的 should 當成承諾。這是一項建議。NextPDF 會把建議記載為建議。引擎的保證是由 shall 條款建構而成，而這項差別關鍵且不可省略。

限制與邊界

本頁是地圖，而非疆域本身。它並未列舉 NextPDF 實作的每一條款，也不是一份相容性證書。逐項行為的證明存在於該行為所屬的主題頁面上，並帶有該頁面自身的證據等級；例如格式差異請見 PDF 2.0：有何變動。

標準版圖也會變動：新版本會推出，引用也會被重新指向。此處所引用的條款，固定於本頁 citations 中所記錄的語料快照。當上游標準改版時，引用會對照新條款重新驗證，而非逕自假設沿用。凡本頁提及進階版（Premium）等級的能力，都只在它對應哪一份標準的層級上描述，絕不觸及內部機制的層級。

詞彙表

標準機構——發布規格的組織（ISO、ETSI、IETF、W3C、NIST）。各自擁有 PDF 堆疊中的不同層級。
規範條款——標準中的一項需求，並以其關鍵字標示（shall/must 表強制，should 表建議，may 表選用）。
標準軌跡——單一能力所經過、有序的規格鏈，其中每份文件都以規範方式引用下一份。
相容等級——分級的相容階層（ETSI 基準設定檔、WCAG 等級）。一項主張會陳述實際達到的等級，而非未經限定的「相容」。
PAdES——PDF 進階電子簽章（PDF Advanced Electronic Signatures），即 ETSI EN 319 142 系列的簽章設定檔，ISO 32000-2 引用它來進行 PDF 簽署。