根本原因是application/x-www-form-urlencoded不携带charset声明，服务器只能按默认编码（如UTF-8）解码，而Postman在Windows中文系统下默认用GBK读取中文并URL编码，导致编码与解码不一致；需统一为UTF-8或显式配置GBK解析。
Postman 发送中文表单时出现乱码，根本原因不是“没选对编码”，而是 application/x-www-form-urlencoded 本身不携带 charset 声明，服务器只能靠默认或猜测来解码——而多数后端（如 Spring Boot）默认按 UTF-8 解，但若前端实际发的是 GBK 字节，就会错解成乱码。
为什么 x-www-form-urlencoded 不写 charset 也能发中文？
因为浏览器在提交表单时，会把中文按当前页面编码（比如 GBK）转成字节，再 URL 编码（即 %XX 形式），但 Content-Type 头里不会带 charset=GBK。Postman 模拟的正是这个行为：它只做键值对的 URL 编码，不干预底层字节来源。
所以关键不在 Postman 设置，而在你输入中文时编辑器用的是什么编码——Postman 桌面版编辑器默认使用系统 locale 编码（Windows 中文版通常是 GBK），但它的文本框本身不显示或锁定编码，容易误判。
- 如果你在
x-www-form-urlencoded模式下直接输入“张三”，Postman 会按当前系统编码（如 GBK）读取字节，再做 URL 编码，例如%D5%C5%C8%FD - 但目标接口若按 UTF-8 解析这串字节，就会还原出乱码（如 “ÕÅÈý”）
- Postman 的
x-www-form-urlencoded模式 **不支持手动指定 charset**，这是 HTTP 规范限制，不是 Postman 缺陷
真正可控的中文表单提交方式：用 raw + application/x-www-form-urlencoded
绕过默认模式的隐式编码，改用 raw 模式手动构造请求体，并显式声明 charset：
- Body 选择
raw，右侧下拉菜单选Text（不要选application/json等） - 在 Headers 里手动加一行：
Content-Type: application/x-www-form-urlencoded; charset=GBK - 在 raw 编辑区直接输入 URL 编码后的字符串，例如：
name=%D5%C5%C8%FD&city=%C9%EE%BD%F7 - 确保你用的是 GBK 编码的文本编辑器（如 Notepad++ 切换到 GBK）生成这串编码，再粘贴进来
这样服务器收到 charset=GBK 后，就能正确按 GBK 解码 %D5%C5%C8%FD 成“张三”。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
Spring Boot 后端必须同步配置 GBK 解析
即使 Postman 发对了，Spring Boot 默认仍用 UTF-8 解 x-www-form-urlencoded，需显式覆盖：
- 在
application.properties加：server.tomcat.uri-encoding=GBK - 或更稳妥地，在 WebMvcConfigurer 中注册
CharacterEncodingFilter，setEncoding("GBK")并设setForceRequestEncoding(true) - 注意：仅设
spring.http.encoding.charset=GBK对 form 表单无效，它只影响 JSON 等 text 类型
没配这一步，Postman 再怎么调都是白搭。
更推荐的长期方案：统一用 UTF-8
除非对接遗留系统强制要求 GBK，否则应推动前后端都切到 UTF-8：
- Postman 中新建请求 → Body →
x-www-form-urlencoded→ 输入“张三”，它会生成%E5%BC%A0%E4%B8%89（UTF-8 编码） - Headers 不用加 charset（UTF-8 是
x-www-form-urlencoded的事实默认） - 后端保持默认配置即可，无需额外编码设置
- 若历史数据是 GBK，可用 Python 或在线工具批量转 UTF-8 编码再填入
GBK 表单本质是兼容性补丁，不是标准路径；一旦涉及多语言、文件名、特殊符号，很快会踩坑。
