Java 8+ 推荐使用 java.util.Base64，提供标准、URL安全和MIME三类编码器；编码需显式指定UTF-8字符集，解码失败多因输入含空白、URL编码或长度非4倍数；withoutPadding()去除填充符=，适用于URL/Token场景；与Apache Commons Codec混用需注意填充、换行及严格性差异。
Java 8+ 自带的 Base64 类怎么用
Java 8 开始，java.util.Base64 是官方推荐、无需引入第三方库的标准方案。它提供三类编码器：getEncoder()（标准 Base64）、getUrlEncoder()（URL 安全，用 - 和 _ 替代 + 和 /）、getMimeEncoder()（带换行符，每 76 字符断行，符合 MIME 规范）。
最常用的是标准编码：
String original = "Hello World"; String encoded = Base64.getEncoder().encodeToString(original.getBytes(StandardCharsets.UTF_8)); // 结果：SGVsbG8gV29ybGQ=
注意：encodeToString() 接收 byte[]，不是字符串；必须显式指定字符集（如 UTF_8），否则依赖平台默认编码，跨环境易出错。
解码时抛 IllegalArgumentException: Input is not valid base64 怎么办
这个错误几乎都源于输入数据不合法 —— 常见原因不是“写法错”，而是“来源脏”。比如前端传来的 Base64 字符串可能被 URL 编码过（+ 变成空格、/ 被转义）、或混入换行/空格、或长度不对（Base64 长度必须是 4 的倍数）。
立即学习“Java免费学习笔记（深入）”；
- 先做基础清洗：
input.replaceAll("[\\s]", "")去掉所有空白 - 若来自 HTTP 请求，检查是否被自动 URL 解码过；如果是 URL 安全格式，改用
Base64.getUrlDecoder() - 校验长度：若长度 % 4 != 0，补足
=（但要小心，盲目补可能掩盖真实问题）
安全做法是捕获异常并记录原始输入，方便排查源头问题。
Base64.Encoder 的 withoutPadding() 有什么实际影响
默认编码结果末尾可能带一个或两个 =（填充符），用于对齐长度。调用 Base64.getEncoder().withoutPadding() 会去掉它们。
这在某些场景下必要：
- 生成 token 或签名参数时，避免
=在 URL 或 HTTP Header 中引发解析歧义 - 与某些旧系统对接，对方不接受填充符
但要注意：解码时必须用对应无填充的解码器（Base64.getDecoder() 默认支持有/无填充；但如果对方也用了 withoutPadding() 编码，你用标准解码器仍能正确处理，无需配对）。
和 Apache Commons Codec 的 Base64 混用会出问题吗
会，尤其在填充、换行、URL 安全性上行为不一致。例如：
- Apache 的
Base64.encodeBase64String()默认不换行，但它的encodeBase64()（返回byte[]）默认启用换行；JDK 的getMimeEncoder()才加换行 - Apache 的
Base64.encodeBase64URLSafeString()用-/_，但 JDK 的getUrlEncoder()行为完全等价 —— 这部分可互换 - 最关键：Apache 3.x 以前版本对非标准填充容忍度更高（比如多几个
=也能解），而 JDK 解码器更严格
结论：新项目直接用 JDK Base64；老项目迁移时，重点比对编码输出是否完全一致，特别是含特殊字符或二进制数据时。
真正容易被忽略的是：不同 JDK 版本对非法输入的容忍度略有差异，JDK 17 比 JDK 8 更严格，线上升级前务必用真实数据回归测试。
