移动端中文乱码本质是编码声明与实际行为不一致：需确保HTML页面用<meta charset="utf-8">显式声明、form不设冲突的accept-charset、服务端统一UTF-8解析（如Java设request.setCharacterEncoding("UTF-8")）、数据库连接层字符集全为utf8mb4，缺一不可。
移动端表单提交时中文乱码的典型现象
用户在 iOS Safari 或 Android Chrome 中输入中文，后端收到的是 %E4%BD%A0%E5%A5%BD 解码后仍为乱码（如 ），或直接变成问号、方框。这不是传输层问题，而是表单编码声明与实际编码行为不一致导致的——浏览器按某种编码序列化表单，但服务器用另一种编码解析，中间断层了。
关键判断：如果 Content-Type 响应头中没带 charset=utf-8，或 HTML 文档没声明 <meta charset="utf-8">，移动端会回退到系统默认编码（如 iOS 可能用 UTF-16，部分安卓旧版本用 GBK），立刻埋下隐患。
确保 form 元素与页面编码严格对齐
HTML 页面必须显式声明 UTF-8，且该声明必须位于 <head> 最前面（早于任何脚本或样式）：
<meta charset="utf-8">
同时，<form> 标签本身无需加 accept-charset（除非要兼容极老浏览器），因为现代移动端浏览器完全遵循页面级 charset 声明。但若你手动设置了：
立即学习“前端免费学习笔记（深入）”；
-
accept-charset="UTF-8"是安全冗余，可加； -
accept-charset="gbk"或空值会强制覆盖页面声明，一定不能出现； - 服务端返回的
Content-Type: text/html; charset=gb2312会直接让整个页面降级，移动端可能忽略<meta>标签。
检查 fetch / XMLHttpRequest 提交时的编码陷阱
用 JS 主动提交表单（比如 fetch()）比原生 <form method="post"> 更容易出编码问题，因为编码控制权完全移交到 JS 层：
- 若用
FormData对象构造请求体，浏览器自动以 UTF-8 编码字段值，无需额外处理； - 若拼接
URLSearchParams或手动构造 query string，确保所有字符串已按 UTF-8 编码（encodeURIComponent()默认就是 UTF-8，放心用）； - 若用
JSON.stringify()发送数据，后端必须明确按 UTF-8 解析请求体，并设置Content-Type: application/json; charset=utf-8； - 错误做法：用
new Blob([str], {type: 'text/plain'})且不指定encoding，Blob 构造默认用 UTF-8，但某些安卓 WebView 会误读为 Latin-1。
服务端接收环节的硬性校验点
即使前端全链路 UTF-8，服务端一个配置偏差就前功尽弃：
- Node.js（Express）：必须设
app.use(express.urlencoded({ extended: true, charset: 'utf-8' }))，否则req.body解析可能失败； - PHP：确认
default_charset = "UTF-8"在php.ini中启用，且mb_internal_encoding('UTF-8')被调用； - Java（Spring Boot）：检查
server.servlet.encoding.charset=UTF-8和server.servlet.encoding.force=true是否生效； - Nginx：若做了代理，确认没加
charset GBK;这类指令，它会覆盖上游响应头。
最易被忽略的是数据库连接层——MySQL 的 character_set_client、character_set_connection、character_set_results 必须全为 utf8mb4，否则存进去就是截断或乱码，查出来也救不回来。
