表单提交时特殊字符不需要、也不该由前端手动转义html实体，应交由后端处理并进行安全过滤与转义。
表单提交时特殊字符不需要、也不该由前端手动转义 HTML 实体（如把 ），否则大概率导致后端收到双重编码或解析失败。
为什么不能对表单 value 手动 HTML 转义
浏览器在提交 application/x-www-form-urlencoded 或 multipart/form-data 表单时，会自动做 URL 编码或分块处理，原始字符串中的 &、、<code>" 等字符本就安全——它们不会被当 HTML 解析，也不会破坏请求结构。
手动 HTML 转义反而引发问题：
- 后端收到
<这类嵌套编码，解码一次得，再解一次才到 <code>，容易漏步或多步 - 富文本内容（比如含
<p></p>的评论）被转义后变成纯文本，丢失语义 - JSON 字段值（如
{"msg":"x & y"}）被转义成{"msg":"x & y"}，后端 JSON.parse 失败 - 服务端模板（如 Django、Vue）默认已做输出转义，前端再转一次，页面直接显示源码
真正要关注的三个编码层
特殊字符能否正确传递，取决于三处是否统一为 UTF-8：
-
HTML 页面声明：确保
<meta charset="UTF-8">在最前面 -
表单传输编码：显式加
accept-charset="UTF-8"（即使页面已声明，Chrome/Firefox 也建议写上） -
HTTP 请求头：POST 时请求头应为
Content-Type: application/x-www-form-urlencoded; charset=UTF-8（现代浏览器默认如此，但 Nginx/Apache 反代可能覆盖）
GET 表单无需设 enctype，但 URL 参数仍受 URIEncoding 影响——Tomcat 需在 server.xml 的 <connector></connector> 中配 URIEncoding="UTF-8"。
文件上传 + 特殊字符怎么处理
含中文/emoji 的文件名（如 报告 ?.pdf）在 multipart/form-data 提交时，浏览器会按 RFC 5987 对 filename* 参数做编码，但旧版 IE/Edge 不支持。稳妥做法：
- 服务端不要依赖原始
filename做存储名，改用安全哈希 + 扩展名白名单 - 若需保留原始名，Node.js（multer）可设
preservePath: true并手动 decode；PHP 用mb_convert_encoding($_FILES['f']['name'], 'UTF-8', 'auto') - 避免在
<input type="file">的 value 上做任何 JS 修改——它只读，且修改无效
后端收到乱码？先查这三处
如果后端拿到的是 ä½ 这类乱码，不是前端没转义，而是编码链断了：
- 检查响应头：
Content-Type: text/html; charset=UTF-8是否存在且拼写正确（utf-8小写也可，但UTF8无效） - 确认数据库字段是
utf8mb4（不是utf8），尤其存 emoji 时，MySQLutf8只支持 3 字节 Unicode - Java Web 项目中，
request.setCharacterEncoding("UTF-8")必须在调用getParameter()之前执行，且不能在读取getInputStream()后再设
最常被跳过的环节：反向代理（Nginx/Apache）未透传或重写 Content-Type 头，或强制设成了 charset=ISO-8859-1。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
