Base64.getMimeEncoder() 不能直接 encode 长文本是因为其默认每行76字符并添加CRLF换行，易在HTTP头或JSON中引发解析错误；应使用wrap()配合OutputStream流式处理以确保换行合规、padding完整且不破坏多字节序列。
Base64.getMimeEncoder() 为什么不能直接 encode 长文本？
因为 Base64.getMimeEncoder() 默认每行最多 76 字符，末尾加 \r\n，且不自动换行——它只在你调用 encode() 或 wrap() 时才按规则截断。如果你传入一个超长 byte[] 直接 encode()，它确实会输出带换行的 MIME 兼容 Base64，但问题常出在「后续处理」：比如拼到 HTTP Header 里被当成多行、或被某些老旧解析器误切。
- 它不是“流式编码器”，不会边读边写；一次
encode()就吐出完整带换行的byte[] - 换行符是
\r\n（CRLF），不是\n，这点在 Unix 环境下容易引发隐性兼容问题 - 如果你手动拼接多个
encode()结果，中间的\r\n可能破坏语义（比如嵌入 JSON 的data:URI）
如何安全地对 >10KB 文本做 MIME Base64 编码？
别依赖一次性 encode()，尤其当目标是嵌入邮件体、HTTP 头或 MIME multipart body 时。正确做法是用 wrap() 配合 OutputStream，把编码过程交给它控制换行节奏。
- 先用
Base64.getMimeEncoder().wrap(outputStream)获取一个包装流 - 把原始字节写进这个包装流（
wrappedOut.write(bytes)），它会自动分块、加\r\n、不截断 UTF-8 多字节序列 - 务必调用
wrappedOut.close()，否则末尾的 padding（=）可能丢失 - 避免用
String.getBytes(StandardCharsets.UTF_8)前不校验内容——含 BOM 或代理对的字符串可能导致编码后长度异常
ByteArrayOutputStream baos = new ByteArrayOutputStream();
try (OutputStream encoded = Base64.getMimeEncoder().wrap(baos)) {
encoded.write("大段中文+emoji?".getBytes(StandardCharsets.UTF_8));
}
byte[] result = baos.toByteArray(); // 含正确 \r\n 和 padding
encode() vs wrap()：什么时候该选哪个？
encode() 是纯函数式，适合短文本（wrap() 是流式适配器，专为 MIME 协议栈设计，强制遵守 RFC 2045 第 6.8 节的 76 字符/行限制。
- 用
encode()：调试打印、生成一次性 token、存配置项（如application.properties中的密钥） - 用
wrap()：构造邮件正文、拼接 multipart body、写入 HTTPContent-Transfer-Encoding: base64字段 - 注意：
encode()返回的byte[]不包含末尾换行；wrap()写出的流一定以\r\n结尾（除非输入为空） - 两者都不处理输入 null —— 传 null 会直接抛
NullPointerException，得自己 guard
常见错误：MIME Base64 解码失败的三个隐藏原因
不是编码错，而是编码结果被二次污染。最典型的是：换行符被中间件吞掉、空格被 trim、或 base64 字符集被转义。
立即学习“Java免费学习笔记（深入）”；
- HTTP 客户端（如 OkHttp）默认 strip header 中的多余空白，导致
\r\n消失 → 解码器收到连续长串，报IllegalArgumentException: Illegal base64 character - 日志框架（如 Logback）对字段值做自动截断或 escape，把
+变成%2B→ 解码前没还原 - 前端 JS 用
btoa()解码时，传入含 Unicode 的字符串（而非 byte[]）→ 实际走的是 Latin-1 编码路径，和 Java 的 UTF-8 编码不匹配
真正麻烦的从来不是怎么编，而是编完之后，谁动了那几行 \r\n，以及谁悄悄替换了 =。
