表单提交中文乱码本质是传输链路中字符编码不一致，典型表现为后端收到???、%E4%BD%A0%E5%A5%BD或ä½ å¥½等乱码；关键断点在HTML声明（需<meta charset="UTF-8">）、HTTP请求头及后端解析逻辑（如Java中POST需request.setCharacterEncoding("UTF-8")，GET需Tomcat配置URIEncoding="UTF-8"）。
表单提交中文乱码的典型表现
后端收到的中文变成 ???、%E4%BD%A0%E5%A5%BD 或类似 ä½ å¥½ 的乱码，本质是字符编码在传输链路中不一致。关键不在“能不能”，而在“哪一环没对齐”。
常见断点有三处：HTML 声明、HTTP 请求头、后端解析逻辑。任一环节用 ISO-8859-1（默认 fallback）解 UTF-8 编码的中文，就会出问题。
确保 HTML 页面声明 UTF-8 编码
这是起点，但仅靠它不够——它只影响浏览器如何解释页面本身，不强制表单提交用什么编码。
- 必须在
<head> 中写明：<meta charset="UTF-8">
- 不要写成
<meta http-equiv="Content-Type" content="text/html; charset=GBK">，GB 系编码和服务端不匹配时极易翻车
- 如果用模板引擎（如 Jinja2、Thymeleaf），确认模板文件本身也是 UTF-8 编码保存（编辑器右下角常显示编码格式）
后端接收时显式指定字符集（以 Java Servlet 为例）
Servlet 容器（如 Tomcat）默认用 ISO-8859-1 解析 POST body，所以 request.getParameter("name") 直接调用会乱码。
- 对 POST 请求，必须在读取任何参数前调用：
request.setCharacterEncoding("UTF-8");
- 这行代码要放在
getParameter() 或 getInputStream() 之前，否则无效
- GET 请求的参数编码由容器 URL 解码逻辑控制，Tomcat 需在
server.xml 的 <Connector> 中加 URIEncoding="UTF-8"
- Spring Boot 用户注意：
spring.http.encoding.charset=UTF-8 仅影响响应和部分自动解析，对原始 request parameter 仍需手动 setCharacterEncoding
Node.js / Python / PHP 的关键处理点
不同语言默认行为差异大，不能套用同一套逻辑。
- Node.js（原生
http 模块）：req.on('data') 接收的是 Buffer，必须用 toString('utf8')；用 Express 则需 app.use(express.urlencoded({ extended: true, encoding: 'utf-8' }))
- Python Flask：
request.form.get('name') 默认可正确处理 UTF-8，前提是前端发来的 Content-Type 包含 charset=utf-8（现代浏览器 POST 表单默认带）
- PHP：
$_POST 通常没问题，但若用 file_get_contents('php://input') 读原始体，需确保文件本身是 UTF-8，且无 BOM 头（BOM 会导致 JSON 解析失败）
<head> 中写明：<meta charset="UTF-8">
<meta http-equiv="Content-Type" content="text/html; charset=GBK">，GB 系编码和服务端不匹配时极易翻车ISO-8859-1 解析 POST body，所以 request.getParameter("name") 直接调用会乱码。
- 对 POST 请求，必须在读取任何参数前调用：
request.setCharacterEncoding("UTF-8"); - 这行代码要放在
getParameter()或getInputStream()之前，否则无效 - GET 请求的参数编码由容器 URL 解码逻辑控制，Tomcat 需在
server.xml的<Connector>中加URIEncoding="UTF-8" - Spring Boot 用户注意：
spring.http.encoding.charset=UTF-8仅影响响应和部分自动解析，对原始 request parameter 仍需手动 setCharacterEncoding
Node.js / Python / PHP 的关键处理点
不同语言默认行为差异大，不能套用同一套逻辑。
- Node.js（原生
http 模块）：req.on('data') 接收的是 Buffer，必须用 toString('utf8')；用 Express 则需 app.use(express.urlencoded({ extended: true, encoding: 'utf-8' }))
- Python Flask：
request.form.get('name') 默认可正确处理 UTF-8，前提是前端发来的 Content-Type 包含 charset=utf-8（现代浏览器 POST 表单默认带）
- PHP：
$_POST 通常没问题，但若用 file_get_contents('php://input') 读原始体，需确保文件本身是 UTF-8，且无 BOM 头（BOM 会导致 JSON 解析失败）
http 模块）：req.on('data') 接收的是 Buffer，必须用 toString('utf8')；用 Express 则需 app.use(express.urlencoded({ extended: true, encoding: 'utf-8' }))
request.form.get('name') 默认可正确处理 UTF-8，前提是前端发来的 Content-Type 包含 charset=utf-8（现代浏览器 POST 表单默认带）$_POST 通常没问题，但若用 file_get_contents('php://input') 读原始体，需确保文件本身是 UTF-8，且无 BOM 头（BOM 会导致 JSON 解析失败）最容易被忽略的是：前后端开发环境本地测试时，浏览器可能缓存旧的 Content-Type 或历史编码设置，换一个隐身窗口或清空缓存再试，比反复改代码更有效。
