Base64是一种二进制数据编码规范而非加密，将任意字节流转换为64个ASCII字符组成的字符串，以适配纯文本传输通道，解决控制字符和高位字节在SMTP、HTTP头、URL等场景中的兼容性问题。

Base64不是加密，而是一种为适配纯文本传输通道所设计的二进制数据编码规范。它的核心作用是把任意字节流（比如图片、证书、音频）转换成仅含64个可打印ASCII字符的字符串，从而在只支持文本的协议中可靠传递二进制内容。

为什么网络传输需要Base64

早期互联网协议（如SMTP邮件协议、HTTP头部、URL路径、Cookie、XML/JSON字段）默认只接受ASCII可见字符（0x20–0x7E）。而原始二进制数据常含控制字符（如\x00–\x1F）、高位字节（\x80–\xFF），这些在传输中易被截断、误解析或被中间代理过滤。Base64通过限定输出字符集，规避了这类兼容性风险。

• SMTP邮件正文不支持\x0A以外的换行或\x00字节，附件必须转为Base64再用MIME封装
• HTTP请求头（如Authorization）禁止非ASCII和空格，Basic认证凭据需Base64编码后填入
• URL路径中“+”“/”“=”有特殊语义，标准Base64需配合URL安全变种（-代替+，_代替/，省略=）才可直接嵌入

标准Base64编解码的核心规则

编码过程严格遵循RFC 4648：

• 以3字节（24位）为一组，拆分为4段6位二进制数
• 每段6位查表映射：A-Z（0–25）、a-z（26–51）、0-9（52–61）、+（62）、/（63）
• 若输入长度不足3字节，末尾补0比特凑整；补1字节补两个“=”，补2字节补一个“=”
• 编码后字符串长度必为4的倍数，体积膨胀约33%（4/3倍）

解码时按相反流程还原：忽略非Base64字符（如换行、空格），校验等号数量，去除填充后恢复原始字节流。

主流应用场景与对应规范要求

不同场景对Base64使用有明确约束，不能混用：

• MIME邮件附件：必须使用标准Base64（含+、/、=），且每76字符强制换行（CRLF），头部声明Content-Transfer-Encoding: base64
• HTTP Basic认证：用户名:密码拼接后Base64编码，不得含换行或空格，填入Authorization: Basic <encoded>
• Data URL内嵌资源：HTML/CSS中使用data:<mime>;base64,<string>格式，编码后字符串不可换行，不加空格
• JWT Token：必须采用URL安全Base64（Base64url），即+→-、/→_、省略=填充，确保Token可直接放在URL、Cookie或HTTP头中
• API JSON字段传文件：前端读取File对象生成Base64字符串，后端解码时需严格校验等号位置与字符合法性，防止注入

常见误区与实践提醒

Base64常被误当作安全手段，实际它完全不提供保密性或完整性保护：

• 编码结果可被任何人轻易解码，敏感数据（如密码、密钥）必须先加密再Base64
• 大文件（如>1MB图片）Base64编码后体积增大、解析开销高，应优先使用multipart/form-data等原生二进制方式
• 数据库存储时，若字段类型为TEXT，Base64可行；但BLOB类型更高效，避免无谓转换
• JavaScript中btoa() / atob()仅支持Latin-1字符，处理Unicode字符串需先转UTF-8字节数组再编码