富文本中文乱码本质是数据流转中任一环节编码不一致所致，需逐环排查：检查响应头charset、HTML结构完整性、后端拼接是否二次编码、导出Word时库的编码处理及多源数据真实编码验证。
富文本内容中文乱码，根本不是“HTML没写对”这么简单——它往往发生在数据流转的中间环节：前端编辑器输出、后端接收、数据库存储、再读取渲染，任一环编码不一致就会出问题。直接改 <meta charset="UTF-8"> 通常无效。
确认富文本原始字符串是否已损坏
乱码可能早在进入 HTML 之前就发生了。比如用户在富文本编辑器里输入“测试”，但后端接收到的是 "æµè¯" 或 ""，说明传输或解析阶段已用错编码解码。
- 在浏览器开发者工具（F12）→ Network → 点击对应请求 → 查看 Payload 或 Response → 复制原始响应体，粘贴到文本编辑器里看中文是否正常
- 如果原始响应里中文就是乱码（如
æµè¯），问题出在服务端返回时未正确设置响应头：Content-Type: text/html; charset=utf-8或application/json; charset=utf-8 - 如果是 JSON 接口，检查后端是否用了
response.setCharacterEncoding("UTF-8")（Java）、res.set('Content-Type', 'application/json; charset=utf-8')（Express）或header('Content-Type: application/json; charset=utf-8')（PHP） - Python Flask/Django 默认 UTF-8，但若用
json.dumps()手动序列化且未设ensure_ascii=False，也可能导致中文被转义成 \uXXXX 后又被错误解码
补全 HTML 结构时 meta 必须紧贴 <head> 开始
富文本常是片段（如 <p>你好</p>），导出 Word 或内嵌渲染时需包裹成完整 HTML。但很多补全逻辑把 <meta charset="UTF-8"> 放在 <head> 内部任意位置，甚至加了空格或注释，浏览器会忽略它。
- 必须写成这样（开头无空格、无注释、无 BOM）：
<html> <head><meta charset="UTF-8"></head> <body>...</body> </html>
<head><!-- 注释 --><meta charset="UTF-8"> 或 <head>\n <meta charset="UTF-8">
xxd -l 16 yourfile.html 检查开头三字节，确保不是 ef bb bf（BOM）；VS Code 保存时选 “UTF-8” 而非 “UTF-8 with BOM”后端拼接 HTML 时避免二次编码污染
常见陷阱：富文本内容本身是 UTF-8 字符串，但后端用 String.replace() 或模板引擎插入时，意外触发了 URL 编码、HTML 实体转义或平台默认编码转换。
立即学习“前端免费学习笔记（深入）”；
- Java 中，
URLEncoder.encode(rawHtml, "UTF-8")后再塞进 HTML body，会导致中文变成%E6%B5%8B%E8%AF%95，浏览器无法还原 - Thymeleaf 用
th:text="${content}"会自动转义，应改用th:utext="${content}"；JSP 用<c:out value="${content}" escapeXml="false"/> - Node.js 中，
res.send('<div>' + content + '</div>')若 content 含未转义引号或<，可能破坏结构；更安全的是用模板或显式设置res.charset = 'utf-8' - PHP 中，
htmlspecialchars($content)后再插入，会把中文原样保留但把<变成，影响解析；应只对不可信字段做转义，富文本内容走 <code>echo $content（前提是它已来自可信源且编码干净）
导出 Word 场景要额外封住 POI/IText 的编码漏洞
用 Apache POI 或类似库将富文本转 Word 时，即使 HTML 片段本身没问题，库内部解析仍可能按平台默认编码（如 Windows 的 GBK）读取字符串，导致中文变乱码。
- POI 的
XWPFDocument不直接处理 HTML，需先用 Jsoup 等解析。Jsoup 加载字符串时必须显式指定编码：Jsoup.parse(htmlString, "", Parser.xmlParser())并确保 htmlString 是 Java 字符串（已 UTF-8 解码） - 若从文件读取 HTML 再转 Word，别用
new FileInputStream(path)，而要用Files.readString(Paths.get(path), StandardCharsets.UTF_8)（Java 11+） - 导出响应头必须带 charset：
Content-Type: application/msword; charset=UTF-8，否则 IE/Edge 可能用 GBK 解析二进制流 - Word 内置 HTML 引擎对
<meta charset>不敏感，真正起作用的是整个 HTTP 响应头或文件流的编码声明 —— 所以服务端输出环节比 HTML 里写 meta 更关键
最容易被忽略的一点：富文本内容可能来自多个源头（用户输入、CMS 导入、旧数据库迁移），它们各自的编码状态未必一致。不要假设“都是 UTF-8”，每次接入新数据源，都得用 file -i、hexdump 或代码中打印字节验证真实编码。
