HTML剥离工具：快速去除HTML标签获取纯文本
把网页文本喂给下游系统时，第一步几乎都是剥离 HTML。这一步看起来只是"删尖括号"，实际上是把一篇带结构、带脚本、带实体引用的文档降维成一条字符流——降维必然丢信息，真正的问题是丢掉哪些、留给谁用。
下面从下游用途反推剥离深度，再用一段可复算的样例对比三种策略的输出差异，最后讲批量处理时的顺序陷阱与合规边界。如果你只想把手里的一段 HTML 立刻变成干净文字，直接用HTML 剥离工具即可；本文要解决的是"跑完一整批语料之后才发现不对"的返工问题。
一、四类下游用途，四种硬约束
剥离策略不该凭手感选，它由产物的用途决定。
- NLP 语料构建：模型看到的是词频与序列。一句
var t=Date.now()会让var、function挤进高频词表，噪声一旦进入统计，后续的向量化与关键词抽取都会被带偏。 - 翻译与本地化：翻译记忆库按句段对齐。段落边界如果被压成一行，
<p>之间的断句信息就消失了，回填译文时会整段错位。 - 内容分析与检索：索引体积和分词质量都受噪声影响。导航、页脚、cookie 提示不裁掉，"登录""注册""首页"会成为全站最高频词。
- 归档与数据迁移：产物要能被人读、能被 diff、能被长期保存。纯文本归档一旦丢掉标题层级，多年后想恢复结构就只能重新抓一遍。
四类约束指向同一个判断：剥离深度应当由产物用途倒推，而不是由工具的默认行为决定。
二、剥离深度的三档选择
| 档位 | 产物形态 | 保留的信息 | 丢失的信息 | 适用下游 |
|---|---|---|---|---|
| 纯文本 | 一段连续字符流 | 全部可见文字 | 标题层级、列表与表格边界、链接地址 | 词频统计、简单检索、字数统计 |
| 保留结构 | 按段落分行的文本 | 段落与标题的换行位置 | 列表符号、表格列关系、链接地址 | 人读归档、翻译句段切分、文本对比 |
| 转 Markdown | 带轻量标记的文本 | 标题层级、列表、链接地址、表格列关系 | 原始 class 与 id、属性、内联样式 | 文档库、静态站点、模型微调语料 |
三档的差别不在"干净程度"——它们都能把标签去掉——而在信息损失的方向。纯文本丢弃的是结构，Markdown 丢弃的是渲染细节。反向需求最容易踩坑：纯文本产物里的链接地址找不回来，因为 URL 只存在于属性里，剥离那一刻就已经消失；反过来，如果下游只需要词频，那么为保留结构付出的额外解析成本也没有回报。
一个实用的判断顺序是：下游会不会重新渲染这份文本？会，就选 Markdown 或保留结构；不会（只做统计、检索、入库），纯文本就够，但必须先净化。
三、真实故障谱系：症状、根因与定位
下面六种问题在批量语料里反复出现，共同点是"单看一段 HTML 完全正常，跑完一整批才发现"。
| 症状 | 常见根因 | 定位方法 | 处理 |
|---|---|---|---|
词频表里出现 function、var、px | 剥离前没有移除 script 与 style 的内容 | 统计输出中的噪声词命中率 | 把净化步骤提到剥离之前 |
| 整篇文章被压成一行 | 块级标签没有映射为换行 | 检查输出的行数与平均行长 | 为块级元素建立换行映射 |
| 两段"看起来一样"的文字比对不相等 | 实体未解码，或空白字符不同（U+00A0 与 U+0020） | 打印码点，或打开编辑器的不可见字符显示 | 解码实体后统一做空白规范化 |
| 表格内容粘连，如"数码产品15 天" | 纯文本没有单元格边界 | 抽查含表格的页面 | 表格单独走 Markdown 管道表或定宽填充 |
| 中文分词结果异常 | 混入全角空格 U+3000 或西文不换行空格 U+00A0 | 按码点统计空白字符分布 | 显式替换为半角空格，不要靠肉眼判断 |
| 正文里混入"登录 注册 首页" | 未裁正文区域，导航与页脚一起进了语料 | 把高频词与页面模板对照 | 先按容器选择器截取正文，再剥离 |
这张表最值得记住的不是处理办法，而是定位方法：这些问题几乎都靠统计特征暴露，而不是靠读文本发现。一份十万页的语料里，人工抽查只能覆盖开头几百页，而噪声词命中率、平均行长、空白字符分布这三项指标可以全量扫描。
四、真实算例：同一段 HTML 的三种产物
样例取自一个商品页的政策区块，原始 362 个字符，其中 script 与 style 合计 97 个字符，占原始体积 26.8%：
<div class="post">
<h2>退款政策</h2>
<script>var t=Date.now();track('view',t);</script>
<style>.note{color:#888;font-size:12px}</style>
<p>7 天内可退款 — 需保留原包装。</p>
<table>
<tr><th>品类</th><th>期限</th></tr>
<tr><td>数码产品</td><td>15 天</td></tr>
<tr><td>食品</td><td>不支持</td></tr>
</table>
<p>详情见 <a href="/refund">退款细则</a>。</p>
</div>策略一：一刀切正则。用 <[^>]+> 直接删标签，再把连续空白折叠成一个空格，得到 139 个字符，全部挤成一行。其中 65 个字符是脚本与样式残留，占输出的 46.8%；实体也没有解码， — 原样留在正文里。这几乎是"清理了一半、污染了一半"。
策略二：先净化，再按块级标签转换行，最后解码实体。输出降到 52 个字符、6 行，实体正确还原为空格与破折号，相对原始 HTML 的体积比约 14.4%。但样例里的表格暴露了纯文本的天花板：表头两格粘连成"品类期限"，数据行粘连成"数码产品15 天"——单元格边界在纯文本里根本不存在。
策略三：转 Markdown。输出 96 个字符、6 行，体积比约 26.5%：标题变成 ## 退款政策，表格变成管道表，链接保留为 [退款细则](/refund)。代价是产物不再是纯文本，下游必须能接受轻量标记。
把比例外推到批量场景：10 万页、平均每页 180 KB 的 HTML，原始体积约 17.17 GB，按策略二的体积比剥离后约 2.47 GB。这个数量级说明存储从来不是瓶颈，真正的成本在清洗与返工——而返工几乎都由"顺序错了"引起。
五、批量处理的顺序：先净化，后剥离
把上例的 46.8% 放大到整批语料，就能看清顺序的意义。推荐的处理链路是：
- 统一编码：抓取结果先转 UTF-8，避免多编码混存导致后续全部乱码。
- 净化：整块移除
script、style、noscript、HTML 注释与隐藏元素。 - 解析：用 DOM 解析器切分文档，而不是用正则表达式匹配标签。
- 剥离或转换：按第二节选定的档位输出产物。
- 规范化：解码实体、统一换行符、折叠空白、处理全角空格与不换行空格。
- 校验：噪声词命中率、平均行长、实体残留三项全量扫描通过后再入库。
第 2 步与第 4 步的顺序不能交换：剥离之后的产物已经丢失了"哪些字符来自脚本"这一信息，此时再想删掉 var t=Date.now() 就只能靠猜——它和正文里的英文句子长得一模一样。反过来，正则替换本身就不可靠：属性值里出现 >、正文里讨论标签写法、注释里的尖括号，都会让 <[^>]+> 删错位置。
六、合规边界：技术可行不等于可以抓
下表只作方向性提示，不构成法律意见；具体项目请以目标站点的服务条款与当地法律为准。
| 来源类型 | 常见约束 | 风险等级 | 建议做法 |
|---|---|---|---|
| 自有站点、客户交付物 | 无额外约束 | 低 | 可直接批量剥离入库 |
| 公开网页（研究、建索引） | robots.txt 与站点条款；抓取频率 | 中 | 遵守 robots.txt，限制并发，不镜像整站 |
| 竞品内容再发布 | 著作权；不正当竞争 | 高 | 只做摘要与引用，不整篇搬运 |
| 公开语料数据集 | 数据集自带许可与使用条款 | 中 | 逐项确认许可范围与署名要求 |
| 付费 API 与订阅源 | 服务条款常限制存储与再分发 | 高 | 先读条款，再决定能存多久、能存什么 |
三条经验规则：robots.txt 是底线而不是许可；抓取频率要留出服务端余量；剥离后的产物依然是受版权保护的表达——把别人的文章剥成纯文本再发布，不会因为"没有 HTML 标签"就变成原创。
七、常见问题（FAQ）
- 剥离后的语料里混进了 JS 变量名，怎么根治？
- 根因几乎都在顺序上：先剥离标签、后删脚本，脚本内容早就被当成正文了。正确顺序是先整块移除 script 与 style 元素，再做标签剥离；同时把 function、var、px 这类噪声词做成黑名单，入库前统计命中率。
- 抓取公开网页做语料，边界在哪里？
- 先看 robots.txt 与站点条款，再控制抓取频率，只取需要的正文区域。用于个人研究、建索引与合理引用的风险较低；整站镜像、去标签后重新发布、训练后商用，风险显著更高，应先确认授权。
- 表格和列表在纯文本里该怎么处理？
- 纯文本没有列宽概念，单元格边界必然丢失，样例里的"数码产品15 天"就是结果。要么接受这种损失，要么给表格单独走一条 Markdown 管道表通道，要么用定宽填充并保留表头行。
- 同一份 HTML 两次剥离结果不一致，可能是什么原因？
- 常见三种：页面由前端渲染，两次抓取拿到的 HTML 本身就不同；编码识别不稳定，同一份字节被按不同字符集解码；实体解码与空白规范化的强度不一致。固定编码、固定解析器版本、把规则写进流水线即可复现。
八、三个反直觉的坑
坑一：先解码实体，再剥离标签。看起来更彻底，实际会把正文里讨论标签写法的示例文本吃掉——源文档里写作 <script> 的内容，解码后变成真正的 <script> 字样，紧接着的标签剥离会把它当成标签删掉。解码必须放在剥离之后。
坑二：用 Unicode 规范化顺手"统一标点"。NFKC 会把全角逗号、全角括号映射为半角形式，对检索归一化有帮助，但对中文排版是有损的。需要保留中文标点的语料应当用 NFC；NFKC 更适合生成检索键，而不是最终产物。
坑三：认为样本量小就不用统计。噪声是按页面模板成批出现的，前十页干净不代表全站干净。全量扫描三项指标的成本，远低于把带噪声的语料喂进模型之后再回头排查。
九、四条落地建议
- 把顺序写进脚本，而不是写进文档：净化、解析、剥离、规范化四步固化成一条可重复执行的命令，任何人重跑都能得到同一份产物。
- 保留原始 HTML 与产物的对应关系：出问题时能回到源头重跑，而不是凭记忆修补。
- 入库前三项校验：噪声词命中率、平均行长，以及实体残留（查找
&后接字母的模式）。 - 先定档位再动手：要二次渲染就选 Markdown，只做统计与检索就选纯文本，但纯文本路线必须先把净化做在前面。
剥离只是语料流水线的第一道工序，后面还有字符级清理与格式转换要接：如果产物里混入零宽字符、BOM 或全角空格，可以用文本清理工具处理，排查思路见不可见字符引发的真实故障；需要把剥离结果保留成带标题与列表的轻量格式时，用Markdown 预览核对渲染效果；统计产物字数则可以直接用字数统计工具。