开发者工具 · 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 编码的数据，而不仅仅是证书。标签告诉您预期用途，但解析器必须正确处理数据类型。