关键不是“怎么解”，而是“要不要解”和“在哪解”：tomcat 8+等主流容器默认对query string执行utf-8解码，request.getparameter()已返回正确中文，重复调用urldecoder.decode()会导致二次解码乱码；仅在手动解析原始url字符串等非标准场景才需显式解码，且必须指定"utf-8"。
Java 处理 HTTP 请求参数中乱码的 URL 解码，关键不是“怎么解”，而是“要不要解”和“在哪解”。多数乱码问题其实源于重复解码、编码不匹配或在不该动手的地方手动干预。
先确认：Servlet 容器是否已自动解码
Tomcat 8+、Jetty、Undertow 等主流容器默认对 query string（即 ? 后面的参数）执行 UTF-8 解码。也就是说，调用 request.getParameter("name") 返回的已经是解码后的中文字符串，无需再套一层 URLDecoder.decode(..., "UTF-8")。
- ✅ 正确做法：直接使用
request.getParameter("q")→ 得到 "张三" - ❌ 常见错误：写成
URLDecoder.decode(request.getParameter("q"), "UTF-8")→ “张三”变成乱码（二次解码） - ⚠️ 注意：若 Tomcat 配置了
URIEncoding="ISO-8859-1"（旧版默认），则需在server.xml的<connector></connector>中显式设为URIEncoding="UTF-8"
只在手动解析原始 URL 字符串时才需 URLDecoder
当你拿到的是原始请求行（比如用 ServerSocket 自己解析 HTTP）、或从 header、cookie、重定向地址等非标准位置提取的编码字符串时，才需要主动解码。
Java Development Manual
下载
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
- 例如：从
request.getRequestURL().toString()+request.getQueryString()拼出完整 URL 字符串后想拆参数，就得先对 query 部分解码 - 解码必须指定字符集：
URLDecoder.decode(encodedValue, "UTF-8") - 别用单参数方法
URLDecoder.decode(s)—— 已废弃，且默认 ISO-8859-1，中文必乱 - 建议封装工具方法，统一捕获
UnsupportedEncodingException和IllegalArgumentException（如遇到残缺 %xx）
避免前端与后端编码错配
乱码常是前后端“各编各的”导致的：
- 前端用
encodeURI("https://a.com/张三")编整个 URL → 后端却只对参数值解码 → 路径语义丢失 - 前端用
encodeURIComponent("张三")（正确），但后端用URLDecoder.decode(s, "GBK")→ 解错字节流 - 解决方案：前端始终用
encodeURIComponent()编参数值；后端坚持用"UTF-8"解；路径中的中文交给框架（如 Spring MVC）或java.net.URI处理
Spring Boot 等框架的额外注意点
Spring 默认对 @RequestParam、@PathVariable 参数已做 UTF-8 解码，但有两点易踩坑：
- 若 Controller 方法里又调用了
URLDecoder.decode()→ 双重解码 → 乱码 - GET 请求路径含中文（如
/user/张三），需确保 Tomcat 或 Web 容器配置了 URI 编码，或改用@PathVariable+ 框架自动处理 - 推荐：用
UriComponentsBuilder构造带中文参数的 URL，它会按 RFC 规范分段编码，比手拼安全得多
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
