从乱文本里提取手机号:电话号码提取与去重清洗指南

做运营和数据整理的人,手上总会攒下一堆"半结构化"的文本。一段微信群聊记录、几百行客服工单导出、从老网页复制下来的联系页,里面藏着电话号码,可它们和姓名、订单号、广告语、HTML 标签混在一起。你想要的只是一份干净的号码清单,但手工一个个挑出来既慢又容易漏。这篇就讲怎么把这件事做对。

先看一个真实的输入输出例子

假设你从一份报名表里复制出这样一段:

张三 138 0013 8000,备注:首选
李四 联系电话 010-8888 6666 转 203
王五 +86 159-2233-4455(已确认)
重复一行:王五 +8615922334455
座机 0755 12345678
错号 415-555-013

把这段粘进电话号码提取器,它扫一遍就只留下号码本身,周围的姓名、备注、括号、转分机这些全部丢掉。识别后的结果大致是:

13800138000   有效   手机号
01088886666   有效   座机(区号 010)
8615922334455 有效   带国家码手机号
07551234567   有效   座机(区号 0755)
415-555-013   无效   位数不足

注意第三行的 +8615922334455 和第五行其实指向同一个王五,去重后只保留一条;而 415-555-013 少一位,工具不会偷偷丢掉它,而是带上"位数不足"的原因列出来,让你自己判断是真号码还是一串长得像的数字。

它怎么识别不同的号码格式

号码格式识别是这类工具的核心,也是最容易出错的地方。提取器要同时认得几种常见写法:

手机号:11 位,常见 13/14/15/16/17/18/19 开头,可能带空格或短横线分隔,如 138 0013 8000、159-2233-4455。
座机:区号加本地号,区号 3 到 4 位,如 010-8888 6666、0755 12345678,中间的分隔符要先剥掉再判断。
带国家码:+86 或 0086 前缀,提取后规范化成统一形式,这样 +86 159... 和 15922334455 才能被认成同一个号去重。
转分机:转 203、ext.203 这类尾巴不是号码的一部分,识别时要切掉,否则会污染去重。

识别逻辑跑完后,每一行都带上规范化值、校验状态和原因。这比单纯一个正则"抓到就算"要稳得多,因为真实文本里到处是差一位、多一位、夹杂订单号的近似串。

去重和排序:把名单整理成可交接的样子

我自己整理报名名单时最头疼的就是重复。同一个人可能在表里出现三次,写法还各不一样:一次带 +86,一次纯 11 位,一次中间打了空格。如果只按字符串比对,这三条会被当成三个人。正确做法是先规范化再去重,把所有写法折叠成同一个标准形式后再比对,重复的就只剩一条。整理完按号码排序,导出 CSV 交给 CRM 或脚本,对方拿到的就是一份没有重复、格式统一的干净名单。

如果你只想做去重这一步,不需要完整的提取流程,可以直接用电话号码去重,把已经是一行一个号码的列表丢进去折叠重复项。

为什么坚持本地处理

电话号码是实打实的个人信息。客户名单、内部联系人、销售线索,这些东西一旦发到外部服务器就有泄露风险,很多公司的数据合规也明令禁止。电话号码提取器的解析、校验、去重、导出全部在你当前这个浏览器标签页里跑,上传的本地文件是通过浏览器 File API 读取的,号码不会发到 Toolora 服务器。

这一点对运营、客服、法务这类天天碰联系人数据的岗位特别重要。你可以放心把整份工单存档、聊天导出粘进去,几 MB 的文本瞬间就扫完。要是遇到几个 GB 的超大转储,先在本地用 grep 把含号码的行筛出来,再粘进工具处理,效率更高。

几个容易踩的坑

整理过几轮之后我总结出几条经验:

第一,格式正确不等于号码真实存在。提取器只负责把符合规则的串挑出来,它没法替你确认这个号码当前是否在用,真要外呼或发短信前还得另做核实。

第二,从网页复制来的文本常带不可见的空白字符,比如全角空格、零宽字符。这些会让看起来一样的号码被当成不同值,所以导入前一定先规范化再去重。

第三,如果这份名单要留审计线索,别只复制最终列表,顺手下载一份带行号的 CSV 或 Markdown。哪天有人问"这个号码从哪来的",你能直接翻回原文那一行。

把这套流程跑顺之后,原来要花半小时手工挑号码的活,现在粘贴、去重、导出三步就完事,而且全程没有一个号码离开过你的电脑。

Made by Toolora · Updated 2026-06-13