Base64.getUrlEncoder()生成URL安全Base64编码，用-替换+、_替换/，默认保留=填充，需链式调用withoutPadding()才能彻底去除=，且必须配套使用getUrlDecoder()解码。
Base64.getUrlEncoder() 不能直接用于 URL 参数编码
它不是为“URL 参数”设计的，而是为「URL 安全 Base64 编码」设计的——即避免 +、/ 和 = 这些在 URL 中有特殊含义的字符。但你如果拿它去编码一个原始 URL 参数（比如 "q=hello world&sort=desc"），结果依然可能出问题：它不处理空格、&、=、? 等 URL 保留字符，只做 Base64 层面的字符替换。
真正安全的 URL 参数编码，应该先做 URLEncoder.encode(..., "UTF-8")，再考虑是否需要进一步 Base64 化（例如隐藏原始结构或统一长度）。
-
Base64.getUrlEncoder()输出的是 Base64 字符串，不是 URL-safe 的原始参数值 - 它不会把空格转成
%20，也不会对&做任何转义 - 如果你把
getUrlEncoder().encodeToString("a b&c=d".getBytes())的结果拼进 URL，接收端不按 Base64 解码就完全无法还原
什么时候才该用 Base64.getUrlEncoder() 处理 URL 参数
典型场景是：你**有意隐藏参数语义**，或需要把一段二进制/非 ASCII 数据（如加密后的字节、JSON 序列化后的 byte[]）塞进 URL，且要求 URL 可读、无歧义、不被中间代理截断或误解析。
- 例如：生成带签名的短链 token：
"token=" + Base64.getUrlEncoder().encodeToString(signedBytes) - 再如：将加密后的 JSON 对象（含中文、emoji、控制字符）作为单个参数传递：
?payload=xxx...，此时原始 JSON 必须先序列化为 UTF-8 字节数组，再用getUrlEncoder() - 注意：必须配套使用
Base64.getUrlDecoder().decode(...)，否则接收端无法还原
正确组合：先 UTF-8 字节数组，再 getUrlEncoder()
关键点在于「输入必须是原始语义的字节表达」，而不是字符串本身。常见错误是直接 encode 字符串对象，忽略编码一致性。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
String original = "姓名=张三&城市=北京";
// ✅ 正确：转为 UTF-8 字节，再 Base64 URL 安全编码
String encoded = Base64.getUrlEncoder()
.encodeToString(original.getBytes(StandardCharsets.UTF_8));
// ❌ 错误：直接 encode 字符串（会用平台默认编码，Windows 上可能是 GBK）
String bad = Base64.getUrlEncoder().encodeToString(original.getBytes());
- 务必显式指定
StandardCharsets.UTF_8，否则跨环境行为不一致 - 输出中不含
+、/、=（末尾填充用-和_替代） - 若需去除末尾填充（比如某些 JWT 场景），可用
Base64.getUrlEncoder().withoutPadding()
解码端必须严格对应，且注意异常处理
URL 参数可能被浏览器自动解码一次（如把 %2B 变成 +），也可能被反向代理二次 decode，所以接收到的 Base64 字符串里如果出现 + 或 /，大概率已损坏 —— 这时 getUrlDecoder().decode(...) 会抛 IllegalArgumentException。
- 接收时建议先用
URLDecoder.decode(param, "UTF-8")恢复原始 URL 编码，再交给 Base64 解码 - 必须包裹 try-catch，因为网络传输或手动拼接容易引入非法字符
- 示例片段：
try { byte[] decoded = Base64.getUrlDecoder().decode( URLDecoder.decode(receivedParam, "UTF-8") ); String original = new String(decoded, StandardCharsets.UTF_8); } catch (IllegalArgumentException | UnsupportedEncodingException e) { // 记录日志，拒绝该请求 }
最易被忽略的是：你以为传过去的是干净的 Base64 字符串，但中间某层代理悄悄做了 URL decode，把 _ 当普通字符放过，却把 %2F 转成了 /，导致 Base64 解码失败 —— 这类问题只能靠服务端防御性校验和清晰的日志定位。
