表单提交特殊字符不会直接导致系统错误，但会引发XSS、SQL注入等故障，根源在于未在正确位置用正确方式转义或校验；PHP中htmlspecialchars()必须指定ENT_QUOTES和'UTF-8'参数，JSON场景须用json_encode()，数据库操作必须用预处理语句，所有输出通道均需按上下文转义。
表单提交时特殊字符不会直接导致“系统错误”，但会引发 XSS、SQL 注入、JSON 解析失败、模板渲染崩溃等实际故障——根源在于你没在正确位置、用正确方式做转义或校验。
htmlspecialchars() 必须带 ENT_QUOTES 和 'UTF-8' 参数
PHP 中 htmlspecialchars() 默认编码是 ISO-8859-1，遇到中文或 emoji 会截断或输出乱码，进而让前端 JS 解析 HTML 片段时报错。比如用户输入 “你好<script>”，不指定编码可能变成 “<script>”，浏览器解析时中断 DOM 树。</script>
- 错误写法：
htmlspecialchars($input)—— 缺少参数，中文被破坏 - 正确写法：
htmlspecialchars($input, ENT_QUOTES, 'UTF-8') -
ENT_QUOTES很关键：它同时转义单引号和双引号，防止插入到value="..."或value='...'时被提前闭合 - 如果变量要进 JS 字符串（如
var msg = "<?php echo $input ?>";），必须改用json_encode($input, JSON_UNESCAPED_UNICODE)，不能只靠htmlspecialchars()
后端接收后别直接拼 SQL 或 echo 到 HTML
很多“系统错误”其实是 PHP 致命错误（如 Parse error: syntax error）或 MySQL 报错（如 You have an error in your SQL syntax），源头就是把未过滤的 $_POST['name'] 直接插进查询或模板里。
- 数据库操作必须用预处理语句：
$stmt = $pdo->prepare("INSERT INTO users(name) VALUES(?)"); $stmt->execute([$name]); - HTML 输出前必须过
htmlspecialchars()，哪怕只是回显提示语：<p>欢迎，<?php echo htmlspecialchars($name, ENT_QUOTES, 'UTF-8'); ?></p> - 禁止拼接：
"SELECT * FROM user WHERE name = '" . $_POST['name'] . "'"—— 单引号、反斜杠、空格都会让 SQL 崩掉 - 模板引擎（如 Twig、Blade）默认开启自动转义，但若用了
{{ raw(user_input) }}或{!! $input !!}，就等于主动关防护
前端 input 事件实时过滤 ≠ 后端可跳过校验
用 JS 在 input 事件里 replace(/[^a-zA-Z0-9_-]/g, '') 确实能让用户“输不进”特殊字符，但这对 curl、Postman、禁用 JS 的浏览器完全无效。后端仍可能收到恶意 payload，比如：
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
立即学习“前端免费学习笔记（深入）”；
- 用户绕过 JS，直接 POST
{"name":"<img src="https://img.php.cn/" alt="HTML表单提交时如何避免特殊字符引发的系统错误">"}—— 前端没拦住，后端又没转义，页面一渲染就执行脚本 - 密码字段用
pattern="[a-zA-Z0-9_-]+"，但攻击者用 curl 提交password=%3Cscript%3Ealert(1)%3C%2Fscript%3E（URL 编码），后端没解码+校验就入库 - 富文本场景下，光过滤
<script>没用：<svg onload="alert(1)">、<img src=x onerror=eval('alert(1)')>一样触发 - 真正安全的做法：前端过滤只作体验优化；后端必须用白名单（如
preg_replace('/[^a-zA-Z0-9_-]/', '', $input)）或成熟净化库（如bleach.clean()）再落地
JSON 提交时注意双引号和反斜杠逃逸
现在很多表单走 AJAX + application/json，后端用 json_decode(file_get_contents('php://input')) 解析。这时特殊字符问题从 HTML 转移到 JSON 层级。
- 用户提交：
{"name": "Alice\"; alert(1)"}—— 如果后端没校验，直接塞进 JS 模板：var name = "<?php echo $name ?>";，会导致 JS 语法错误甚至执行 - 解决方案不是自己写正则去删引号，而是统一用
json_encode()输出到前端 JS 变量中：var data = <?php echo json_encode($serverData, JSON_UNESCAPED_UNICODE); ?>; - 注意：
json_encode()输出的是合法 JSON 字符串，自带引号和转义，不需要再套htmlspecialchars() - 如果 JSON 数据最终还要插入 HTML（比如渲染成列表项），先
json_encode()给 JS，再由 JS 用textContent插入，而不是innerHTML
最容易被忽略的一点：错误日志里直接 echo $_POST 或写进 log 文件，也会把恶意脚本原样记录并可能被运维人员在后台页面查看时触发——所有输出通道都要按上下文做对应转义，不只限于用户可见的 HTML 页面。
