表单中文乱码需从前端accept-charset、后端请求解析、文件上传编码、数据库字符集四方面排查：前端form必须设accept-charset="UTF-8"；后端按框架要求显式指定UTF-8解码；文件名用filename*编码；数据库全链路（连接、表、字段、会话）须统一utf8mb4。
表单提交时中文变乱码，先检查 accept-charset 是否设为 UTF-8
浏览器默认可能用 ISO-8859-1 编码提交表单，一遇到中文、日文或 emoji 就直接丢字节。不是后端没解码，是前端根本没发对。
-
标签必须显式声明accept-charset="UTF-8"，哪怕页面 meta 已设 charset - 如果用 JavaScript 动态创建表单，记得手动设置
form.acceptCharset = "UTF-8" - 某些老版本 IE 对
accept-charset支持不稳定，此时更依赖服务端主动按 UTF-8 解析（见下一条）
后端接收时乱码，关键看 Content-Type 的 charset 参数是否生效
HTTP 请求头里的 Content-Type: application/x-www-form-urlencoded; charset=UTF-8 是提示，不是强制——很多框架忽略它，只按自身默认编码解析。
- Node.js + Express：需启用
express.urlencoded({ extended: true, charset: "utf-8" })，且确保没被其他中间件覆盖 - Python Flask：
request.form默认按 UTF-8 解析，但若用了request.get_data()手动读体，必须显式.decode("utf-8") - Java Servlet：
request.setCharacterEncoding("UTF-8")必须在调用getParameter()之前执行，且仅对 POST 生效
文件上传含多字节文件名，Content-Disposition 的 filename* 字段不能省
普通 filename="中文.txt" 在多数浏览器里会失败，因为 RFC 5987 要求非 ASCII 文件名必须用 filename*=UTF-8''%E4%B8%AD%E6%96%87.txt 格式编码。
- 前端用
FormData.append()传文件时，浏览器自动处理编码，无需干预 - 后端解析时，优先读
filename*字段；若不存在，再 fallback 到filename（并假设为 Latin-1 或 ISO-8859-1） - Nginx 默认会剥离
filename*，需配置underscores_in_headers on;并确认未过滤 header
数据库存取中文出问题，别只盯连接字符串的 charset
MySQL 连接参数加了 ?charset=utf8mb4 不等于万事大吉——表结构、字段、甚至客户端连接 session 都可能降级成 latin1。
- 建表语句必须带
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 执行
SET NAMES utf8mb4只影响当前 session，连接池复用时可能失效 - PostgreSQL 更严格：只要客户端编码（
client_encoding）和服务端不一致，就报错，不能静默转换
最常被跳过的环节是：开发环境改了，测试环境同步了，生产数据库的 default charset 却还是旧的。查 SHOW VARIABLES LIKE 'character_set%' 比猜有用得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
