表单提交时表情符号变成问号或乱码
根本原因是字符编码没对齐，HTML 页面、表单编码声明、后端接收和数据库存储全链路必须统一为 UTF-8。只要其中一环是 ISO-8859-1 或默认系统编码（比如 Windows-1252），?、? 这类四字节 Unicode 字符就会被截断或替换为 ?。
实操要点：
- HTML 页面顶部必须有
<meta charset="UTF-8">，且放在最前面 - 表单显式声明编码：
<form accept-charset="UTF-8"></form>（即使页面已设 charset，也建议加上） - 后端接收前确认请求头：
Content-Type: application/x-www-form-urlencoded; charset=UTF-8—— 如果缺失或写成charset=ISO-8859-1，Nginx/Apache/Node.js 中间件会按错误编码解析 - PHP 用户注意：
mb_internal_encoding('UTF-8')和mb_http_input('UTF-8')要在入口处调用；Python Flask/Django 默认支持 UTF-8，但若用了自定义中间件，需检查是否误调用了.decode('latin-1')
MySQL 存表情符号报错 Incorrect string value: '\xF0\x9F\x98\x8A'...
这是典型的 MySQL 字符集不支持四字节 UTF-8 的表现。MySQL 的 utf8 实际是阉割版（最多三字节），真正支持表情符号的是 utf8mb4。
必须同步改四层：
立即学习“前端免费学习笔记（深入）”；
- 数据库创建时指定：
CREATE DATABASE db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; - 数据表与字段：用
ALTER TABLE tbl CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - MySQL 配置文件（
my.cnf）加两段：[client] default-character-set = utf8mb4和[mysqld] character-set-server = utf8mb4 - 连接层也要配对：PHP PDO 要加
PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"；Node.js mysql2 需显式传charset: 'utf8mb4'
JavaScript 中检测并清理非法表情符号输入
不是所有场景都允许表情符号，比如用户名、邮箱前缀、API 标识字段。直接用正则过滤比后端兜底更可控。
注意：不能只靠 /[\u{1F600}-\u{1F6FF}]/u 这种简单范围——它漏掉大量常用符号（如 ?、?、?），也误伤部分合法增补字符（如带变体选择符的 ??）。
推荐做法：
- 用成熟的库做检测，比如
grapheme-splitter或unicode-regex，它们按 Unicode 图形簇（grapheme cluster）切分，能正确识别组合型表情 - 若必须手写过滤，至少覆盖：
/[\u{1F300}-\u{1F9FF}|\u{1F1E0}-\u{1F1FF}|\u{200D}|\u{FE0F}]/gu（含 emoji 补充区、区域标志、零宽连接符、变体选择符） - 前端清理后，仍需后端二次校验——用户可绕过 JS，直接发请求
textarea 输入长段落含表情时卡顿或光标错位
现代浏览器对含大量 emoji 的文本渲染开销明显增大，尤其在 iOS Safari 和旧版 Chrome 上，textarea 内部的排版引擎容易因图形簇边界计算出错，导致光标跳到行首、输入延迟、甚至崩溃。
缓解策略优先级从高到低：
- 禁用自动补全和拼写检查：
<textarea spellcheck="false" autocorrect="off"></textarea>，减少浏览器额外解析负担 - 避免在
input或keydown事件中频繁调用textarea.value.length—— 它返回的是 UTF-16 码元数，不是真实字符数，对 emoji 会误判，引发重绘抖动 - 如需实时统计字数，用
Intl.Segmenter（Chrome 90+、Safari 15.4+）：new Intl.Segmenter('zh', { granularity: 'grapheme' }).segment(str).length - 极端情况可降级：检测到连续输入 >3 个 emoji 时，提示“建议使用文字描述”，或切换为富文本编辑器（如
contenteditable+ 自定义渲染）
最常被忽略的一点：前后端之间传输 emoji 时，别依赖 JSON.stringify() 默认行为——它不会报错，但某些老旧环境（如某些嵌入式 JS 引擎）可能静默丢弃高位代理对，导致表情变空格或乱码。保险起见，敏感字段建议先 encodeURIComponent() 再传，后端再解码。
