base64.geturlencoder()生成url安全编码，字符集为a-za-z0-9-_，不含+、/，但默认保留=填充；需显式调用withoutpadding()才能彻底去除=，确保与python、go等语言兼容。
Java里用Base64.getUrlEncoder()生成URL安全编码
直接说结论：它能生成不含 +、/、= 的字符串，适合拼在URL路径或查询参数里，不用再手动替换或URLEncoder。但默认不带“无填充”（no-padding）行为，=仍可能出现——这点很多人忽略。
为什么Base64.getUrlEncoder()比Base64.getEncoder()更适合URL场景
Base64.getEncoder()输出含 + 和 /，在URL里会被误解析为分隔符或路径层级；=在查询参数末尾还可能被某些网关截断。而getUrlEncoder()把 + 换成 -、/ 换成 _，字符集完全属于URL安全子集（A-Za-z0-9-_）。
不过注意：getUrlEncoder()默认仍保留填充字符 =。如果你往GET参数里塞编码结果，比如 ?token=abcd123=，部分老Nginx配置或移动端WebView会把末尾等号吃掉——这时候就得自己去掉填充。
- 需要彻底无符号？用
Base64.getUrlEncoder().withoutPadding() - 只用于路径段（如
/api/v1/user/SGVsbG8=）？带填充一般没问题 - 用于HTTP Header（如
Authorization: Bearer ...）？推荐加withoutPadding()，更稳妥
getUrlEncoder()和getMimeEncoder()混用会解码失败
编码和解码必须配对。用getUrlEncoder()编码的，必须用Base64.getUrlDecoder()解码。如果错用Base64.getDecoder()，遇到 - 或 _ 就直接抛 IllegalArgumentException: Illegal base64 character。
立即学习“Java免费学习笔记（深入）”；
常见错误现象：
- 后端用
getUrlEncoder()发 token，前端用 JS 的btoa()试图解码 → 失败，因为字符映射不同 - Spring Boot 接口接收参数时没指定解码器，直接用
Base64.getDecoder().decode(input)→ 报错 - 混淆了
getUrlEncoder().withoutPadding()和getMimeEncoder().withoutPadding()→ 解码时长度校验失败
实际编码示例与边界注意点
下面这段代码看着简单，但几个细节决定是否真能“无特殊符号”：
String raw = "hello world!"; // ✅ 正确：URL安全 + 无填充 String encoded = Base64.getUrlEncoder().withoutPadding().encodeToString(raw.getBytes(StandardCharsets.UTF_8)); // ❌ 错误：没去填充，结尾可能有 = String encodedBad = Base64.getUrlEncoder().encodeToString(raw.getBytes(StandardCharsets.UTF_8)); // ❌ 错误：用了普通encoder，含+和/ String encodedWorse = Base64.getEncoder().encodeToString(raw.getBytes(StandardCharsets.UTF_8));
性能上没差别，但兼容性要看下游：Python 的 base64.urlsafe_b64encode() 默认无填充；Go 的 encoding/base64.URLEncoding 也默认无填充。Java这边不显式调用 withoutPadding()，就和它们不一致。
真正容易被忽略的是：空字符串、单字节、中文字符这些边界输入，getUrlEncoder() 行为完全正常，但如果你自己写了替换逻辑（比如先用getEncoder()再.replace('+', '-').replace('/', '_')），就可能漏掉填充处理或破坏字节对齐——别手写，就用原生getUrlEncoder()。
