URL 校验实战:把一行一个的链接批量检查出有效和无效

手里攒了一份外链清单,几百行 URL,准备导入 CRM 或者写进重定向表。问题是这份清单从哪来的都有:有人从浏览器地址栏复制,有人从 Excel 拉出来,还有从客服工单里抠出来的。里面混着拼错的域名、漏了协议头的裸链接、末尾粘了空格的脏数据。一行一行肉眼看显然不现实,这时候就需要一个能批量校验 URL 的工具。

批量校验到底在检查什么

很多人以为 URL 校验就是看看链接能不能打开。其实不是,能不能打开取决于服务器,那是联网请求的事。格式校验只看一件事:这一行字符串符不符合 URL 的书写规范。具体拆成三段来判:

第一段是协议头,也就是 https:// 或 http:// 这一截。漏掉它,example.com/page 这种写法就只是一段文本,不是合法 URL。

第二段是主机名,也就是域名部分。主机里不能出现空格、中文逗号、半个括号这类非法字符。exa mple.com 中间多了空格,例子。com 用了全角句号,都会在这一段被判失败。

第三段是路径和端口。端口必须是数字,https://host:80a/ 里的 80a 不是合法端口,会被点名。路径部分相对宽松,但整体仍要能被 URL 解析器接住。

把这三段都过一遍,才算真正完成一次格式校验。URL 链接列表校验器 就是逐行按这套规则判定,每一行标出通过或失败,失败的旁边写明是哪一段出了问题。

一份真实清单跑出来的样子

举个我自己常遇到的例子。假设输入是这么六行:

https://toolora.info/zh/t/url-list-validator/
http://example.com:8080/path
example.com/no-scheme
https://exa mple.com/space
https://host:80a/badport
https://正确域名.cn/页面

跑完之后,结果会清清楚楚分成两堆。

通过的有三行:第一行规范完整;第二行带了合法端口 8080;最后一行虽然是中文域名,但全角字符都在合法范围内,照样过。

失败的也是三行,而且每行都带原因:example.com/no-scheme 缺协议头;https://exa mple.com/space 主机里混了空格;https://host:80a/badport 端口写错了。原因列直接点到那一段,不用再回头猜。

这种带原因的输出,比单纯标个红叉有用得多。你能立刻知道是补个 https:// 就行,还是这一行根本是拼错的废链接得删掉。

导入前的清洗顺序

校验只是第一步。一份能交接的清单,往往要走完整的清洗流程,顺序很有讲究:

先规范化。从网页复制来的文本经常带隐藏空白,看着没问题,导入时却对不上。先把首尾空格、零宽字符这类杂质清掉。

再去重。一份合并了多个来源的清单,重复链接是常态。去重之后行数往往砍掉一截,后面的人工复核量也跟着降下来。

最后选导出格式。要塞进脚本就导 JSON,要写进数据库查询就导 SQL IN,要交给前端就导 TypeScript union。不用再手工加引号、补逗号,省掉一轮容易出错的体力活。

如果你的清单是从一大段网页或 Markdown 里抠出来的,可以先用 URL 链接提取器 把链接捞出来,再丢进校验器走上面这套流程,衔接得很顺。

为什么坚持本地处理

我处理外链清单时有个硬习惯:能不上传就不上传。这些清单里常常夹着客户域名、内部跳转地址,甚至带 token 的回调链接。把这种数据传到任何第三方服务器,都是给自己埋雷。

校验器的解析、去重、导出全在浏览器这一个标签页里跑完,上传的本地文件也只是通过浏览器读一遍,不会发到服务器。这意味着哪怕断网,工具照样能用,数据也始终在你自己机器上。对运营和开发来说,这一点比快几毫秒重要得多。

一个容易踩的坑

最后提醒一句:URL 格式正确,不等于这个链接真实存在。校验只保证书写规范,不保证域名注册了、页面还在、资源没被删。如果你要的是可达性验证,那是另一回事,得真的去请求一次。把格式校验和真实性验证分清楚,才不会拿着一份格式漂亮的死链清单白忙活。

想留审计线索的话,别只复制最终列表,顺手把带行号的 CSV 一起下载下来,后面回查时能对得上原始位置。

---

Made by Toolora · Updated 2026-06-13