Java中Base64编码应使用JDK 8+内置Base64.getEncoder().encodeToString()，线程安全且无需依赖；URL安全场景用getUrlEncoder().withoutPadding()；解码后需按原始编码（如UTF-8）转字符串，不可直接new String(byte[])；避免手动拼接、错误字符集处理及误当加密使用。
Java里用Base64类编码二进制数据，直接调Base64.getEncoder().encodeToString()就行
这是最常用、最安全的路径。JDK 8+ 自带，无需额外依赖，且线程安全。别自己手写查表或引入老版本Apache Commons Codec——容易漏掉填充、换行、字符集问题。
-
encodeToString()返回的是标准MIME格式字符串（含=填充，无换行），适合HTTP头、URL参数、JSON字段 - 如果要URL安全（比如JWT payload），得用
Base64.getUrlEncoder()，它把+和/换成-和_，且默认不填充（需手动加.withoutPadding()才彻底干净） - 别用
new String(bytes, "UTF-8")去“强行转”二进制为字符串——字节序列可能含非法UTF-8码点，解码时直接抛MalformedInputException
解码失败常见报错：IllegalArgumentException: Illegal base64 character
这基本等于输入字符串被污染了：多了空格、换行、HTML实体（如+代替+）、或用了非标准字符集编码（比如前端用btoa()但后端没按ASCII处理）。
- 先
trim()再解码，干掉首尾空白和\r\n - 确认来源：JS的
btoa()输出是ASCII兼容的，但若原始字符串含中文，必须先encodeURIComponent再btoa，否则Java端解码会错位 - 如果数据来自表单或URL，检查是否被Web容器自动URL解码过一次又解一次——比如
%2B变成+再被当成Base64字符，但实际该位置应是-
Base64.Decoder.decode()返回byte[]，不是String
很多人卡在这步：以为解码完就能当文本用，结果打印出来是乱码或[B@xxxxx。解码结果只是原始字节，还得按原始编码还原成字符串——而这个编码信息，Base64本身不保存。
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 如果原始数据是UTF-8文本，解码后要显式调
new String(decodedBytes, StandardCharsets.UTF_8) - 如果原始是图片、ZIP、加密密文等二进制内容，就别转
String，直接拿byte[]喂给ImageIO.read()、ZipInputStream或Cipher - 误用
new String(decodedBytes)（无参构造）会触发平台默认编码，在Linux/macOS常是UTF-8，Windows可能是GBK，一换环境就出错
性能和兼容性：别在循环里反复调Base64.getEncoder()
这个方法每次调用都新建一个实例，虽然轻量，但高频场景（比如日志脱敏、消息体编解码）下GC压力明显。而且getEncoder()和getUrlEncoder()返回的对象都是无状态的，完全可以复用。
立即学习“Java免费学习笔记（深入）”；
- 声明为
private static final Base64.Encoder URL_SAFE_ENCODER = Base64.getUrlEncoder().withoutPadding(); - JDK 8起支持流式编解码：
encoder.encode(InputStream)，适合大文件，避免一次性加载全部字节到内存 - Android API 26+才完整支持
Base64类；低于此版本必须用android.util.Base64，两者API相似但不完全兼容（比如NO_WRAP对应withoutPadding()）
