用 DOMParser 解析 HTML 并取 textContent 是最安全通用的纯文本提取方式,需指定 MIME 类型为 text/html,优先用 doc.body?.textContent,回退到 doc.documentElement.textContent,避免使用 innerText 或正则替换。

直接用 DOMParser 解析后取 textContent,是最安全、最通用的做法。正则替换看似简单,但遇到嵌套、自闭合标签、HTML 实体或不规范结构时必然翻车。
为什么不能用 htmlString.replace(/]*>/g, '')
这个正则在简单场景下能“看起来有效”,但它根本不是 HTML 解析器:它会把 <script>alert("<div>")</script> 中的 "<div>" 也当标签删掉;无法识别 <code> 或 <br> 这类合法变体;更无法处理 <div>
<span>hello</span>world</div> 这种嵌套文本流——结果可能变成 helloworld 而非预期的 hello world(中间空格丢失)。浏览器原生解析器才是唯一能正确还原 DOM 文本语义的工具。
用 DOMParser 提取纯文本的正确写法
必须指定 MIME 类型为 text/html,否则解析结果不可靠:
function htmlToText(html) {
const parser = new DOMParser();
const doc = parser.parseFromString(html, 'text/html');
return doc.body?.textContent || doc.documentElement?.textContent || '';
}
-
doc.body?.textContent是首选,因为大多数富文本内容在内;若 HTML 片段不含(如仅<div>xxx</div>),回退到doc.documentElement.textContent - 不要用
innerText:它受 CSS 样式影响(比如display: none的子元素会被跳过),而textContent是纯粹的节点树遍历,稳定可靠 - 解析失败时
doc.body可能为null,所以要用可选链?.防崩
从 title、data-html 等属性值中提取时特别注意
这类属性值常含未转义 HTML 字符串(如 title="<strong>Hello</strong>"),直接 innerHTML 赋值会二次解析实体,导致 变成字面量 <code>。必须先用 <code>DOMParser,而不是创建临时元素再设 innerHTML:
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面,使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力: - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面; - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”; - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记(深入)”;
const titleHtml = element.getAttribute('title');
const text = htmlToText(titleHtml); // 复用上面定义的函数
- 避免
temp.innerHTML = titleHtml; temp.textContent:如果原始字符串里有<div>,临时元素会把它当字面量渲染,textContent就真读出<div> 字符串,而非其含义 <li> <code>DOMParser把输入当作原始 HTML 字符串处理,自动解码实体,行为与浏览器加载页面时一致 - 该方式天然过滤
<script></script>、<style></style>和事件处理器,无 XSS 风险
需要截断摘要或清理空白时别在解析前动手
所有文本清洗(去首尾空格、合并多余换行、截断加省略号)必须放在 textContent 获取之后,而不是对原始 HTML 字符串操作:
const summary = text .replace(/\s+/g, ' ') // 合并连续空白为单空格 .trim() // 去首尾 .substring(0, 200) // 截取 + (text.length > 200 ? '…' : '');
- 提前对 HTML 字符串
.replace()会破坏标签结构,让DOMParser解析失败或错位 -
textContent返回的是“渲染后语义文本”,已自然保留段落间换行和内联空格逻辑,清洗应基于它做 - 如果原始 HTML 含大量
或<br>
,它们在textContent中已转为普通空格或换行符,无需额外处理标签
真正容易被忽略的一点是:DOMParser 在不同浏览器中对 malformed HTML 的容错策略略有差异,但只要你只取 textContent,结果差异几乎不可见;而任何基于字符串的正则方案,只要 HTML 结构稍一复杂,就立刻暴露不可维护性——这不是优化问题,是底层能力边界问题。


















