Base64 术语表

A 到 C

Alphabet（字母表）

一种编码所使用的字符集合，按索引顺序排列。标准 Base64 使用 A-Z、a-z、0-9、+ 和 /，因此 A 表示 0，/ 表示 63。见 字母表。

ASN.1

抽象语法标记一（Abstract Syntax Notation One），一种描述数据结构的语言，X.509 证书、密钥和许多电信协议都在用。ASN.1 定义结构，DER 等编码规则定义具体的字节。

Base16

RFC 4648 对 hex 的称呼：每个字节变成两个 0-9 A-F 中的字符，体积翻倍。试试 Base16 工具。

Base32

使用 32 个字符（RFC 4648 中为 A-Z 和 2-7）的编码，把 5 个字节变成 8 个字符，比输入大 60%。由于字母表不区分大小写，它很适合 TOTP 密钥和 DNS 名称。试试 Base32 编码器。

Base45

由 RFC 9285 定义，把 2 个字节变成 3 个字符，字符取自二维码字母数字模式所能存储的 45 个字符。欧盟数字新冠证书用的就是它。试试 Base45 编码器。

Base58

比特币使用的 58 字符字母表：即去掉 0、O、I、l、+ 和 / 的 Base64 字母表。它把整个输入当作一个大数来转换，每个前导零字节都变成一个 1。试试 Base58 编码器。

Base58Check

在 Base58 的基础上，前面加一个版本字节，末尾加 4 字节校验和。校验和是连续两次 SHA-256 的结果的前 4 个字节。传统比特币地址和 WIF 私钥都使用它。见 Base58Check 工具。

Base64

一种二进制到文本的编码，把每 3 个字节写成 64 字符字母表中的 4 个字符，末尾用 = 填充。输出比输入大约 33%。可以从 编码器 和 解码器 开始，或者阅读 Base64 的工作原理。

Base64URL

用 - 和 _ 代替 + 和 / 的 Base64，出自 RFC 4648 第 5 节。通常省略填充。JWT 和 URL 中都用它。见 Base64 与 Base64URL 的区别 和 Base64URL 编码器。

Base85

一类把 4 个字节写成 5 个字符的编码，开销为 25%。常见变体有 Ascii85（Adobe 制定，用于 PDF 和 PostScript）、Z85（ZeroMQ）以及 git 使用的 RFC 1924 字母表。试试 Base85 工具。

Base91

basE91 由 Joachim Henke 设计，使用 91 个可打印 ASCII 字符，每两个字符承载 13 或 14 位。因此它的开销在约 14% 到 23% 之间，是这里最低的，代价是字母表里包含双引号和许多其他标点符号。试试 Base91 工具。

Basic Auth

HTTP Basic 认证（RFC 7617）把 user:password 经 Base64 编码后放在 Authorization 请求头中发送：Aladdin:open sesame 会变成 Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==。任何看到这个请求头的人都能解码它，所以必须配合 HTTPS。可以用 Basic Auth 生成器 和 解码器 生成或解读。

Binary-to-text encoding（二进制到文本编码）

任何只用可打印字符来表示任意字节的方案，让数据能安全经过电子邮件、JSON、URL 等为文本设计的系统。Hex、Base32、Base64、Base85、uuencode 和 quoted-printable 都属于这类编码。它们的对比见 Base64 与 hex、Base32、Base58、Base85 的对比。

BOM

字节顺序标记（Byte order mark），即放在文本文件开头的字符 U+FEFF。在 UTF-8 中是 EF BB BF（Base64 为 77u/），在 UTF-16LE 中是 FF FE。不认识它的解码器会把它显示成  或一个多余的不可见字符。

Canonical encoding（规范编码）

某段数据唯一“正确”的编码形式。在 Base64 中，它要求填充前未使用的比特为零（RFC 4648 第 3.5 节）：SGk/Pg== 是规范的；SGk/Ph== 在宽松的解码器中能解出相同的字节，但不规范。

Charset（字符集）

把文本映射为字节的字符编码，例如 UTF-8、UTF-16LE 或 Windows-1252。Base64 存储的是字节，所以要把 Base64 解码成文本，就得知道文本保存时用的字符集。猜错了就会出现 Café 这样的乱码。Base64 转文本 工具可以切换字符集。

CRLF

回车加换行，即字节 0D 0A。MIME 要求 Base64 各行之间使用 CRLF，而 Unix 工具通常只写 LF（0A）。宽松的解码器会忽略两者，严格的解码器则会拒绝。

CSP nonce

内容安全策略请求头（script-src 'nonce-…'）中的一个随机值，只允许带有相同 nonce 属性的内联脚本执行。它用 Base64 书写，每个响应都必须重新生成，并且应包含至少 128 位随机性。可以用 CSP nonce 生成器 生成。

D 到 J

Data URI

一种直接携带数据本身、而不是指向数据的 URL，由 RFC 2397 定义：data:image/png;base64,iVBORw0KGgo…。适合在 HTML 和 CSS 中嵌入小图片和图标。见 Data URI 生成器、解析器 和 Data URI 的性能。

Deflate

ZIP、gzip、zlib 和 PNG 内部使用的压缩算法（RFC 1951）。“raw deflate”指外面不带头部和校验和的压缩数据流。可以用 zlib 和 deflate 工具 压缩并编码。

DER

可区分编码规则（Distinguished Encoding Rules），ITU-T X.690 定义的 ASN.1 结构的严格二进制编码。证书和密钥就是 DER 字节。DER 结构通常以 30（SEQUENCE）开头，所以 PEM 的正文以 M 开头，常见的是 MII。

gzip

一种文件格式（RFC 1952），用 10 字节的头部和 CRC-32 校验和包裹 deflate 压缩数据。它以字节 1F 8B 开头，所以 gzip 数据的 Base64 以 H4sI 开头。用 gzip 与 Base64 压缩，用 解码 gzip Base64 还原。

Hex

十六进制：每个字节写成两个 0-9 和 a-f 中的数字，例如 Hello 写作 48 65 6c 6c 6f。逐字节阅读很方便，体积是输入的两倍。可以用 Base64 转 hex 和 hex 转 Base64 转换。

JWE

JSON Web 加密（RFC 7516）。一种加密令牌，其紧凑格式由五个 Base64URL 部分组成：头部、加密的密钥、初始化向量、密文和认证标签。与 JWS 不同，没有密钥就无法读取内容。

JWS

JSON Web 签名（RFC 7515）。一种带签名的消息，由三个 Base64URL 部分组成：头部、载荷和签名。载荷任何人都能读，签名只证明它没有被改过。

JWT

JSON Web 令牌（RFC 7519），即装在 JWS 或 JWE 里的一组 JSON 声明。你遇到的 JWT 大多是以 eyJ 开头的 JWS 令牌。用 JWT 解码器 解码，用 JWT 编码器 生成，也可以阅读 JWT 中的 Base64。

L 到 Q

Line wrapping（换行）

在较长的 Base64 输出中插入换行符。MIME 每行不超过 76 个字符，PEM 每行恰好 64 个字符。GNU base64 默认在 76 个字符处换行（-w 0 关闭换行），openssl base64 在 64 处换行（-A 关闭换行）。MIME 编码器 会自动帮你换行。

Magic number（魔数）

文件开头用来标识格式的固定字节序列，例如 PDF 的 %PDF-、PNG 的 89 50 4E 47。由于 Base64 每次编码 3 个字节，魔数会变成可辨认的 Base64 前缀。见 常见的 Base64 前缀 和 Base64 转文件。

MIME

多用途互联网邮件扩展（RFC 2045 到 2049），让电子邮件能够携带附件和非 ASCII 文本的标准。它的 base64 Content-Transfer-Encoding 就是附件在纯文本邮件中传输的方式。见 电子邮件中的 Base64 和 EML 解码器。

Padding（填充）

Base64 末尾用来填满最后一个 4 字符组的 = 字符：剩 1 个字节时是 ==，剩 2 个字节时是 =。有些格式会去掉它。请阅读 填充指南。

PEM

隐私增强邮件（Privacy-Enhanced Mail），最初是一个安全电子邮件标准（RFC 1421）。如今这个名字指的是它为密钥和证书定义的文本格式：DER 字节的 Base64，夹在 -----BEGIN CERTIFICATE----- 和 -----END CERTIFICATE----- 两行之间，每 64 个字符换行（RFC 7468）。可以用 证书解码器 查看。

Quoted-printable

MIME 的另一种传输编码。它保留可打印的 ASCII 字符，把其他字节写成 = 加两位 hex 数字，所以 UTF-8 的 Café 会变成 Caf=C3=A9。对以 ASCII 为主的文本很高效，用于二进制则很浪费。试试 quoted-printable 工具。

R 到 Z

Radix-64

OpenPGP 对其 ASCII 封装（ASCII armor）的称呼：标准 Base64，外加一行可选的校验和，以 = 开头，内容是 Base64 形式的 CRC-24。见 Base64 相关标准。

SRI

子资源完整性（Subresource Integrity），浏览器的一项功能，用 integrity 属性中的哈希来校验下载的脚本或样式表，写法是算法名加 Base64 摘要：sha384-…。支持的算法有 SHA-256、SHA-384 和 SHA-512。可以用 SRI 哈希生成器 生成。

uuencode

Unix-to-Unix 编码，一种比 MIME 更早的二进制到文本格式。每行以一个长度字符开头，数据字符取自 ASCII 32 到 95，因此包含 MIME 的 Base64 所避开的标点符号。见 uuencode 工具。

UTF-8

Web 上最主流的文本编码。ASCII 字符占一个字节，其他字符占两到四个字节。工具说“文本转 Base64”时，几乎总是指把 UTF-8 字节转成 Base64：é 是 C3 A9。见 UTF-8 转 Base64。

UTF-16LE

低字节在前的 UTF-16，是 Windows 和 .NET 内部的字符串格式。UTF-16LE 编码的 ASCII 文本在每个字符后都有一个零字节，所以 Hello 会变成满是 A 的 SABlAGwAbABvAA==。PowerShell 的 -EncodedCommand 要求的就是这种格式。见 UTF-16 转 Base64 和 PowerShell 解码器。

Z85

ZeroMQ 的 Base85 变体（ZeroMQ RFC 32）。它把 4 个字节编码成 5 个字符，避开了引号和反斜杠，因此输出可以直接放进源代码字符串中，并要求输入长度是 4 字节的倍数。试试 Z85 工具。

zlib

包在 deflate 数据外面的一层薄封装（RFC 1950）：2 字节的头部和 Adler-32 校验和。头部通常以 78 开头，所以 zlib 数据的 Base64 会以 eJ、eN、eF 或 eA 开头，具体取决于压缩级别。使用 zlib 工具。

常见问题