Base64 是什么,什么时候用
Base64 用 64 个可打印字符(大写字母 26 个、小写字母 26 个、数字 10 个,再加 + 和 /,末尾用 = 补齐)来表示任意字节序列。 邮件正文、JSON 字段、HTTP 请求头、HTML 的 data: URI、配置文件等通道只能稳妥地传输文本,把图片或中文这类字节任意的数据放进去时,就需要先编码成 Base64。 HTTP Basic 认证头(Authorization: Basic ...)和 JWT 的各个部分也用这种方式书写(JWT 使用 URL 安全变体)。 本页面先把输入的字符串转换成 UTF-8 字节再做 Base64 编码,解码时则把 Base64 还原为字节,再按 UTF-8 读成文本。
原理:3 个字节变 4 个字符
3 个字节共 24 位,按每 6 位分成 4 组,每组是 0~63 的数值,再到 64 字符表中查出对应字符(A-Z 为 0~25,a-z 为 26~51,0-9 为 52~61,+ 为 62,/ 为 63)。 例如 Man 的字节是 77、97、110,按二进制连起来是 010011 010110 000101 101110,即第 19、22、5、46 号字符,结果为 TWFu。 输入长度不是 3 的倍数时,剩 1 个字节用 2 个字符加 == 补齐,剩 2 个字节用 3 个字符加 = 补齐,保证结果总是以 4 个字符为一组。 因此结果长度恒为 4 × ⌈字节数 ÷ 3⌉,比原数据大约多三分之一。
测试向量(构建时计算)
下表是生成页面时对每个输入的 UTF-8 字节实际编码得到的值,可用来和工具结果或自己的代码对照,检验实现是否正确。
| 输入 | 字符数 | UTF-8 字节数 | Base64 |
|---|---|---|---|
| (空字符串) | 0 | 0 | (空) |
| a | 1 | 1 | YQ== |
| ab | 2 | 2 | YWI= |
| abc | 3 | 3 | YWJj |
| Hello, World! | 13 | 13 | SGVsbG8sIFdvcmxkIQ== |
| {"id":1} | 8 | 8 | eyJpZCI6MX0= |
| 你好世界 | 4 | 12 | 5L2g5aW95LiW55WM |
| 😀 | 1 | 4 | 8J+YgA== |
| user:pass | 9 | 9 | dXNlcjpwYXNz |
英文字母每个 1 字节,常见汉字每个 3 字节(“你好世界”4 个字 12 字节,编码后 16 个字符),表情符号 4 字节。所以字数相同时,中文的 Base64 更长。空输入得到空结果,不属于错误。
长度与体积变化
| 原始字节数 | Base64 字符数 | 填充 = 的个数 | 相对原始大小 |
|---|---|---|---|
| 1 | 4 | 2 | 400.0% |
| 2 | 4 | 1 | 200.0% |
| 3 | 4 | 0 | 133.3% |
| 10 | 16 | 2 | 160.0% |
| 100 | 136 | 2 | 136.0% |
| 1,000 | 1,336 | 2 | 133.6% |
| 1,048,576 | 1,398,104 | 2 | 133.3% |
1 MiB(1,048,576 字节)的文件会变成约 1.33 MiB 的文本。把图片直接嵌入 HTML 或 CSS 能少一次请求,但文档会变大且无法单独缓存,所以只适合小图标。
什么时候需要 URL 安全格式
标准 Base64 中的 + 和 / 在 URL 里可能被当作空格和路径分隔符。因此在 URL、文件名和 JWT 中,会用 - 代替 +、_ 代替 /,并省略末尾的 =(RFC 4648 中的 base64url)。 例如 subject?>> 在标准格式下是 c3ViamVjdD8+Pg==,在 URL 安全格式下是 c3ViamVjdD8-Pg。勾选复选框再编码即可得到这种形式;解码时无论是否勾选,两种格式都能识别。
动手试试:三个例子
例 1 中文往返。输入 你好世界 并编码,得到 5L2g5aW95LiW55WM(16 个字符,无填充)。12 字节是 3 的倍数,所以没有 =。把它放回输入框解码,即可还原。
例 2 检查 Basic 认证头。把 user:pass 编码得到 dXNlcjpwYXNz。如果请求头里是 Basic dXNlcjpwYXNz,任何人都能用这个工具读出用户名和密码,所以 Basic 认证只能配合 HTTPS 使用。
例 3 解码杂乱的输入。即使其中混有换行或空格、使用了 - 和 _,或者缺少末尾的填充,工具也会先整理再读取。邮件里每 76 个字符换行的 Base64 也可以直接粘贴。
注意事项与局限
中文与表情符号。工具先把字符串转成 UTF-8 字节再编码。如果别的工具或语言对同一段中文得到不同结果,多半是它用了 GBK、UTF-16 等其他编码来生成字节。本工具解码时只按 UTF-8 解读,遇到其他编码的字节会提示“不是 UTF-8 文本”。
二进制数据。图片、PDF、加密后的字节解码出来无法当作文字阅读,会提示错误。本工具只处理文本,不是文件转换工具。
无效输入。包含 Base64 不允许的字符,或去掉填充后的字符数除以 4 余 1(单个字符无法构成字节),都会提示无法解码。
大文本。几百 KB 的文本通常瞬间完成,特别大时标签页可能短暂卡顿。转换按块进行,不会触发参数长度限制的错误。
安全与隐私
转换脚本只读取输入框并在浏览器内转换,不会发送输入内容,也不保存。不过广告脚本等网站的其他组成部分是独立运行的,因此对于正在使用的密码、API 密钥等敏感值,建议尽量在本地环境中处理。 最重要的是,Base64 不是加密。任何人无需密钥就能还原,所以“已经转成 Base64 就安全了”是危险的想法。要保护秘密应使用加密,需要不可逆的指纹则应使用哈希。
结果可以用在哪里
可用于检查认证头、查看 JWT 各部分的内容(把其中一段用 URL 安全格式解码就能看到 JSON)、核对配置文件中的编码值以及制作测试数据。 如果解码结果是 JSON,可以用 JSON 格式化工具 整理缩进,阅读更方便。
常见问题
Base64 是加密吗?
不是。Base64 是任何人无需密钥都能还原的编码,不能用来保护密码或敏感信息。
中文显示成乱码怎么办?
本工具以 UTF-8 为准,中文可以正常编码和解码。如果解码别处生成的 Base64 出现乱码,很可能原文使用了 GBK 等其他编码,或者本身是二进制数据而不是文本。
末尾的 = 有什么用,可以去掉吗?
它是在输入不是 3 字节整数倍时补齐到 4 字符一组的填充。URL 安全格式常常省略它,本解码器也能根据长度自动补回,但一些严格的库会拒绝没有填充的输入。
含 + 或 / 的值放进 URL 后出问题怎么办?
查询字符串中的 + 可能被读成空格,/ 可能被当作路径分隔符。可以用 URL 安全格式编码,或用 URL 编码工具 再做一次百分号编码。
它和哈希有什么区别?
Base64 可以还原,长度随输入增长;哈希是不可逆的固定长度指纹。需要哈希请使用 哈希生成器。
相关工具
- URL 编码/解码工具:百分号编码转换
- 哈希生成器:生成不可逆的指纹
- JSON 格式化工具:让解码出的 JSON 更易读
- 密码生成器:生成高强度随机密码