Base64编码是二进制转ASCII文本的安全传输方案，Java的java.util.Base64类提供标准、URL-safe、MIME三种编码器，用于适配HTTP、URL、邮件等场景，但不提供加密或压缩功能。
Base64 编码解决了二进制数据在文本通道中安全传输的问题
Java 的 java.util.Base64 类不是为“加密”或“压缩”设计的，它的核心作用是把任意字节序列（比如图片、PDF、加密密文）转成仅含 ASCII 可见字符的字符串，从而能安全地放在 HTTP 请求体、JSON 字段、URL 参数、XML 内容、邮件正文等纯文本环境中传输，避免因编码不一致、控制字符截断、网络中间件误处理导致的数据损坏。
为什么不用自己手写 Base64 转换逻辑
手动实现容易出错，且忽略边界情况：
-
Base64.getEncoder()和Base64.getDecoder()已针对 JDK 8+ 做过充分测试，支持所有标准变体（MIME、URL-safe、纯 Base64） - 手动处理填充字符（
=）、换行符（MIME 模式下的\r\n）、非法字符容忍（如解码时跳过空格）极易遗漏 - JDK 实现底层使用查表+位运算，性能远超多数手写循环拼接方案；实测 1MB 数据编码，JDK 版本比常见手写 loop 快 3–5 倍
三种 Encoder/Decoder 工厂方法的区别和选型建议
别直接用 Base64.getEncoder()——它默认是标准 Base64（含 +、/、=），在 URL 或文件名里会出问题：
- 传参场景用
Base64.getUrlEncoder()：把+→-，/→_，省略填充（无=），适合 JWT、URL 查询参数、Redis 键名 - 邮件或附件场景用
Base64.getMimeEncoder()：自动按 76 字符折行 +\r\n，并保留填充，符合 RFC 2045 - 通用存储/日志场景用
Base64.getEncoder()：最兼容，但注意接收方是否支持填充和换行
示例：
String encoded = Base64.getUrlEncoder().encodeToString("hello".getBytes(StandardCharsets.UTF_8)); // 输出 aGVsbG8
立即学习“Java免费学习笔记（深入）”；
解码失败的常见原因和排查点
抛 IllegalArgumentException: Illegal base64 character 或 ArrayIndexOutOfBoundsException 通常不是数据被篡改，而是编码方式不匹配：
- 发送端用了
getUrlEncoder()，接收端却用getDecoder()解——URL-safe 字符（-/_）会被当成非法字符 -
前端 JavaScript 用
btoa()编码（不支持 UTF-8 多字节），后端 Java 直接 decode 含中文的字符串，会因字节序列不合法崩溃 - 从 JSON 中读取 Base64 字符串时，JSON 库自动去除了末尾的
=填充（尤其某些移动端 SDK），需手动补足到长度是 4 的倍数再解码
安全做法是：统一约定编码类型，并在解码前校验字符串长度模 4 是否为 0，不足则补 =。
"你好".getBytes(StandardCharsets.UTF_8) 而非裸调 getBytes()），否则跨环境运行时默认编码差异会让 Base64 结果完全不可逆。 
