URLEncoder.encode()乱码的根本原因是默认使用ISO-8859-1编码，而中文字符串实际为UTF-8字节流，必须显式指定"UTF-8"字符集；解码时也需严格匹配编码字符集，且Spring等框架已自动处理@RequestParam等参数的UTF-8解码，重复解码会导致乱码。
Java里URLEncoder.encode()为什么总出乱码
根本原因是它默认按ISO-8859-1编码，而你传入的中文字符串实际是UTF-8字节流，不显式指定字符集就会把UTF-8字节当ISO-8859-1解析，结果就是乱码。
必须强制指定UTF-8——这是唯一靠谱的做法：
String encoded = URLEncoder.encode("你好", "UTF-8"); // ✅ 正确
常见错误包括：
- 漏写第二个参数，用
URLEncoder.encode(String)重载（已废弃，且默认ISO-8859-1） - 传错字符集名，比如写成
"utf8"或"UTF8"（必须是"UTF-8"） - 在Web容器里混用不同编码上下文（如Tomcat默认用ISO-8859-1解URL，需额外配置）
URLDecoder.decode()解码失败的典型场景
解码失败往往不是函数本身问题，而是前后端编码不一致导致的“错配”。比如前端用encodeURIComponent("中文")（UTF-8），后端却用URLDecoder.decode(s, "ISO-8859-1")去解。
立即学习“Java免费学习笔记（深入）”；
实操要点：
- 解码时字符集必须和编码时完全一致，通常是
"UTF-8" - 如果原始字符串来自HTTP请求（如GET参数），要确认Servlet容器是否已帮你做过一次解码（Tomcat 8+默认对query string自动UTF-8解码，再调用
URLDecoder.decode()就可能二次解码出错） - 遇到
IllegalStateException: URLDecoder: Incomplete trailing escape (%)，说明输入含残缺的%xx序列，需先校验或过滤非法输入
别直接用URLEncoder拼接URL路径
URLEncoder设计目标是编码表单数据（application/x-www-form-urlencoded），它会把空格转成+、斜杠/转成%2F等。但如果你在构造URL路径（比如https://api.com/user/张三），这些转换会让路径语义失效。
正确做法：
- 只对路径中「参数值」部分单独编码，比如
name=张三里的张三 - 路径分隔符
/、冒号:、问号?等保留字符不能被URLEncoder处理 - 更安全的选择是用
java.net.URI构造器：URI uri = new URI("https", "api.com", "/user/" + URLEncoder.encode("张三", "UTF-8"), null);它会自动处理各部分的合法编码边界
Spring Boot里参数自动解码的坑
Spring MVC默认对@RequestParam和@PathVariable做了一次UTF-8解码，所以你通常不需要手动调用URLDecoder.decode()。手动再解一次，就会把已经解好的中文又按UTF-8重新解释一遍字节，结果变成乱码。
怎么判断要不要自己解？
- 如果参数来自
@RequestParam或@PathVariable，直接用，别碰URLDecoder - 如果参数来自
HttpServletRequest.getQueryString()或getRawParameterMap()这类“原始字符串”，才需要自己解码 - 检查
server.tomcat.uri-encoding配置（默认UTF-8），避免和Spring行为冲突
最常被忽略的是：你以为自己在解码，其实框架早就替你做了；而你以为框架没做，结果自己多解了一次。这个边界不厘清，乱码问题永远反复出现。
