上一篇
如何用正则获取域名？正则表达式提取主域名的方法
用简洁的字符模式匹配域名结构，同时避开杂乱的协议、路径和参数，推荐从“主机名部分”入手，配合在线工具调试验证。
很多开发者在处理文本时都会遇到同样的场景：日志里躺着海量URL，用户留言里夹杂着链接，或者需要从数据库字段中抽出干净的域名，直接手写正则容易翻车，但掌握几个关键思维,规则本身就会变得顺理成章。
正则获取域名时最常见的匹配规则有哪些？
域名由标签和点组成，www.example.com 由三个标签构成，每个标签可以用字母、数字和连字符，但连字符不能出现在开头和结尾，顶级域（TLD）之前的部分我们称为二级域名或子域名，匹配时通常关注“完整主机名”。
基础正则示例
从一个标准URL中提取域名，最简单的做法是匹配“协议之后、路径之前”的部分，以 https://www.example.com/path?query=1
但这只能处理带协议的URL，如果文本里既有裸域名 example.com，又有 www.example.com 和 https://blog.example.com
(?:[a-zA-Z0-9-]+.)+[a-zA-Z]{2,}
这个模式的工作方式：
- (?:[a-zA-Z0-9-]+.)+ 匹配一个或多个“标签+点”的组合，example.、blog.example.
- [a-zA-Z]{2,} 匹配顶级域，至少两个字母，如 com、org、cn
为什么不能直接复制网上所有正则
网上的“通用域名正则”往往一长串，包含各种边界情况和顶级域清单，实际使用时，这些规则常出现两个问题：一是把 example.jpg 里的 jpg 误认作顶级域，二是会匹配到IP地址或文件扩展名，行业共识认为，顶级域列表每年都会更新，硬编码清单迟早过时,不如用字母数量控制。
正则提取域名和URL解析有什么区别？如何选择？
很多语言都提供了 urlparse、URL 或 URI 类的方法，可以直接取出hostname，那么正则还有意义吗？要看场景。
适合用正则的场景
- 文本不是完整URL，而是混在自然语言中，请访问 xxx.example.com 获取信息”
- 需要从一行日志中提取多个域名，但分隔符不固定
- 数据源来自非标准化格式，URL缺少协议或包含异常字符
适合用内置解析器的场景
- 输入是标准URL，且需要获取路径、参数、端口、用户信息等结构化字段
- 需要处理国际化域名（IDN）的punycode编码
- 已经确认字符串是合法URL，不包含噪音
举一个具体例子：从 用户访问了https://shop.example.com/goods?id=3
性能对比
正则引擎回朔较多时性能会下降，但处理普通文本（几千条记录）几乎无感知，如果是百万级日志流，建议先用简单的字符串截取或过滤，再对候选子串做正则验证，多数情况下，正则的灵活性和内置工具的可维护性并不冲突,混合使用效率更高。
从HTML源码中批量抓取域名，正则怎么写才不漏不误？
HTML是最常见的“域名词源”，从 <a href="https://www.example.com/post
先清洗HTML再匹配
直接对完整HTML跑正则，会误伤CSS、JS变量和注释内容,推荐的流程是：
- 用 BeautifulSoup、html-parse 等工具提取所有 a 标签的 href 属性和 img 的 src 属性。
- 对这些属性值单独跑正则。
- 如果需要纯正,再补一个去重步骤。
如果坚持用正则抓全站链接,可以用这个模式提取标签属性：
<a[^>]+href=["'](.?)["']
这个正则具有明显的贪婪陷阱。 非贪婪匹配可以避免跨到下一个标签，但如果HTML属性值本身包含 >，仍会出错，业内专家指出，面对不规范的HTML，正则解析比DOM解析更脆弱,建议优先使用解析库。
处理“裸域名”和“图片域名”
有些场景只需要站外域名，比如分析外链，这时要排除当前站点的域名、资源文件域名（如 cdn.）、以及 javascript: 和 mailto: 协议，先匹配出URL，再取域名,判断是否属于白名单。
批量抓取时，“漏掉”经常发生在协议相对URL（//example.com）和没有 www 的子域名上，可以先把HTML中的 补上 https: 再提取,或者正则直接允许可选的协议。
正则匹配中文域名和IP地址的边界处理技巧
如果目标域名包含中文（如 例子.中国），传统ASCII正则会失配，这类域名在浏览器里会被转换成punycode（
xn--fsq092h.xn--fiqs8s），但文本中可能直接显示中文原形,建议使用Unicode属性：
(?:[a-zA-Z0-9u4e00-u9fa5-]+.)+[a-zA-Zu4e00-u9fa5]{2,}
这个变体将中文汉字纳入标签字符，同时顶级域允许中文，要注意的是，中文域名中“点”可能是全角 ,需要先归一化。
IP地址要不要用正则匹配？
IP不是域名，但提取host时经常混在一起，如果只想要域名,排除纯IP即可：
(?!((25[0-5]|2[0-4]d|[01]?dd?).){3}(25[0-5]|2[0-4]d|[01]?dd?)$)(?:[a-zA-Z0-9-]+.)+[a-zA-Z]{2,}
这串规则前置了一个负向先行断言，用来排除IPv4地址，但说实话，99%的日志场景用不上这么复杂的断言，你可以先匹配出所有类似host的片段，再用语言自带的IP判断函数过滤,正则只做粗筛。
端口和边界的处理
当你从 http://example.com:8080/index
常见问题：正则获取域名为什么总有多余字符？
“多余字符”通常来自三个方面，分别对应三个解决办法,多数情况下都能通过调整规则解决。
贪婪匹配吃掉了后续内容
[a-zA-Z0-9.-]+ 遇到 www.example.com/path 时，会一路吃掉 /path，原因是 匹配了正斜杠吗？不，[] 里的 是字面点，不会匹配 ，但如果写成 .?.com 这种宽松模式，就会出问题，解决方法是严格列出允许的字符集，不让 或 出现在边界。
顶级域被截断或误判
子域名缺失或重复
正则 (?:[a-zA-Z0-9-]+.)+[a-zA-Z]{2,} 匹配 www.example.com 时，捕获组会包含 www.example.，直观但获取完整域名时需要 match.group(0) 而不是捕获的子组，如果只想要“注册域名”（不含子域名），比如从 blog.example.com 提取 example.com，这已经超出了正则的舒适区，建议用字符切割：先取最后两个标签，多数情况下,正则返回完整hostname就够了。
| 常见问题 | 典型表现 | 解决思路 |
|---|---|---|
| 贪婪匹配 | 域名后跟着路径或参数 | 使用字符类限制，不用 |
| 边界失控 | 域名后紧邻中文或特殊符号 | 增加 b 或手动清理尾部 |
| 顶级域偏长 | 匹配到 example.jpg | 限制字母数量或使用白名单顶层域 |
| 大小写混乱 | EXAMPLE.COM 匹配不完整 | 正则中启用 i 忽略大小写 |
Q&A：正则获取域名相关的三个高频问题
问：有没有一条正则表达式能匹配所有域名并适配所有编程语言？
没有，也不建议追求“万能”，不同语言的正则引擎差异、文本结构差异、域名规则更新，决定了你写出的规则一定需要根据上下文微调，比如Python的 re 不支持 b 对Unicode的完美处理，JavaScript的 /[^/]+/ 在URL中表现良好，但在自然语言里就会误伤，解决方法是把提取任务拆解为先“切割”再“验证”,正则只做第一道筛选。
问：正则获取域名时如何避免匹配到邮箱地址？
邮箱地址的特征是包含 ，user@example.com，如果目标只是域名，应该匹配 之后的部分，或者先剥离，一个简单规则是不要允许 出现在域名前，可以在正则开头添加负向断言 (?<![w.]) 保证域名前不是单词字符或点，另一种思路是先找出所有“看起来像域名”的片段，再排除包含 的行，多数文本编辑器支持这个思路，实际业务代码中推荐先按 拆分。
问：从日志中提取域名时，是否需要先格式化文本？
需要，而且这步很关键，原始日志经常包含转义字符、换行符、非ASCII空格，先统一将 / 替换为 、去掉 r 和 n，能免去正则里大量转义，统计显示，经过简单清洗后，同样一条正则在相同数据上的匹配速度能提升30%以上，清洗操作通常不需要正则,用字符串替换函数即可完成。
正则获取域名从来不是“背一条规则走天下”的事，而是理解边界、测试反馈、针对场景收放模式的过程，把基础规则记牢，在线的正则调试工具多跑几次，你会自然形成一套属于自己的“域名提取三板斧”，下次遇到混合文本时，先从协议和字符集切入口，再慢慢收窄边界,干净的域名就会自己跳到捕获组里。
