Java 8的Base64类位于java.util.Base64，提供标准、URL安全和MIME三种编码器，推荐使用且无需第三方依赖，避免使用已移除的sun.misc.BASE64Encoder。
Java 8的Base64类在哪找、怎么用
Java 8起，java.util.Base64是标准库自带的唯一推荐方案，不用引第三方包。它分三类：标准编码（Base64.getEncoder()）、URL安全编码（Base64.getUrlEncoder()）、MIME编码（Base64.getMimeEncoder()）。别去翻sun.misc.BASE64Encoder——那是内部API，JDK 9+已移除，运行时可能直接NoClassDefFoundError。
常见错误现象：java.lang.NoClassDefFoundError: sun/misc/BASE64Encoder，尤其从老项目迁移时容易踩这个坑。
- 标准编码用于通用字符串/二进制转换，比如HTTP头里的token
- URL安全编码会把
+和/换成-和_，不加换行符，适合做URL参数或文件名 - MIME编码每76字符加
\r\n，仅在邮件或旧协议里需要，日常基本不用
encodeToString()和decode()的典型误用
最常犯的错是把字符串先new String(bytes)再编码——这会因平台默认编码（如Windows的GBK）破坏原始字节，导致解码失败。Base64操作的是字节，不是字符串。
正确做法永远基于byte[]：用String.getBytes(StandardCharsets.UTF_8)明确指定编码，解码后也用new String(byte[], StandardCharsets.UTF_8)还原。
立即学习“Java免费学习笔记（深入）”；
示例：
String original = "hello世界"; // ✅ 正确：显式UTF-8 byte[] encoded = Base64.getEncoder().encode(original.getBytes(StandardCharsets.UTF_8)); String b64 = new String(encoded, StandardCharsets.US_ASCII); byte[] decoded = Base64.getDecoder().decode(b64); String restored = new String(decoded, StandardCharsets.UTF_8); // "hello世界"
如果跳过StandardCharsets.UTF_8，中文在某些环境里直接变乱码，且无法恢复。
流式编解码（Base64.InputStream / OutputStream）的适用场景
大文件（比如几十MB的图片、PDF）别一次性读进内存再编码，用流式处理更稳。但要注意：这些包装流不自动close底层流，必须手动管理；而且它们只处理“纯”Base64数据，不跳过空白或换行——如果源数据含空格或\r\n（比如从邮件正文复制的Base64），会抛IllegalArgumentException: Illegal base64 character。
- 适合场景：上传文件前实时编码、下载时边解码边写磁盘
- 不适用场景：解析带注释或格式化过的Base64文本（得先clean掉非base64字符）
- 性能影响：流式比内存式略慢一点，但内存占用从O(n)降到O(1)，对大文件是刚需
和Apache Commons Codec或Bouncy Castle混用的风险
如果项目里同时存在org.apache.commons.codec.binary.Base64和java.util.Base64，别以为只是类名不同就没事。它们的默认行为有差异：Commons Codec的encodeBase64String()默认不换行，但它的Base64(true)构造器可开padding，而JDK的getUrlEncoder()默认无padding且不可关——混用会导致同一段字节编出不同结果，解码必然失败。
建议：新代码统一用JDK原生；老代码迁移时，逐个核对是否启用了padding、是否忽略换行、是否URL安全，别靠“看起来一样”就上线。
最容易被忽略的一点：JDK的getDecoder()对末尾填充字符=校验严格，少一个都会报IllegalArgumentException；而有些旧工具生成的Base64会省略padding（尤其前端JavaScript的btoa()在某些长度下不补=），这时得用Base64.getDecoder().withoutPadding()配合处理。
