Base64.getMimeEncoder() 默认每76字符插入\r\n，导致JSON/HTTP等场景解析失败；应改用Base64.getEncoder()或手动去除换行，解码时需匹配编码方式，避免Illegal base64 character错误。
Base64.getMimeEncoder() 编码后换行导致解析失败
Java 的 Base64.getMimeEncoder() 默认每 76 字符插入一个 \r\n，这在 HTTP 头、JSON 字段或 URL 参数里会直接破坏数据结构。MIME 标准要求换行，但很多下游系统（比如某些 REST API、JWT payload、配置中心）根本没按 MIME 规范做解码，一遇到 \r\n 就报 IllegalArgumentException: Illegal base64 character d 或解析截断。
解决方法很简单：用 Base64.getMimeEncoder().withoutPadding() 不能去换行，得用 Base64.getEncoder() 替代——但它不带 MIME 换行，也不带填充控制；真要严格 MIME 兼容又不想换行，只能自己 wrap：
Base64.Encoder mimeNoWrap = new Base64.Encoder() {
private final Base64.Encoder delegate = Base64.getMimeEncoder();
public String encodeToString(byte[] src) {
return delegate.encodeToString(src).replace("\r\n", "");
}
// 其他方法同理委托，但多数场景只用到 encodeToString
};
- 如果只是传给浏览器或标准邮件库，保留
\r\n没问题；但凡走 JSON / HTTP body / 日志埋点，先去掉 -
withoutPadding()只影响末尾=，对换行完全无效——这是最常见的误解 - JDK 8+ 才有
getMimeEncoder()，JDK 7 项目别硬套，用javax.mail.internet.MimeUtility更稳
decode() 报 IllegalArgumentException: Illegal base64 character
这个错八成不是数据坏了，而是你用了 Base64.getMimeDecoder() 去解一个没换行的字符串（比如前端 JS 的 btoa() 结果，或 Base64.getEncoder() 编的）。MIME 解码器会严格检查换行位置，遇到非预期字符（如中间突然出现字母而非 \r\n）就炸。
实际做法是：别预设编码方用了 MIME，先看原始字符串有没有 \r\n。没有的话，直接切到 Base64.getDecoder()：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
String raw = "SGVsbG8gV29ybGQ="; // 无换行 byte[] decoded = Base64.getDecoder().decode(raw); // ✅
-
Base64.getMimeDecoder()要求输入严格符合 MIME 行宽 + CRLF，哪怕多一个空格都可能触发异常 - 前后端约定不清时，宁可用
getDecoder()，它更宽容（跳过空白、忽略非法字符位置） - 日志里看到
Illegal base64 character a（a 是十六进制 0x61），说明解码器在第 N 位遇到了字母，但它预期那里该是\r或\n
MIME encoder 的 lineLength 和 lineSeparator 参数不可配
有人翻源码想改每行长度或换行符为 \n，结果发现 Base64.getMimeEncoder() 没提供构造参数。这是 JDK 故意锁死的：RFC 2045 明确规定 MIME Base64 必须是 76 字符/行 + \r\n，所以 JDK 实现不给你动——不是忘了加，是不能加。
- 需要自定义行宽？用
Base64.getEncoder()+ 手动分段 + 插入换行（但这就不是 MIME 了） - 想用
\n替代\r\n？MIME 标准不认，部分老邮件服务器会静默丢弃整行 - 如果必须兼容某私有协议（比如某 IoT 设备只要求 64 字符+
\n），别碰 MIME encoder，老实用getEncoder()自己格式化
和 Apache Commons Codec 的 Base64 对比容易踩内存坑
Commons Codec 的 Base64.encodeBase64String() 默认不换行，行为接近 JDK 的 getEncoder()；但它的 encodeBase64Chunked() 才对应 MIME。混用时最常出问题的是：把 Commons 编的 chunked 字符串，拿 JDK 的 getMimeDecoder() 去解——看似都叫 “MIME”，但 Commons 的 chunked 默认用 \n，而 JDK 要 \r\n，解着解着就崩。
- 同一项目里别同时引两个 Base64 实现，选一个统一到底
- 如果必须共存，解码前先 normalize 换行：
str.replace("\n", "\r\n")，但注意别把原本就合法的\r\n变成\r\r\n - Commons Codec 1.15+ 加了
Base64Codec类支持 RFC 2045，但默认仍不启用，得显式传new Base64(true, null, true)（第三个 true 表示 lineBreaks）
