Base64 编码详解：它是什么、如何工作及何时使用
你每天都在用 Base64，你可能自己都不知道。邮件附件、网页里嵌的小图片、JWT Token 那串乱码——背后都是它。但你有没有想过，为什么需要这么个东西？
核心原因很简单：很多传输协议只认文本，不认二进制。Base64 就是二进制数据穿上文本的外衣，安全地通过只认 ASCII 的通道。读完这篇文章，试试我们的 在线 Base64 编解码工具 亲手验证一下。
什么是 Base64？
Base64 用 64 个可打印字符来表示任意二进制数据。这 64 个字符包括 A-Z、a-z、0-9、+ 和 /，再加上 = 作为填充。
说白了就是：二进制数据不能直接当文本传，Base64 给它做了一层"文本化"转换。代价是体积增加大约 33%。
Base64 的工作原理
编码过程三步走：
步骤 1：将二进制数据分组
每 3 个字节（24 位）分成一组。不够 3 的倍数就补填充字节。
步骤 2：将 24 位分成 4 个 6 位块
每个 3 字节组拆成 4 个 6 位的块。6 位能表示 0-63，正好对应那 64 个字符。
步骤 3：映射到 Base64 字符集
每个 6 位的数值对应一个字符：
| 数值范围 | 对应字符 |
|---|---|
| 0-25 | A-Z |
| 26-51 | a-z |
| 52-61 | 0-9 |
| 62 | + |
| 63 | / |
| 填充 | = |
示例：编码 "Man"
来实操一下 "Man" 是怎么变成 "TWFu" 的：
原始数据: M a n
ASCII: 77 97 110
二进制: 01001101 01100001 01101110
重新分组: 010011 010110 000101 101110
十进制: 19 22 5 46
Base64: T W F u
结果: "TWFu"常见的 Base64 变体
- 标准 Base64：用 + 和 /，通用场景
- URL-safe Base64：+ 换成 -，/ 换成 _，去掉填充 =，能安全放在 URL 里
- MIME Base64：标准 Base64，但每 76 个字符加个换行
Base64 的常见应用场景
1. 电子邮件附件（MIME）
SMTP 协议最早只支持纯文本。为了让图片、文档能通过邮件传，MIME 标准就用 Base64 把附件编码成文本。
2. Data URI
前端性能优化里经常用到。小图片直接转成 Base64 嵌入 HTML 或 CSS，省一次 HTTP 请求：
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg...">3. JWT（JSON Web Token）
JWT 的三个部分（Header、Payload、Signature）全是用 URL-safe Base64 编码的。这就是为什么 JWT 看起来是一串由点和字母数字组成的字符串。
4. HTTP Basic 认证
HTTP Basic Auth 把用户名和密码拼起来，Base64 编码后塞进 Authorization 头里。
Base64 的优缺点
优点
- 兼容性极好——是系统就支持
- 实现简单，几分钟就能写出来
- 编码后的文本可读性还行
缺点
- 体积膨胀：编码后数据增加约 33%
- 不是加密：这是编码，不是加密，谁都能解码
- 不适合大文件：大文件编码后体积太大
重要提示：Base64 不是加密！敏感数据要先加密（比如 AES），再 Base64 编码传输。
使用在线工具箱的 Base64 工具
我们的 在线 Base64 编解码工具 支持：
- 文本与 Base64 互转
- 完美支持中文、Emoji 等 Unicode 字符
- 纯浏览器端处理，数据不会上传到服务器