富文本中文乱码本质是数据流转中任一环节编码不一致所致，需逐环排查：检查响应头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 必须紧贴 开始
富文本常是片段（如 <p>你好</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill6712" title="Wechat HTML Publisher"><img
src="https://img.php.cn/upload/skill/000/000/081/179109368394970.jpg" alt="Wechat HTML Publisher" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill6712" title="Wechat HTML Publisher" class="overflowclass">Wechat HTML Publisher</a>
<p class="overflowclass">直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。</p>
</div>
<a rel="nofollow" href="/xiazai/skill6712" title="Wechat HTML Publisher" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>），导出 Word 或内嵌渲染时需包裹成完整 HTML。但很多补全逻辑把 <meta charset="UTF-8"> 放在 内部任意位置，甚至加了空格或注释，浏览器会忽略它。
- 必须写成这样（开头无空格、无注释、无 BOM）：
<meta charset="UTF-8">...
<!-- 注释 --><meta charset="UTF-8"> 或 \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 用<out value="${content}" escapexml="false"></out> - Node.js 中，
res.send('<div>' + content + '</div>')若 content 含未转义引号或，可能破坏结构；更安全的是用模板或显式设置 <code>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 或代码中打印字节验证真实编码。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
