什么是 Base64 编码 / 解码器？
Base64 是一种二进制到文本的编码方案，使用 64 个可打印的 ASCII 字符(A-Z、a-z、0-9、+、/)来表示二进制数据。它广泛用于 Web 开发、电子邮件、密码学和数据传输中，以便通过仅支持文本的通道安全地传输二进制数据。我们的 Base64 编码器和解码器可在原始文本与 Base64 编码字符串之间即时转换，没有大小限制，并完整支持 Unicode。
Base64 是编码，不是加密。它不保护数据不被读取——它只是改变数据的表示方式。任何有权访问该字符串的人都可以将任何 Base64 字符串解码回原始数据。它出于兼容性原因而被使用：将图像作为 data URI 嵌入 HTML、为 HTTP 基本认证编码 API 凭据、通过 MIME 经电子邮件传输二进制文件，以及在只能包含文本的 JSON 或 XML 中存储二进制数据块。
理解 Base64 是现代 Web 开发的基础。JWT 令牌、data URI、Basic Auth 头、SAML 断言和 PEM 证书文件都使用 Base64 编码。一个无法快速编码或解码 Base64 字符串的开发者，会把时间浪费在编写一次性脚本或查找正确的命令行参数上。我们的工具让这一切即时完成，并可从任何浏览器访问。
使用场景
以下是人们每天使用 Base64 编码 / 解码器 的最常见场景。
API 认证头
HTTP 基本认证将凭据以"用户名:密码"的形式经 Base64 编码后放入 Authorization 头中：Authorization: Basic dXNlcjpwYXNzd29yZA==。使用编码器即可生成正确的头部值，用于通过 curl 或 Postman 手动测试 API，而无需编写代码。使用解码器可在调试认证问题时读取并验证现有 Authorization 头中的凭据。
在 HTML 和 CSS 中嵌入图像
小图像——图标、徽标、内联 SVG——可以使用 Base64 编码作为 data URI 直接嵌入 HTML 或 CSS：src="data:image/png;base64,..."。这就省去了对小型资源原本需要的单独文件的一次 HTTP 请求。代价是更大的 HTML 文件体积(Base64 使体积增加约 33%)。对于小于 1 KB 的图标，省去请求的好处通常超过体积成本。我们的编码器可直接处理这种用例。
JWT 令牌检查
JSON Web Token 由三个以点分隔的 Base64URL 编码段组成：头部.载荷.签名。头部和载荷包含的 JSON 数据无需密钥即可解码。在前两段(点之前和点之间)上使用我们的解码器，即可检查令牌的算法、签发者、主体、声明、签发时间和过期时间——这对于在没有专门 JWT 检查器的情况下调试 JWT 认证问题至关重要。
电子邮件附件编码
电子邮件协议(SMTP、IMAP)在 MIME 多部分消息格式中以 Base64 传输二进制文件，因为电子邮件基础设施是为 7 位 ASCII 文本设计的。附加到邮件的图像、PDF 和文档会在邮件的原始源码中被 Base64 编码。理解这种编码对于编写邮件发送代码、调试邮件投递问题以及在数据处理管道中解析原始邮件消息至关重要。
配置与密钥存储
Base64 编码常用于在仅支持文本的环境变量和配置文件中存储二进制数据。TLS 证书(PEM 格式)、SSH 密钥、二进制令牌和二进制配置值会被 Base64 编码后存储在 .env 文件和 Kubernetes Secret 中。kubectl get secret 默认输出 Base64 编码的值：我们的解码器是检查底层数据的快捷方式，无需在命令行中通过 base64 -d 管道处理。
示例
编码 API 凭据
从用户名和密码创建 HTTP 基本认证头部值。
admin:secretpassword123 YWRtaW46c2VjcmV0cGFzc3dvcmQxMjM= 解码 JWT 载荷
解码 JWT 的第二段以检查其声明。
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0= {"sub":"1234567890","name":"John Doe"} 为 URL 编码 JSON
将 JSON 对象编码为 Base64，用于 cookie 或 URL 参数。
{"userId": 42, "role": "admin"} eyJ1c2VySWQiOiA0MiwgInJvbGUiOiAiYWRtaW4ifQ== Base64 编码 / 解码器 使用技巧
- Base64 使数据体积增加约 33%：一张 1 MB 的图像编码后约为 1.33 MB。内联嵌入图像时要考虑到这一点。
- Base64URL(用于 JWT)将 + 替换为 -、将 / 替换为 _，以获得 URL 安全的输出。标准 Base64 与 Base64URL 不可互换。
- Kubernetes 密钥以 Base64 存储数据。使用解码器检查密钥值：echo "dmFsdWU=" | base64 -d——或使用我们的工具。
- 切勿假定 Base64 数据是私密的。它可被轻易逆转。对待 Base64 字符串应与对待其解码内容同样谨慎。
- PEM 证书文件(.pem、.crt)是被 -----BEGIN CERTIFICATE----- 头包裹的 Base64 编码 DER 证书。
常见问题解答
Base64 和加密是一回事吗？
不是。Base64 是一种编码方案——它改变数据的表示方式，但完全不提供保密性。任何人都能用任意 Base64 解码器在几毫秒内将 Base64 字符串解码回原始数据。而加密则将数据转换为没有正确密钥就无法逆转的密文。切勿用 Base64 来保护敏感数据。请用加密(AES-256、RSA、TLS)来实现保密，仅在兼容性方面使用 Base64——即为仅支持文本的传输通道编码二进制数据。
为什么 Base64 以"="填充结尾？
Base64 将 3 个字节的输入(24 位)编码为 4 个 Base64 字符(4 × 6 位 = 24 位)。如果输入长度不能被 3 整除，就会添加填充字符"="，使编码后字符串的长度能被 4 整除。一个"="表示添加了一个字节的填充；"=="表示两个字节。某些应用(如 JWT 和 Base64URL)会省略填充，因为解码器可以从字符串长度推断出长度。标准 Base64 始终包含填充。
Base64 和 Base64URL 有什么区别？
标准 Base64 使用字符 A-Z、a-z、0-9、+ 和 /。+ 和 / 在 URL 中是特殊字符：在百分号编码中它们会被编码为 %2B 和 %2F，使得标准 Base64 字符串在 URL 中很别扭。Base64URL 是为 URL 设计的：它将 + 替换为 -、将 / 替换为 _，以产生在 URL 路径、查询字符串和文件名中无需百分号编码即可安全使用的字符串。JWT 令牌、OAuth 令牌和 URL 参数都使用 Base64URL。
为什么 Base64 会使数据增大 33%？
Base64 将每 3 个字节(24 位)的输入转换为 4 个字符(每个表示 6 位)。比例为 4/3 ≈ 1.33，因此每 3 个字节变成 4 个字符——无论数据内容如何，体积都增加 33%。这种开销是二进制到文本编码的代价。在为 Base64 编码内容规划存储或带宽时，将原始二进制大小乘以 1.34 即可估算编码后的大小(额外的 0.01 用于计入可能的填充和换行符)。
Base64 能编码任何类型的数据吗？
可以。Base64 能编码任何二进制数据：图像、音频、视频、可执行文件、压缩档案、加密密钥和任意字节序列。这种编码与内容无关——它将所有输入都视为原始字节。对于文本输入，工具会先转换为 UTF-8 字节，再对这些字节进行 Base64 编码。对于非 ASCII 文本(中文、阿拉伯文、表情符号)，这意味着 Base64 字符串编码的是 UTF-8 字节表示，而非原始的 Unicode 码点。
什么是 data URI，Base64 如何使其成为可能？
data URI 是一种 URI 方案，它将数据直接嵌入 URI 字符串中，而不是指向外部资源：data:[媒体类型][;base64],数据。例如：src="data:image/png;base64,iVBORw0KGgo..."。base64 参数表明数据部分是 Base64 编码的，而非百分号编码的纯文本。data URI 允许将图像、字体和其他资源直接嵌入 HTML 或 CSS，无需单独的 HTTP 请求，这可以提升小型资源的页面加载性能。