从文本里批量提取链接 URL:去重、过滤域名与本地清洗实操

一段聊天记录、一份 CSV 导出、一页复制下来的 HTML,里面常常埋着几十上百个链接。手工一个个找出来再去重,既慢又容易漏。把这种混乱文本变成一份干净、可复核的 URL 列表,才是真正能往下用的产物。下面讲清楚整个流程,以及为什么我更倾向于在浏览器本地做这件事。

提取链接到底在解决什么问题

很多人以为提取 URL 就是正则匹配 https:// 开头的字符串。真做起来没那么简单。复制网页时,链接会裹在 HTML 标签里;邮件正文里,链接尾部常粘着标点;Markdown 笔记里,链接藏在 [文字](地址) 的括号中。这些都需要先剥掉外层内容,只留下纯链接。

更麻烦的是重复。同一份资料从三个渠道汇总,同一个链接出现五六次很正常。如果不去重就导入 CRM 或工单系统,后面对账会被重复项拖累。所以提取这一步,本质是把不可控的原始文本,变成行号清晰、规范化、可校验的审计表。

一个真实的输入输出例子

我手头有一段从工单里复制的客服回复,原文是这样:

您好,问题文档见 https://docs.example.com/guide?id=12 ,
另外参考 http://blog.example.com/post-1。
旧链接 https://docs.example.com/guide?id=12 已失效,
统计后台 example-internal 暂时打不开。

把它粘进 URL 链接提取器后,输出是这样一张去重表:

| 行 | 规范化值 | 状态 | | --- | --- | --- | | 1 | https://docs.example.com/guide?id=12 | 有效 | | 2 | http://blog.example.com/post-1 | 有效 | | 4 | example-internal | 无效:缺少协议头 |

四处提及,实际只有两个唯一有效链接。第 1 行末尾粘着的逗号被自动裁掉,重复的那条被合并,而 example-internal 这种裸名被标成无效但仍带出来复核。这就是我要的:既干净,又不丢线索。

去重和按域名过滤怎么用

去重默认按规范化后的值比较,所以 https://docs.example.com/guide?id=12 末尾带不带空格、带不带尾部标点,都会被当成同一条。这一点对从网页复制的文本尤其重要,因为复制内容常带隐藏空白,不先规范化就去重,会留下一堆看起来一样实则字符不同的"假重复"。

按域名过滤则适合两类活:一类是整理收藏,你只想留下某个站点的页面,把其余噪声链接剔掉;另一类是做抓取清单,你需要先确认目标域名集中、没混进外站。把规范化结果排序后,同域名的链接会自然聚在一起,扫一眼就能判断分布是否合理。

整理收藏、抓取清单与数据清洗

我自己最常用它做三件事。整理收藏时,把浏览器历史或几个笔记里的链接一股脑粘进来,去重后导出 Markdown,直接归档。准备抓取清单时,我会保留无效项一起看,因为一个缺协议头的裸域名往往提醒我:这里漏抄了 https://,得回原文补。做数据清洗交接时,我不只复制最终列表,而是下载带行号的 CSV,这样接手的人能回到原文每一行核对来源。

需要开发可用的产物时,这个工具还能把列表直接转成 JSON、SQL IN 或 TypeScript union,省掉手工加引号、补逗号的活。如果你处理的是 Markdown 文档里的链接,Markdown 链接提取器会更对口,它专门认 [文字](地址) 这种语法。

为什么坚持本地处理

工单、日志、聊天记录里往往夹着客户数据、内部域名甚至访问 token。把这种文本贴到一个把内容发回服务器的在线工具,本身就是风险。URL 链接提取器的解析、校验、去重、复制和下载全在浏览器当前标签页完成,上传的本地文本文件也只通过 File API 读取,不离开你的设备。

这也带来一个实际好处:没有网络往返,几 MB 之内的文本几乎瞬间出结果。当然它不是为上 GB 的爬取归档设计的,那种量级建议先在本地 grep 出相关行再贴进来。对日常的页面源码、聊天记录、导出文档来说,这个边界足够用了。

一句话总结:提取链接不是把字符串抠出来就完,而是把杂乱来源整理成可复核、可交接、可复用的列表。让这件事留在本地,既快又稳。

Made by Toolora · Updated 2026-06-13