根本原因是Word等来源粘贴的HTML或文本自带非UTF-8编码（如GBK、ANSI带BOM），而编辑器仅做DOM操作不自动转码，浏览器未明确编码时fallback至系统默认（如Windows用GBK），导致解码错乱。
富文本内容保存时为什么一粘贴就乱码
根本原因不是编辑器本身，而是粘贴进来的 HTML 片段或纯文本自带非 UTF-8 编码（比如 Word 复制带 BOM 的 ANSI、微信/QQ 导出的 GBK 片段），而富文本编辑器（如 Quill、TinyMCE、CKEditor）默认只做 DOM 操作，不自动转码。浏览器解析时若页面未明确声明编码，就会 fallback 到系统默认（Windows 是 GBK），你好 可能被当 GBK 解成 浣犲ソ。
- 复制自 Word / 微信 / QQ 的文本常含不可见控制符、全角空格、BOM 或 GBK 字节流
-
document.execCommand或contenteditable直接插入的 HTML 不经过字符集校验 - 后端接收时若没指定
Content-Type: text/html; charset=utf-8，Node.js/PHP 默认按 ISO-8859-1 或 GBK 解包 - 前端用
innerHTML插入服务端返回的 HTML 时，若响应头没带charset=utf-8，也会解错
前端富文本输出必须强制声明 UTF-8 三要素
光靠 <meta charset="UTF-8"> 不够——它只影响 HTML 解析，不影响 JS 动态插入的内容。必须同时控制：页面编码、AJAX 响应头、DOM 插入方式。
- 确保 HTML 页面本身是无 BOM 的 UTF-8 文件（用
xxd -l 4 index.html验证无ef bb bf） - AJAX 请求后端时，显式设置请求头：
headers: { 'Accept-Charset': 'utf-8' }；后端响应必须带Content-Type: text/html; charset=utf-8 - 不要用
element.innerHTML = htmlString直接插入服务端返回的 HTML；改用DOMParser+document.adoptNode或先转义再渲染 - 富文本编辑器初始化时，强制清空初始值中的非法字节：
editor.root.innerHTML = cleanHtml(editor.root.innerHTML)，其中cleanHtml应过滤掉\u0000-\u0008\u000B\u000C\u000E-\u001F等控制字符
后端接收富文本内容时 charset 必须显式指定
很多框架默认忽略 POST body 编码，尤其 multipart/form-data 表单提交富文本 HTML 时，req.body.content 可能是乱码字节数组而非字符串。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- Express.js：必须在
body-parser前加中间件：app.use((req, res, next) => { req.setEncoding('utf8'); next(); })，且bodyParser.urlencoded({ extended: true, charset: 'utf-8' }) - PHP：
mb_internal_encoding('UTF-8')+mb_http_input('UTF-8')+mb_http_output('UTF-8')三连，不能只靠header('Content-Type: text/html; charset=utf-8') - Nginx 反向代理时，确认没覆盖响应头：禁用
charset utf-8;与add_header Content-Type冲突，优先用后端设 header - 数据库存储前，用
iconv('GBK', 'UTF-8//IGNORE', $str)或mb_convert_encoding($str, 'UTF-8', 'auto')强制转码
富文本编辑器自身配置易被忽略的点
像 TinyMCE 的 forced_root_block、Quill 的 formats 白名单，看似和编码无关，实则影响输出结构——错误嵌套导致浏览器解析中断，进而触发编码 fallback。
立即学习“前端免费学习笔记（深入）”；
-
TinyMCE：启用encoding: 'xml'并配entity_encoding: 'raw'，避免把中文转成你再二次解码 -
Quill：禁用clipboard.matchVisual = false，否则粘贴 Word 内容时会丢格式但保留乱码字节 - 所有编辑器导出 HTML 前，务必调用
editor.getSemanticHTML()（若支持）或正则清理：html.replace(/[\u0000-\u0008\u000B\u000C\u000E-\u001F\uFFFE\uFFFF]/g, '') - 服务端返回富文本 HTML 给前端渲染时，不要包裹在 JSON 里直接
JSON.parse()—— JSON 默认 UTF-8，但若原始数据含 BOM 或混合编码，JSON.parse会静默截断
最常漏掉的是：前端发请求时没设 Accept-Charset，后端收请求时没强制 setEncoding('utf8')，编辑器导出时没 strip 控制字符——三者缺一，富文本就可能在某个环节突然“变脸”。
