開發者工具 · Base64 編碼器和解碼器
PEM 解釋：為什麼憑證和金鑰在 BEGIN 和 END 之間是 Base64
· 背景
base64 編碼
PEM 檔案是用 Base64 封裝的 DER 二進位檔案，帶有標記的裝甲線。這篇文章解釋了這種格式的起源、行規則以及透過解碼可以學到什麼和不能學到什麼。
“看起來像文字”但無法解析的證書 - 標頭拼字錯誤、雜散回車符和下面的格式
PEM 檔案是包裹在文字標籤中的 Base64 編碼二進位檔案。此名稱來自隱私增強郵件（RFC 1421、1992），該格式使用此格式來加密郵件。該格式至今仍存在於 TLS 憑證、SSH 金鑰和 GPG 金鑰中。結構很簡單：一行 -----BEGIN CERTIFICATE----- （或 BEGIN PRIVATE KEY、BEGIN PUBLIC KEY 等），後面跟著 64-base64 文字字元行，然後是 -----END CERTIFICATE-----。
base64 主體解碼為稱為 DER（傑出編碼規則）的二進位格式，這是一種序列化結構化資料（具體來說，ASN.1 結構）的方法。解碼 Base64 會得到二進位；讀取二進位檔案需要了解 ASN.1，這很複雜。 PEM 裝甲的存在是因為二進位檔案很難透過電子郵件發送和編輯。純二進位形式的憑證檔案會在通過舊郵件系統、USENET 或 Web 表單時損壞。
PEM 區塊中可見的文字裝甲 — Base64 主體周圍的標籤
透過對二進位檔案進行 base64 編碼並將其包裝在文字標籤中，整個憑證變成 7 位元 ASCII 文字，可以在任何傳輸中保存。文字編輯器可以打開它；郵件系統不會損壞它。 -----BEGIN 和 -----END 行是人類和自動化工具的標籤；它們清楚地標記了裡面的資料類型。證書標記為CERTIFICATE；私鑰被標記為私鑰。
標籤未經加密軟體驗證；它只是給人類和工具的一個提示。 PEM 中的 64 字元行限制來自 RFC 1421 以及與電子郵件 base64 相同的 MIME 推理：舊郵件系統有行長度限制，並 64 字元適合 20 世紀 80 年代的終端。 PEM 將 base64 輸出包裝在 64 字元處並以行結尾（Windows 上為 CR LF，Unix 上為 LF）。
從標記文字到解碼位元組 - 此儲存庫不建立格式歷史記錄
解碼 PEM 憑證時，解析器必須剝離鎧甲線 (-----BEGIN..., -----END...) 和換行符，然後對剩餘部分進行 Base64 解碼。雜散的回車符或不匹配的標籤可能會中斷解析。換行不是 base64 標準的一部分（RFC 4648 base64 已展開）；它是 PEM 特有的。 Base64 內部是 DER 編碼的二進位。 DER 是 ASN.1（抽象語法表示法），一種表示資料結構的複雜規格。
憑證是包含主題名稱、公鑰、簽章和元資料的結構化記錄。 ASN.1 不直接描述位元組；它描述了結構應該如何編碼。
作為此工具輸入的區塊的剖析 - 刪除標籤並僅傳遞 Base64 主體
編碼以標籤長度值三元組開始。例如，ASN.1 中的 SEQUENCE 被編碼為標記 0x30，後面跟著內容的長度，最後是內容本身。證書總是以位元組 0x30 0x82（序列，以兩個位元組編碼的長度）開頭，在 Base64 中顯示為 MII。
檢查證書而不解析它：PEM 證書正文的前三個字元幾乎總是 MII（在 base64 中為 0x30 0x82，SEQUENCE 的開頭）。如果 PEM 區塊未解碼為 0x30，則表示 Base64 已損壞或標籤錯誤。 Base64 編碼器和解碼器工具可以解碼正文並顯示十六進位：貼上 Base64 行（不含 -----BEGIN 和 END 裝甲），刪除換行符，然後解碼。
解碼公開什麼：二進位字節，未解析的憑證欄位
如果輸出是以 30 82 開頭的二進位檔案，則它可能是有效的證書結構。如果是亂碼或文字，則說明解碼失敗或base64錯誤。常見的 PEM 錯誤：標籤不符（例如，帶有 PRIVATE KEY 標籤的證書正文）、Windows 行結束問題（某些解析器在 CRLF 上阻塞）、盔甲行中的拼字錯誤（多餘的空格或字元）或缺少換行符。
工具需要 -----BEGIN CERTIFICATE----- 而非 -----BEGIN CERT----- 或 BEGIN CERTIFICATE。從 Web 瀏覽器或 PDF 複製貼上 PEM 可能會引入 Unicode 引號或智慧引號而不是 ASCII 引號，從而破壞標籤。將私鑰貼到憑證欄位中是一個常見的錯誤；解析器將拒絕它，因為標籤不符。 PEM 支援一個檔案中的多個區塊。
工作範例：解碼短文並檢查位元組而不斷言憑證簽名
SSH 金鑰檔案可能包含私鑰（標記為 PRIVATE KEY）和公鑰（標記為 PUBLIC KEY）或多個憑證區塊。解析器從頂部讀取文件，尋找以 -----BEGIN 開頭的行。當它找到一個時，它會讀取直到 -----END 具有匹配的標籤，提取正文並對其進行 Base64 解碼，然後對其進行處理。然後它繼續尋找下一個區塊。
意外串聯的憑證鏈（憑證及其中間體的多個 PEM 區塊）有效。 PEM 格式在 20 世紀 90 年代初針對隱私增強郵件 (RFC 1421) 進行了標準化。
這不包括什麼 - 解析 ASN.1 結構、私鑰加密和 PKCS#12 捆綁包
RFC 7468 (2015) 對定義進行了現代化改造，闡明了線長度規則、裝甲線格式和邊緣情況。現在大多數工具和標準都會引用 RFC 7468。還有其他二進位到文字格式（例如某些協定的 DER 到十六進位），但帶有 base64 和 ASCII 標籤的 PEM 是密碼學和 TLS 的事實上的標準，因為它是人類可讀的純文字，並易於複製或發送。
建立 PEM 區塊：取得 DER 二進位檔案（例如，來自加密庫的憑證），將其編碼為 base64，將結果包裝在帶有換行符號的 64 字元處，並用 -----BEGIN CERTIFICATE----- 和 -----END CERTIFICATE----- 行將其包圍。解析 PEM 區塊：找到 -----BEGIN 和 -----END 行，提取 base64 主體（去除裝甲和換行符），base64 解碼以取得二進位檔案，然後解析 DER 和 ASN.1 二進位檔案。
重點：PEM 是帶有標籤的 Base64 — Base64 編碼器和解碼器如何提供您一個完全在瀏覽器中嘗試區塊的 Base64 主體的本地位置
大多數工具都會自動執行此操作；你很少手動建立 PEM。但是，在偵錯解析錯誤或手動驗證憑證時，了解該結構非常有用。 PEM憑證看起來像文字，但內容是二進位資料。閱讀開始和結束標籤並不能告訴您憑證包含什麼內容；您必須解碼 Base64 並解析 ASN.1 以查看主題名稱、公鑰、頒發者和過期時間。
Base64 編碼器和解碼器工具可以解碼正文，以便您可以檢查前幾個位元組。要進行完整解析，您需要一個 ASN.1 解析器（大多數程式語言都有用於此目的的程式庫）。關鍵在於 PEM 是一種容器格式：它保存任何 DER 編碼的資料，而不僅僅是憑證。標籤告訴您預期用途，但解析器必須正確處理資料類型。