展会官网数据采集与清洗：邮箱解码、电话校验与多页爬取实战

1. 项目背景：一个展会官网到底埋了多少坑

1.1 这个爬虫到底要爬什么

做展会类网站的数据采集，尤其是跨境B2B展会，最让人头疼的其实不是数据量大，而是数据本身不规整。前阵子我接了一个某国际塑料行业展会官网的数据采集项目，目标是把所有展商名录、产品分类、联系方式做成结构化数据，后续拿去做买家和供应商匹配。

本来以为这是一个常规的列表页爬虫项目，毕竟展会官网的栏目再复杂，也无非是“行业分类页—展商列表页—公司详情页—产品子页”这种树状结构。可真把入口页面打开以后，我发现自己太乐观了。展商详情页里的邮箱不是明文，联系电话格式也完全没有统一标准，列表页里还混着不少主办方、承办方的栏目卡片。更麻烦的是，详情页并不都从一个列表入口进入，有的藏在往届回顾栏目里，有的挂在分类标签下面，还有一部分要通过翻页参数才能发现。

最终字段其实很清晰：公司名称、展位号、行业类别、官网、邮箱、电话、地址、来源URL。但字段越简单，脏数据的破坏力越大。如果一开始不把清洗规则设计好，等数据量冲到几千条再回头处理，代价会成倍上升。所以我当时给项目定了三条硬性要求：每条数据必须可追溯来源，联系人字段必须规范化，公司主体必须先过滤再入库。

1.2 为什么四个难点要按顺序攻坚

展会爬虫本身不算稀罕，很多同行的做法是拿一个通用框架，套上站点规则就开始跑。但这个项目很快撞上四堵墙：邮箱编码解码、国际电话验证、主办方过滤、多页面深度爬取。这四个问题看着各自独立，实际上前后牵扯。

邮箱不解码，电话就无法和邮箱关联起来做联系人完整性判断；电话不标准化，公司去重就没有稳定主键；主办方不过滤，数据处理完才发现库里一半是展会服务商而不是参展企业；多页面链路不打通，前面三项做得再好，也覆盖不了全部数据源。

所以这篇文章按我实际攻坚的顺序来写，每一段尽量给出能直接落地的方案和代码。如果你正在做展会名录采集、行业黄页清洗、企业库构建这类项目，应该能少踩几个坑。

2. 邮箱编码解码：被HTML实体和脚本拼接双重夹击

2.1 展会官网里的邮箱为什么不是明文

一开始我直接用正则去匹配HTML源码里的邮箱明文，结果第一轮下来漏了一大半。原因很简单，前端工程师不想让爬虫这么轻松拿到邮箱，但又希望正常用户能看见，所以会做一层或多层“伪隐藏”。

最常见的是HTML实体编码。页面源码里看起来是info@example.com，浏览器渲染时会自动把@转成@，把.转成小数点，所以人眼看到的是正常邮箱，但爬虫拿正则去匹配明文邮箱时，一个都匹配不到。第二种是JS动态拼接，比如源码里只写了'info' + '@' + 'example.com'，或者把邮箱拆成几个片段放进数组，再在脚本里join('')。第三种是编码混淆，常见的有Base64、URL编码、简易的字符串翻转，有时还会混合使用。

展会官网不像高安全系统那样做高强度混淆，但只要上了任一种，普通文本抓取就会失效。我一开始看到邮箱字段里的@还暗自高兴，以为只有一种实体编码。结果多抓几个页面才发现，不同栏目用的是不同模板，有的详情页邮箱必须等脚本执行后才出现。所以第一件事永远是摸底：把这个站所有页面模板翻一遍，搞清楚存在几种编码形式，再写统一解码逻辑。

2.2 实体解码与动态拼接处理方案

我的方案分三步走。

第一步，对静态HTML先做实体解码。直接用Python标准库的html.unescape()，它能自动把@、.这类的数字或命名实体还原成普通字符。解码之后再用常规邮箱正则提取。

from html import unescape import re html_source = "info@example.com" text = unescape(html_source) emails = re.findall(r"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}", text)

这一步等同于先把HTML“翻译回人类可读文本”，再抽取字段。别看只是简单调用，很多直接抓源码的正则方案就是漏掉这一行。

第二步，检查页面有没有可执行的JS编码逻辑。如果邮箱藏在脚本里，我不会一上来就启动浏览器去完整渲染页面，而是先看这段脚本到底做了什么。比如脚本写的是：

var a = ['info', 'example', 'com']; var email = a[0] + '@' + a[1] + '.' + a[2];

这种属于简单拼接，直接用静态分析就能还原。更复杂一点会用Base64：

var email = atob('aW5mb0BleGFtcGxlLmNvbQ==');

遇到这种情况，我一般先把JS片段截下来，找出编码函数和解码函数，再用同样的规则在Python里还原。比起操作无头浏览器，这种静态还原方案速度快得多，也更好维护。

第三步，如果整个站点是动态渲染，邮箱数据是前端请求接口拿到的，那就直接定位接口URL。接口返回的JSON里如果邮箱又编码了一次，再按第二步的逻辑解码。核心思路是：先搞清楚数据到底从哪一层来，再决定解码策略，不要盲目处理渲染后的HTML。

2.3 邮箱解码环节的三个典型坑

第一个坑是误把非邮箱的乱码当线索。有些页面上会有“数据保护”文本或者售后服务占位符，看起来像presse@xxx.com，解码之后也确实能当邮箱入库，但这类邮箱不一定属于参展企业，可能是展会服务商的统一客服邮箱。判断标准我后面会提到，一定不能只看联系方式格式，要看主体身份。

第二个坑是同一个字段里混了多个邮箱。比如有的详情页写“市场部：[e-mail] 技术部：[e-mail]”，正则写得太贪婪会把两个邮箱吸成一个字符串，或者干脆匹配失败。我的做法是先按空格、逗号、分号切分文本，再逐段提取邮箱。

第三个坑是邮箱解码后的噪音字符。有些HTML源码会有 之类的空格实体，也有反斜杠转义，提取出来的邮箱可能带着末尾的空白或引号。入库前要统一做一次strip()和常见符号清理。另外要留意邮箱去重，不同展会栏目可能重复收录同一企业，邮箱就是很好的去重凭证。

提示：这部分只处理页面公开的信息，不要试图去挖非公开数据。展会网站里的展商联系方式本来就是给买家看的，做结构化整理没有合规问题，但拿到数据之后不要滥发邮件，这会影响行业形象，也可能招来投诉。

3. 国际电话验证：把“像电话号码的字符串”变成标准号码

3.1 展商电话在HTML里能乱成什么样

展会网站的展商信息经常来自参展商自己提交的表格，所以电话字段的格式五花八门。我见过这些情况：

• 完整国际格式：[phone]
• 只有本地号码：010-12345678
• 带括号分机：+00 (0) 1234-5678 ext.102
• 不同号码混一列：12345678 / 87654321
• 传真夹在电话字段里：Tel: [phone] Fax: [phone]
• 还有直接把手机号写成009-123-4567这种不连续状态的

如果只靠简单正则把所有非数字字符去掉，必然会走向两个极端。一种是把“123456”这种片段也当成电话，另一种是把原样字符串整段收入库，导致后续外呼系统根本没法处理。

我们收集联系方式是为了后续做展会通知、电话回访这一类真实业务，所以电话有效性直接决定这条线索能不能用。这里说的“国际电话验证”，本质是标准化加真实性校验，不是真的去拨每一通电话，而是在入库前把号码格式统一成国际标准，并且验掉明显不存在的号码。

3.2 标准化加校验的实现步骤

我的清洗流程是：先去噪，再补国家码，最后用phonenumbers库做校验和格式化。

“去噪”在正则层面就是去掉空白、括号、连字符、点、斜杠这些分隔符，只保留数字、加号和分机信息。这里要注意，不要把所有非数字字符都删掉，加号是国际格式必需的一部分，分机号码也不是必须删除的部分，应该单独拆到子字段里。

然后处理国家码。展会数据通常有明确的目标国家，大部分跨境企业会写完整国际格式，但当地中小企业经常只填本地号码。这时候要补一个默认区号，具体规则是：如果字符串不是加号开头，就在前面拼接展会主办方所在国家的国际区号，并且把号码开头的长途前缀0去掉。

import re import phonenumbers from phonenumbers import PhoneNumberFormat DEFAULT_REGION = "XX" DEFAULT_COUNTRY_CODE = "+000" def normalize_phone(raw): if not raw: return None # 去掉常见分隔符，并把传真/分机拆出去 text = re.sub(r"[()\-\s./]", "", raw) text = re.sub(r"[;,].*$", "", text).strip() # 没有国家码就补一个，本地号码的0会由phonenumbers按区域规则处理 if not text.startswith("+"): text = DEFAULT_COUNTRY_CODE + text try: parsed = phonenumbers.parse(text, DEFAULT_REGION) if phonenumbers.is_valid_number(parsed): return phonenumbers.format_number(parsed, PhoneNumberFormat.E164) except phonenumbers.NumberParseException: return None return None

这里有两个细节值得说明。is_valid_number会根据国家区号是否已分配、号码位数是否合理、区号是否存在来做综合判断，像明显瞎编的号码会被直接筛掉。format_number(..., E164)会把号码标准化成“加号开头的连续数字串”，这是国际通信交换最通用的格式，后续不管接外呼系统还是做数据库匹配都很方便。

在实际项目中，DEFAULT_REGION和DEFAULT_COUNTRY_CODE一般是全站配置，按照展会主办方所在国家填写，不要在每个解析函数里硬编码。如果某个文本段既包含电话又包含传真，我会先判断里面有没有fax或传真这样的关键词，然后把它们分别写入电话字段和传真字段，避免把传真号码当成主电话。

3.3 把电话分成“能打”和“不能用”

光靠一个函数返回None或号码，还不够。我在这个项目里把电话状态分成四类，方便后续业务判断：

状态	判断条件	处理方式
有效主号	E.164格式化后通过校验	直接入库
可修复号	只缺国家码或多了括号，补全后通过校验	修复后入库
无效号码	数字位数少于7位或超过15位，或明显是网络占位号	剔除并记录原值
传真/分机	文本里包含Fax、传真、Ext等关键词	拆到独立子字段

这样分完之后，后续做电话外呼和线索分配就简单多了。另外还有一个好处，电话标准化之后可以参与公司级去重。同一个企业可能出现在“往届回顾”和“本届列表”两个入口下，公司名不完全一致，但联系电话通常很稳定，拿标准化电话做相似性判断比纯比公司名字可靠得多。

4. 主办方过滤：把“管展会的”和“参展的”区分开

4.1 组委会为什么总是混进展商名册

展会官网的内容模型有几个天然缺陷。一个展会页面上，既要展示“组织机构”，又要展示“展商名录”，这两类内容往往共用同一个卡片组件。前端开发图省事，常常把它们塞进同一个列表容器，只是栏目名不同。结果就是，爬虫按列表页统一逻辑抓取时，组委会、承办单位、支持媒体全都混在展商数据里。

我一开始想过用URL路径来判断，看到路径里有organizer或committee就不抓。但很快发现，同一个机构可能既出现在“主办单位”栏目，又出现在“支持单位”栏目，还可能作为参展企业出现在展商列表里。仅凭URL路径根本区分不了。

4.2 基于区块与关键词的过滤规则

最后我采用的是多因素打分制，不搞一刀切。这个打分制分三层。

第一层，在页面解析阶段就记录内容区块来源。当前卡片属于“展商名录”还是“组织机构”，这本身是一个强信号。第二层，看公司名称和简介里的关键词，比如“组委会”“主办单位”“承办单位”“协办单位”“媒体支持”这类词，一旦出现就明显偏主办方。第三层，看有没有展位号。真正的参展企业通常会分配一个展位号，而主办单位页面里很少会写展位号。

多层信号组合之后，用分数阈值决定是否排除。比如“出现在组织机构区块”给3分，“名称含主办方关键词”给2分，“没有展位号”给1分，总分大于等于3就标记为非展商。

ORGANIZER_WORDS = ["组委会", "主办单位", "承办单位", "协办单位", "媒体支持", "秘书长"] ORGANIZER_SECTIONS = {"organizer", "committee", "support_media"} def is_organizer(record): score = 0 text = record.get("name", "") + " " + record.get("description", "") for word in ORGANIZER_WORDS: if word in text: score += 2 break if record.get("section") in ORGANIZER_SECTIONS: score += 3 if not record.get("booth_number"): score += 1 return score >= 3

这套规则的关键在于“组合判断”。如果某一页里有一个“某协会展商”，名称带协会两个字，但它在展商名录区块里，而且有展位号，那么它只会得1分，不会被误杀。这比简单黑名单灵活得多，也能平滑处理不同模板的差异。

4.3 误杀与漏杀怎么平衡

我当时做完第一版过滤后，抽样200条数据人工核对，发现大概有3%的误杀率和4%的漏杀率。误杀主要发生在行业媒体，它们既是媒体支持单位，又以参展商身份买了展位。漏杀主要发生在“XX国际展览有限公司”这种企业，它们名字里没有组委会，却是展会服务商。

于是我给“XX国际展览有限公司”这类企业增加了新的规则。如果名称命中“展览公司”“会展公司”这类字样，且没有展位号，同样进非展商。反过来，如果它出现了展位号，就当展商保留。这个取舍没有一个绝对正确的标准，取决于项目目标数据到底要什么。如果你要的是塑料制品生产商，那展览服务公司不管有没有展位号都不该入库；如果你要的是完整的买家线索池，那它们可能还有保留价值。

所以过滤规则不要一遍写死，要留出配置化的空间。我习惯把关键词表和分数线抽到配置文件里，或者设计成数据库表，让运营人员可以随时调整，而不是每次改规则都重跑代码。

5. 多页面深度爬取：列表、详情、产品页一次走通

5.1 列表页、详情页、产品页的关系

这个展会官网并不是“一个列表页就能抓完”的结构。它大体上是：行业导航首页 → 产品分类页 → 公司列表页 → 公司详情页 → 公司产品子页。我把它叫多页面深度爬取，因为要沿着链接不断往下走，而不是抓完一个列表目录就收工。

实际做的时候，第一个难点是分页规则不一致。有的分类页URL是/exhibitors/，翻页后变成/exhibitors/index_2.html；有的产品分类页直接用查询参数?page=2；还有的地方翻页按钮是动态加载的，初次HTML里根本看不到下一页的URL。所以动手写爬虫之前，我要把主栏目、分页链接、详情页入口之间的关系人工梳理一遍，形成一个入口URL清单。

5.2 用队列加去重集合完成全站遍历

对于这种网站，我不太喜欢搞重量级框架，一个轻量调度器完全够用。基本结构是三个对象：一个双端队列存放待抓取URL，一个去重集合保存已访问URL，一个重试字典记录失败次数。

思路很简单：先把入口URL加入队列。每次从队列左侧取一个URL，如果已经在访问集合里就跳过。请求成功之后解析页面，拿到下一页和详情页链接，未访问过的加入队列。请求失败就把URL记入重试字典，重新放回队列，最多重试三次。

import time from collections import deque class LightCrawler: def __init__(self, start_urls, parser): self.queue = deque(start_urls) self.visited = set() self.retries = {} self.parser = parser def run(self, max_pages=5000): while self.queue and len(self.visited) < max_pages: url = self.queue.popleft() if url in self.visited: continue try: next_urls, items = self.parser(url) self.visited.add(url) for item in items: self.save(item) for next_url in next_urls: if next_url not in self.visited and next_url not in self.queue: self.queue.append(next_url) time.sleep(1.5) except Exception: self.retries[url] = self.retries.get(url, 0) + 1 if self.retries[url] <= 3: self.queue.append(url) print("crawled pages:", len(self.visited))

time.sleep(1.5)是一道主动限速，目的是避免对一个站点发起高频请求。抓取公开数据也不代表可以无限压力，一个稳重的爬虫应该把目标站点当正常用户访问那样对待。另外，正式抓取前应该检查站点声明的访问规则，遵守站内说明，这是基本的职业素养。

5.3 断点续爬与内容级去重

实战里爬虫跑到一半挂了很正常，可能是网络抖动，也可能是详情页结构临时出错。所以我在项目里把visited和queue的状态定期保存到本地，每次启动时先加载历史进度，而不是从头再跑一遍。实现方法也很简单，轮流把集合和队列序列化到文件里，或者用一个SQLite表存状态。

除此之外，URL级去重解决不了内容重复。同一个公司详情页可能被多个分类列表重复引用，URL不同，内容却一样。这时我会生成一个内容指纹，用“公司名 + 标准化电话 + 邮箱列表”拼起来算MD5。为什么把电话放进去？因为公司名可能大小写不同、繁简体混用，但电话经过标准化之后非常稳定。指纹相同就说明是同一家公司，后续入库时做合并处理。

import hashlib fingerprint = hashlib.md5( (company_name + "|" + phone_e164 + "|" + "|".join(sorted(emails))).encode() ).hexdigest()

这一段内容级去重和前面的电话标准化是联动的。电话不规范，指纹就不稳定；主办方不过滤，指纹会把组委会也算成一家公司。做完这些前置清洗之后才去重，才真的有意义。

6. 整条流水线组装：从HTML到干净线索库

6.1 主流程：从请求到入库

单看某个环节都不难，难的是串联。我最终落地的流程是这样：

1. 站点结构侦察：人工跑一遍主要分类页，记录所有入口URL。
2. 入口列表建设：把分类页、列表页、摘要页入口写进启动配置。
3. 启动爬虫：用队列调度器逐页遍历，解析时保留区块来源和栏目归类。
4. 原始字段提取：从详情页抽取公司名、展位号、官网、地址、联系方式等。
5. 邮箱解码：对HTML实体、JS拼接、接口编码分别调用对应的解码函数。
6. 电话标准化：按照国际格式清洗并校验号码。
7. 主办方过滤：用打分规则剔除组委会、承办方、展览服务商。
8. 内容级去重：生成指纹并合并重复公司。
9. 入库：写入结构化数据库，记录来源URL和抓取时间。

这个流程每个环节之间用标准字典传参，解析器只负责产出原始字段，清洗函数只负责数据标准化，过滤规则只在入库前生效。解耦带来的好处是，某个展会页面结构调整了，我只需要改parser这一层，后面所有逻辑都不用动。

6.2 一条数据的清洗流水线

核心清洗函数大致是这样：

def process_item(raw): emails = decode_emails(raw.get("email_html", "")) phone = normalize_phone(raw.get("phone_text", "")) if is_organizer(raw): return None return { "company_name": raw["company_name"].strip(), "booth_number": raw.get("booth_number", "").strip(), "category": raw.get("category", ""), "emails": emails, "phone": phone, "website": raw.get("website", "").strip(), "source_url": raw["url"], "crawled_at": time.time(), }

注意emails这里返回的是一个列表，因为一个公司可能留了销售部和技术部两个邮箱。电话则是单个字符串，保留主号即可。如果电话标准化失败，我不会立刻放弃这一条，而是把原始文本放回待清洗区，后续用样本核对是规则问题还是号码本身无效。

6.3 最终入库字段长什么样

最终表结构我列一下，给做同类项目的朋友一个参考：

字段名	来源	清洗逻辑	输出示例
company_name	详情页标题	去空白、去标签	某新材料科技有限公司
booth_number	展位信息	统一成大写	A123
category	分类页面锚文本	列表标准化	塑料机械
emails	邮箱区	实体解码+正则+去重	[[e-mail]]
phone	联系方式文本	电话标准化+校验	+00012345678
website	官网字段	去除参数尾巴	https://www.example.com
source_url	抓取时URL	直接保留	https://expo.example.com/detail/123
crawled_at	抓取时间	时间戳	1730000000

source_url和crawled_at看着不起眼，却是后期排查问题的救命字段。一旦发现某条数据有问题，可以直接定位到它来自哪个页面、什么时候抓的，再去对比页面结构变化。

7. 现场踩过的坑与问题排查速查表

7.1 三个印象深刻的现场错误

第一个错误发生在邮箱提取阶段。我以为页面源码里没有邮箱就是真的没有，后来发现很多展商详情页的邮箱要点击“显示联系方式”按钮才会加载。用户能看到邮箱，是因为前端触发了一个请求。我调试了很久才反应过来，把解析逻辑改成在脚本执行后再读取联系方式区域，而不是只抓初始HTML。

第二个错误是传真混入电话字段。某个页面的电话字段写了“Tel: [phone] Fax: [phone]”，我的清洗代码直接消掉分隔符后把两个号码拼成了一个超长号码，结果被phonenumbers判定为无效号码。后来我调整了逻辑，遇到fax或ext关键词，先把电话和传真拆分，再分别处理。

第三个错误是主办方过滤过严。有一类行业媒体协会确实参展了，但公司名称里带着“协会”“联合会”字样，被我误判成主办方挡在库外。后来人工抽样发现这个误杀率不低，才引入了“展位号优先”的逻辑：只要有真实展位号，即使名称里有主办方关键词，也先保留为展商。

7.2 问题排查速查表

现象	可能原因	解决办法
邮箱字段抓不到	HTML实体没解码	先调用html.unescape()再匹配
邮箱缺一半	正则贪婪匹配跨字段	先按分隔符切分文本，再逐段提取
电话格式不统一	缺少国家码、存在分隔符	按E.164标准做清洗和校验
传真混进电话	电话字段包含Fax/Ext	拆分到独立子字段
公司重复入库	同一公司被多个入口收录	用“公司名+电话”做内容指纹去重
主办单位混进展商	栏目区块没区分	增加区块来源评分规则

7.3 一个直到项目后期才发现的小功能

最后再分享一个小技巧：给每条数据都保存来源URL和抓取时间，看似多余，实际上越早做越好。

这个项目跑到第五轮增量更新时，某个详情页改了页面结构，导致新抓的数据里地址字段全部丢失。因为每条数据都有来源URL和抓取时间，我很快定位到晚一天入库的那批记录，拉出对应页面一对比，发现是HTML模板变了。如果没有这两个字段，我恐怕要全表重扫才能定位范围。做数据采集项目，第一条原则永远是“每条数据都能说清楚自己从哪里来”。这个原则越早落地，后期维护成本越低。