URLDecoder 解码乱码的核心原因是编码与解码字符集不一致，需明确原始编码（如 UTF-8、GBK 或 ISO-8859-1）并显式指定 charset 解码，避免依赖默认行为，同时前后端应统一约定 UTF-8 编码规范。
URLDecoder 解码时出现乱码，核心原因是编码与解码使用的字符集不一致。默认使用 UTF-8，但若原始字符串是用 GBK、ISO-8859-1 等其他编码 URL 编码的，直接 decode 就会出错。
明确原始编码再解码
不能依赖 URLDecoder 的默认行为。需先确认前端或上游系统对参数做了哪种编码（常见于老系统或某些浏览器环境）：
- Java 后端接收请求参数时，可通过 request.getCharacterEncoding() 查看当前请求编码（但该值可能为 null，实际取决于容器配置）
- 前端 JavaScript 使用 encodeURI 或 encodeURIComponent 时，本质是 UTF-8 编码，对应后端应统一用 UTF-8 解码
- 若遇到类似
%C4%E3这类双字节十六进制串，且解码后是中文乱码（如“浣”变成“Äã”），大概率是 GBK 编码后被当 UTF-8 解了
手动指定字符集解码（推荐做法）
避免使用 URLDecoder.decode(String s) 无参方法。改用带 charset 的重载：
-
UTF-8 场景（现代主流）：
URLDecoder.decode(s, "UTF-8") -
GBK 场景（部分旧系统）：
URLDecoder.decode(s, "GBK") -
兜底 ISO-8859-1（常用于 Tomcat 早期默认）： 若参数经多次错误解码已损坏，有时需先按 ISO-8859-1 原样还原字节，再转 UTF-8：
new String(s.getBytes("ISO-8859-1"), "UTF-8")—— 注意这不是 URLDecode，而是绕过误解码的补救
前后端约定优先，避免临时修复
乱码本质是协作断层。与其在后端不断猜测编码，不如固化规范：
- 所有 API 接口文档明确要求：查询参数、表单提交、JSON 字符串中的键值，统一使用 UTF-8 编码后进行 URL 编码
- Spring Boot 项目可在
application.properties中设server.servlet.encoding.charset=UTF-8和server.servlet.encoding.force=true - 前端 fetch 或 axios 发送请求前，确保字符串先经
encodeURIComponent()处理，它内部就是 UTF-8 编码逻辑
调试时快速验证编码方式
遇到可疑乱码字符串，可临时写小段代码逐个尝试解码并打印结果：
- 把乱码字符串（如
%E4%BD%A0%E5%A5%BD）分别用 UTF-8 / GBK / ISO-8859-1 解码，看哪个输出“你好” - 用在线工具（如 urlencoder.org）反向验证：输入明文“你好”，看生成的编码是否和你收到的一致
- 抓包查看原始 HTTP 请求头中是否有
Content-Type: application/x-www-form-urlencoded; charset=GBK类似声明
