Base64.getMimeDecoder() 自动忽略 MIME Base64 中的空格、制表符、CR/LF 等合法空白字符，无需预处理；应直接传入原始字符串，仅需校验长度是否为4的倍数，并区分 RFC 2045（MIME）与 RFC 4648（标准）场景。
Base64.getMimeDecoder() 本身就能自动忽略 MIME Base64 编码中合法的空白字符（包括空格、制表符、回车、换行），无需手动预处理。关键在于理解它的设计契约和边界情况。
明确 MIME 解码器的行为边界
Java 的 Base64.getMimeDecoder() 严格遵循 RFC 2045，允许在编码数据中出现以下字符并自动跳过：
- ASCII 空格（U+0020）
- 水平制表符（U+0009）
- CR（U+000D）和 LF（U+000A），包括 CRLF 组合
- 这些字符可出现在任意位置（开头、中间、结尾），只要不破坏 4 字符分组结构
例如，下面三段输入解码结果完全相同：
"SGVsbG8=" "SGVs bG8=" " S G V s b G 8 = "
避免常见误操作
不要在调用 decode 前对字符串做 trim() 或正则替换——这可能误删有效填充符或引入逻辑漏洞：
sc-java-to-ts-interface
下载
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
立即学习“Java免费学习笔记（深入）”；
-
错误做法：
s.trim().replaceAll("[\s&&[^=]]", "")—— 可能误删等号前的空格（虽罕见但合法），且破坏原始格式语义 - 正确做法：直接传入原始字符串，让 MimeDecoder 自行处理
- 若输入来自不可信来源（如用户粘贴、邮件正文），需先校验长度是否为 4 的倍数（含等号），否则抛出
IllegalArgumentException
鲁棒解码的推荐写法
封装一个安全解码方法，兼顾空值、格式异常与语义清晰：
public static byte[] decodeMimeSafe(String encoded) {
if (encoded == null || encoded.trim().isEmpty()) {
return new byte[0];
}
try {
return Base64.getMimeDecoder().decode(encoded);
} catch (IllegalArgumentException e) {
throw new IllegalArgumentException("Invalid Base64 MIME input: " + e.getMessage(), e);
}
}
该方法不清洗输入，而是信任 MimeDecoder 的内置容错能力，并将底层异常转为语义明确的错误提示。
注意非 MIME 场景的混淆
如果数据实际是标准 Base64（RFC 4648），而非 MIME 格式（如 HTTP 头、邮件体），应改用 Base64.getDecoder()。后者也忽略空白，但对换行位置无 MIME 那样的“每 76 字符换行”隐含约定。混用虽常能工作，但语义不准确，易在后续维护中引发误解。
