2026年8月27日
ASiC（Associated Signature Containers，關聯簽名容器）由 ETSI TS 102 918 標準定義，是一種基於 ZIP 的容器格式，將數碼簽名與被簽署的檔案及其支援材料打包進單個 .asics 或 .asice 檔案。它存在的意義在於：簽名與文件通常分離傳輸，一份孤立的簽名檔案在多年儲存後很容易遺失、錯配或無法驗證。使用 ASiC 後，數據、簽名，以及擴展形式下的清單、時間戳和證據記錄會一起傳輸，在傳遞和長期歸檔過程中始終可驗證。歐洲的公共行政部門、電子發票交換平台以及合規要求嚴格的團隊用得最多。單一數據對象選 ASiC-S；多檔案或需要更豐富證據鏈的場景選 ASiC-E。
甚麼是 ASiC 容器，它為甚麼存在？
一份分離式數碼簽名（detached signature）能保護文件的字節內容，但它不會隨文件一起走。一份合約和它的 .xml 或 .p7s 簽名檔案分散在不同的附件裏，被重新命名後放進不同文件夾，或在系統遷移時徹底分離。多年以後，驗證者面對的一邊是一堆沒有簽名的檔案，另一邊是無人認領的孤立簽名，沒有可靠的辦法證明哪個簽名屬於哪份文件。關於 ASiC 所包裝的簽名機制本身，可參閱數碼簽名在實際業務工作流程中如何運作。
ASiC 解決的就是這個打包問題。它由 ETSI TS 102 918 定義，並在 ETSI EN 319 162 系列標準中延續，把數據對象和簽名綁定進一個基於 ZIP 的檔案，使兩者的關聯不會因檔案系統的意外而斷開。容器不取代簽名，而是承載簽名，連同清單、時間戳和驗證證據一起，確保簽名在傳輸和長期儲存之後仍可驗證。
ASiC 容器的結構是怎樣的
ASiC 檔案就是一個普通的 ZIP 壓縮檔，只是遵循嚴格的約定。你可以用任何解壓工具開啟它，但其目錄佈局是標準化的，以便驗證軟件確定性地解析：
- mimetype：壓縮檔中的第一個條目，以未壓縮方式儲存，內容為
application/vnd.etsi.asic-s+zip或application/vnd.etsi.asic-e+zip。它向任何開啟該檔案的工具聲明容器類型。 - 數據對象：被簽署的檔案，存放在根目錄或
docs文件夾中，與簽署時的字節完全一致。 - META-INF/：元數據文件夾，存放簽名區塊——XAdES 簽名為
signatures.xml，CAdES 簽名為signatures.p7s——以及（如有）manifest.xml（列出每個數據對象及其摘要值）和timestamp.tst（RFC 3161 時間戳令牌）。
由於每個數據對象的摘要值要麼出現在簽名中，要麼出現在清單裏，簽署後改動任何一個字節都會導致驗證失敗——這正是歸檔所需要的防篡改特性。
ASiC-S 與 ASiC-E：該用哪種容器？
標準定義了兩個規格。ASiC-S（simple，簡單型）只包裝一個數據對象和一份分離式簽名；ASiC-E（extended，擴展型）可容納多個數據對象、多份簽名和附加證據。選擇依據是你需要把多少檔案保護在一起，以及這個檔案包必須保持可驗證多長時間。
| 對比維度 | ASiC-S（簡單型） | ASiC-E（擴展型） |
|---|---|---|
| 數據對象 | 恰好一個 | 一個或多個 |
| 簽名 | 一份 XAdES 或 CAdES 簽名 | 多份簽名，含會簽（counter-signature） |
| 清單 / 時間戳 | 不要求 | 支援 manifest.xml 和時間戳令牌 |
| 常見副檔名 | .asics | .asice（亦可見 .sce） |
| 適用場景 | 一份檔案簽一次（如單張發票 XML） | 多檔案打包、多人會簽、長期歸檔 |
經驗法則：只要將來可能需要給同一個檔案包加第二份檔案、第二位簽署人或時間戳，就直接從 ASiC-E 開始。事後轉換意味着重新打包、重新簽署。
ASiC 與 XAdES、CAdES、PAdES 是甚麼關係？
ASiC 不是一種簽名格式，而是承載簽名格式的容器。XAdES（XML 高級電子簽名）和 CAdES（基於 CMS/PKCS#7 的簽名）都可以是分離式的，這正是 ASiC 要解決的場景：簽名區塊存放在容器的 META-INF 文件夾中，透過摘要值引用數據對象。如果你在比較這些簽名的證書層面，我們關於甚麼是 DSC 的解讀文章介紹了 XAdES 和 CAdES 簽署人所使用的證書憑證。
PAdES 則不同：簽名直接嵌入 PDF 檔案結構內部，所以一份已簽署的 PDF 本身就是自包含的，不需要 ASiC 包裝。你仍然可以把 PDF 作為數據對象放進 ASiC-E 容器——例如 PDF 必須與已簽署的 XML 附件一起傳輸時——但 PAdES 簽名本身始終留在 PDF 內部。
ASiC 容器的實際應用場景
凡是簽名和檔案必須經受住傳輸、審計和多年儲存考驗的地方，都能見到 ASiC：
- 電子發票： 歐洲多個電子發票交換平台把發票 XML 與其簽名作為一個
.asice檔案包傳輸，接收平台只需驗證單個檔案。 - 政府與跨境申報： 歐盟成員國門戶以及海關、稅務申報通常接受 ASiC 提交，因為一個容器就把「你簽的到底是哪份檔案」這類爭議降到零。
- 長期歸檔： 借助 ASiC-E 的清單和時間戳令牌，即使算法逐漸老化，歸檔機構也能在多年後重新驗證檔案包。
- 法庭證據： 把證物、簽名和驗證證據打包進一個檔案，能簡化證據鏈（chain of custody）的論證。
共同點在於：任何要求簽名始終附著在它所保護的確切字節上的流程。負責簽發底層證書的團隊可查看如何製作數碼簽名證書，了解簽發前提。
如何開啟並驗證 .asics 或 .asice 檔案
開啟很簡單——如果解壓工具不認識副檔名，把檔案改名為 .zip 即可查看內容。真正的工作是驗證。支援 ASiC 的工具包括歐盟委員會的開源 DSS（Digital Signature Service）庫及其示範網頁應用、各國電子簽名驗證門戶，以及電子發票驗證器。一份實用的驗證清單：
- 確認
mimetype條目與容器規格一致（asic-s 還是 asic-e）。 - 對簽名做密碼學驗證，並檢查它引用的數據對象確實存在。
- 沿證書鏈回溯到可信根證書——一份可信證書頒發機構清單有助於確認簽發者的資質。
- 檢查簽名聲稱時間點的吊銷狀態（CRL/OCSP）。
- 對每個數據對象重新計算清單摘要值，必須全部匹配。
- 驗證時間戳令牌及其自身的簽名鏈。
- 把驗證報告作為審計證據留存。
瀏覽器端的檢查也涵蓋證書這一環；在 Chrome 中驗證數碼簽名展示的證書鏈檢查步驟，同樣適用於 ASiC 容器內的證書。
ASiC 如何融入 eIDAS 框架
eIDAS 並不強制使用 ASiC。eIDAS 管的是容器內部的簽名等級——標準級（SES）、高級（AES）或合格級（QES）——而 ASiC 屬於落實 eIDAS 兼容包裝的 ETSI 標準族（EN 319 162）。一個裝有合格級 XAdES 簽名的 .asice 檔案，與該合格簽名在任何其他包裝形式下具有同等法律效力；容器只是保證它完好無損。這一格式也被歐盟數碼身分錢包（EU Digital Identity Wallet）的技術工作引用，始終留在歐洲的技術路線圖上。如果你的工作流程要求簽名等級正確而不僅是包裝正確，相關要求見我們的eIDAS 合規電子簽名指南。在歐盟之外，ASiC 是技術選型而非法律要求——對歐洲合作方的互操作性有用，在其他地區則保持中立。
Nota Sign：把 ASiC 就緒的簽署放進合規工作流程
ASiC 容器能把簽名和檔案裝在一起，但修不好容器裏那個本身就不牢靠的簽名。裝進容器裏的身分核驗、簽名等級與證據記錄，取決於產生它的簽署工作流程。Nota Sign 是法大大旗下的全球電子簽名平台，從源頭把工作流程做對：簽名等級涵蓋 SES、AES 到 QES，身分核驗與等級匹配，審計記錄經得起長期歸檔。區域數據中心讓記錄留在當地規則要求的地方，價格不按席位計費，業務量增長時成本可預期。如果你的檔案需要在任何容器裏多年後仍可驗證，聯絡 Nota Sign，從第一份簽名起就把證據鏈建進去。
