BeautifulSoup解析后，text属性中为何仍存在 、—等符号？

这种情况并不少见，也容易引发困惑。既然 BeautifulSoup 能够解码，为何 （不换行空格）或 —（长破折号）这类符号仍然存在？

实际上，这涉及一个技术细节：BeautifulSoup 确实会处理如 <、& 等标准实体，但像 、— 这类属于HTML 4或5规范中的“命名字符引用”。部分旧版本解析器（尤其是Python内置的 html.parser），默认支持可能不完整，或在特定上下文中选择保留其原始形式。

解决方案是什么？一个简单且可靠的兜底策略是：在通过 .get_text() 获取文本后，再次统一使用 html.unescape() 进行处理。

立即学习“Python免费学习笔记（深入）”；

from bs4 import BeautifulSoup
import html

soup = BeautifulSoup(response.text, 'html.parser')
raw_text = soup.find('div', class_='content').get_text()
clean_text = html.unescape(raw_text)  # 这步不能省

• 解析器选择有讲究：lxml 解析器对命名实体的支持通常更佳，但并非万能。遇到自定义DTD或非标准实体时，仍可能出现问题。因此，添加 html.unescape() 这步“保险”操作依然建议保留。
• 避免方法误用：请注意，soup.decode() 或直接 str(soup) 返回的是HTML源码字符串，而非解码后的纯文本，切勿将其与 .get_text() 的结果混淆。
• 编码问题优先处理：若遇到页面元标签声明为 ，但服务器响应头却为 utf-8 的情况，务必首先确认 response.encoding 设置正确。否则，在解码HTML实体之前，文本本身可能已因编码错误而呈现乱码。

使用正则匹配HTML并手动unquote，为何会错误替换URL中的&符号？

这是一个典型的“过度处理”引发的错误。例如，尝试使用正则表达式 re.sub(r'&(\w+);', ...) 匹配并替换所有实体时，却忽略了URL查询参数中本应存在的 & 符号（例如 ?a=1&b=2）。正则表达式盲目操作，将作为参数分隔符的合法 & 也替换掉，导致链接失效。

• 核心原则：勿用正则解析HTML结构：HTML实体可能嵌套、跨标签或隐藏在属性值中，正则表达式无法可靠识别这些复杂上下文中的边界。
• 标准文本提取流程：若目标是从HTML片段中提取纯文本，最安全的路径是：先使用 BeautifulSoup(...).get_text() 提取内容，再应用 html.unescape() 进行清理。此方法完全规避了HTML结构的干扰。
• 专用工具处理URL：若仅需处理URL中的查询参数，请使用 urllib.parse.parse_qs() 或 parse_qsl()。这些工具专为解析URL参数设计，能自动处理 %xx 形式的百分号编码，而不会误触 & 等HTML实体。

Scrapy框架中response.css()提取的文本包含未解码实体，如何在pipeline中统一处理？

在Scrapy框架下，通过 response.css() 或 .xpath() 提取的文本节点，虽经初步解析，但其行为与 BeautifulSoup 类似：通常仅解码标准实体，对完整命名实体集的支持可能不彻底。

• 处理时机宜早不宜迟：建议在 ItemLoader 或Spider的 parse() 方法中，就对每个提取的字段执行 html.unescape() 处理。避免拖延至后期的pipeline，处理越晚，越易遗漏或与其他清洗步骤产生冲突。
• 封装通用处理函数：一种高效做法是利用 ItemLoader 的 MapCompose 功能，封装通用处理链。例如：MapCompose(html.unescape, str.strip)，并将其直接绑定到Item Field的 input_processor 上，实现自动化清洗。
• 数值实体同样支持：请放心，即使是像 〹 这类使用十进制数值表示的实体，html.unescape() 同样能够正确解码，无需额外操作。

总而言之，HTML实体解码看似简单，真正的难点往往在于“由谁处理、在哪个环节处理、处理几次以及上下文是否干净”。最稳健的路径非常明确：让解析器（如 BeautifulSoup、lxml）专注于解析文档结构，然后使用 html.unescape() 作为最终文本的“清洁工”。中间环节尽量避免手动干预，即可规避绝大多数常见问题。