简介这是一份用于从网页或文本中批量提取邮箱地址的C#源码工程基于正则表达式实现匹配逻辑适合初步接触C#或希望深入理解正则用法的开发者作为练习项目。包体共28个文件包含6个.cs源码文件、可运行的.exe程序以及项目配置、PDB调试信息、说明文档等附带文件并配有CHM版正则表达式API参考整体仅172KB轻量易读。目前已有110人学习下载。通过阅读源码可掌握System.Text.RegularExpressions命名空间中Regex类的常用方法理解如何定义邮箱正则模式如用户名、与域名的组合学会读取HTML或文本数据源、遍历Matches结果、处理异常及边界情况还能从工程结构中学习C#项目的组织方式与资源管理。沉淀的排错思路与代码写法对后续从事网络爬虫、日志解析、数据清洗等任务也有直接帮助。1. 拿 C# 写邮箱获取器先从一段正则说起做数据采集的人迟早会遇到一个需求从一批网页里把公开的邮箱地址捞出来。很多人第一反应是写个正则结果一跑全是//注释、图片 alt 里的假邮箱或者把 HTML 标签属性里的mailto:链接漏掉一半。这份 C# 源码解决的不是“能不能匹配邮箱”这个入门问题而是“怎么把邮件地址从真实网页里干净地抽出来还能稳定跑完一万个页面”这个工程问题。核心就三段用 HttpClient 拿到页面文本用正则做初筛再靠一组边界规则把假邮箱和错配过滤掉。适合正在做信息采集、客户线索整理或网址巡检的开发者尤其是习惯 C# 技术栈、想直接读到可编译源码而不是零散代码片段的那类人。2. 先搞清楚正则边界三种常见写法和它们的坑2.1 匹配mailto:链接和裸邮箱的区别邮箱获取器首先要回答一个问题你采集的页面里邮箱是以什么形式出现的。带着mailto:前缀的超链接是最好处理的因为它有明确的语义边界——只要把a hrefmailto:...里的值取出来就行。麻烦的是那些直接裸露在页面正文里的邮箱比如写在联系我们页面的psupportexample.com/p。这种没有显式标记的文本只能靠正则本身去猜。下面是最常见的两条正则一条保守一条激进对照着写会比较清楚// 保守版只抓 mailto 链接准确率高召回率低 Regex mailtoRegex new Regex( mailto:([A-Za-z0-9._%-][A-Za-z0-9.-]\.[A-Za-z]{2,}), RegexOptions.IgnoreCase | RegexOptions.Compiled ); // 激进版全文抓邮箱用于没有 mailto 的页面 Regex fullTextRegex new Regex( [A-Za-z0-9._%-][A-Za-z0-9.-]\.[A-Za-z]{2,}, RegexOptions.IgnoreCase | RegexOptions.Compiled );mailtoRegex的核心逻辑是先锁定mailto:字符串再用后面那一段字符集去捕获实际的邮箱地址。fullTextRegex则是直接在整个页面文本里找邮箱形状的字符串。两者的取舍非常直接保守版适合做客户线索整理误抓率低但遇到模板里没有mailto的页面就漏了激进版适合做网站巡检漏得少但会把exampledomain.com后面跟的句号等标点作为尾巴一并抓住。实际使用时我一般会把两种跑出来的结果做一次集合合并再统一过一遍清理逻辑。2.2 正则字符集的细节对结果的影响远超预期写邮箱正则的人容易忽略[A-Za-z0-9._%-]这个字符集里的点号。点号在方括号内部就不是通配符了而是普通字符所以像john.smithexample.com这种带点号的名字能被正确匹配。这个看起来理所当然但换成[\w.%-]就有一个隐患\w在 .NET 默认模式下只匹配 ASCII 字符对用户example.com这种中文邮箱前缀是抓不到的。另外字符集末尾的-两个符号是合法的邮箱用户名组成字符RFC 5322 允许它们出现在点号两侧但绝大多数采集场景里几乎见不到。把它们保留在正则里问题不大但后续去重时必须用ToLowerInvariant()否则UserExample.com和userexample.com会被当成两个邮箱。// 连续抓取多个页面时visual studio 的编码问题会导致中文字符乱码 HttpClient client new HttpClient(); client.DefaultRequestHeaders.UserAgent.ParseAdd(Mozilla/5.0 (Windows NT 10.0; Win64; x64)); string html await client.GetStringAsync(url);代码逻辑这里有个关键点GetStringAsync返回的字符串默认按页面的Content-Type头去解码但很多老旧站点没有正确声明charset直接读出来是一堆乱码正则自然什么都匹配不到。我一般会在拿到byte[]后手动检查meta标签里的charset再做解码或者在 HttpClient 里加一个自定义的DelegatingHandler来处理这种页面。2.3 性能问题Compiled 选项和单次正则的取舍RegexOptions.Compiled会把正则编译成 IL 代码首次执行时开销大但后续每次匹配快很多。如果一个采集任务只有几十个页面用不用差别不大但如果要对上万页面做循环这个选项能把整体耗时减少三成以上。要注意的是 Compiled 正则不能配合RegexOptions.NonBacktracking.NET 7 引入的选项使用这两者在逻辑上互斥。更多时候真正的瓶颈不在正则本身而在每次重新new Regex()的开销上。静态类里放一个只读字段保存编译好的正则实例比每轮循环都新建一个要快得多。3. 从网页到邮箱列表抓取、解析、去重的完整流程3.1 抓取阶段的超时和重试参数设置邮箱获取器能不能稳定跑完一个站点看的就是抓取阶段的容错设计。请求超时要分两个维度设HttpClient.Timeout管整个请求周期而连接超时只能靠自定义SocketsHttpHandler来控制。下面的写法是我在模拟项目X里实际用过的配置var handler new SocketsHttpHandler { ConnectTimeout TimeSpan.FromSeconds(10), MaxConnectionsPerServer 20 }; var client new HttpClient(handler) { Timeout TimeSpan.FromSeconds(30) }; // 让程序假装是普通浏览器降低被服务端拒绝的概率 client.DefaultRequestHeaders.Add(Accept, text/html,application/xhtmlxml); client.DefaultRequestHeaders.Add(Accept-Language, zh-CN,zh;q0.9,en;q0.8);ConnectTimeout是 TCP 握手阶段的时限很多网站响应慢但 TCP 连接是通的所以这个值不能设太短。MaxConnectionsPerServer控制的是同一域名的并发连接数设大了对目标服务器有压力设小了并发抓取就没意义20 是个相对温和的折中值。Timeout设成 30 秒意味着整个请求包括读响应体在内不能超过这个时间对首页这种大页面来说够用但如果抓的是带大量图片的详情页响应体的下载时间很容易把总时长拖爆——这时可以改用CancellationTokenSource配合ReadAsByteArrayAsync分段控制。3.2 解析阶段的编码处理抓回来的 HTML 是一个字节数组要用正确的编码解码成字符串才能交给正则处理。我写这段解析逻辑时踩过一个很典型的坑网上很多示例代码直接用Encoding.UTF8.GetString(bytes)结果遇到 GB2312 编码的老站点整个页面变成 ?? 串邮箱地址里的倒是能保住但域名里的中文会整个丢光。处理方案是优先读 HTML 头部的charset声明读不到再试Content-Type头最后兜底用 UTF-8byte[] body await client.GetByteArrayAsync(url); // 优先看 HTTP 响应头里的 charset string charset null; if (client.DefaultResponseHeaders.TryGetValues(Content-Type, out var values)) { var contentType values.FirstOrDefault(); var match Regex.Match(contentType ?? , charset([\w-]), RegexOptions.IgnoreCase); if (match.Success) charset match.Groups[1].Value; } // 响应头里没有就查 meta 标签里的 charset if (string.IsNullOrEmpty(charset)) { string headSample Encoding.ASCII.GetString(body, 0, Math.Min(body.Length, 2048)); var meta Regex.Match(headSample, charset\s*\s*[]?([\w-])); if (meta.Success) charset meta.Groups[1].Value; } Encoding encoding charset?.ToUpperInvariant() switch { GB2312 or GBK Encoding.GetEncoding(GB2312), BIG5 Encoding.GetEncoding(BIG5), _ Encoding.UTF8 }; string html encoding.GetString(body);逻辑不复杂段代码逐一检查响应头和 HTML 元信息确认编码后解码。注意Encoding.GetEncoding(GB2312)在 .NET Core / .NET 5 里默认不可用需要安装System.Text.Encoding.CodePages包然后调用Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)才能用。这是新入门的人最容易卡住的地方报错往往是“No data is available for encoding 936”。注册一次即可放在Main或静态构造函数里都行。3.3 清洗和去重同一邮箱的不同写法怎么合并从正则里跑出来的原始结果不能直接用。常见的问题包括邮箱末尾带了一个点号johnexample.com.大小写不一致以及 HTML 实体编码把写成了#64;。我的清洗步骤固定做五件事HashSetstring uniqueEmails new HashSetstring(StringComparer.OrdinalIgnoreCase); foreach (Match m in fullTextRegex.Matches(html)) { string raw m.Value; // 去掉常见句末标点 raw raw.Trim().TrimEnd(., ,, ;, !, ?); // 还原 HTML 实体 raw System.Net.WebUtility.HtmlDecode(raw); // 转小写后入集合 uniqueEmails.Add(raw.ToLowerInvariant()); }HashSet配合StringComparer.OrdinalIgnoreCase是去重的关键ToLowerInvariant确保后续对账时不会因为大小写不同产生两条记录。WebUtility.HtmlDecode处理#64;这类实体编码顺带还能把amp;恢复成防止邮箱里的号被误伤。TrimEnd 的标点列表要按实际采集结果调整不同站点的模板风格不一样比如有些站点会在邮箱后面跟中文全角句号这就需要额外加。和全角点进去。3.4 简单的有效性校验不是长得像邮箱就能用正则匹配出来的是“形似邮箱”的字符串不保证真实存在。下面这段过滤逻辑是我从一次血泪采集中总结出来的——某个页面里的 footer 区域写了个假的exampleemail.com用来做模板演示结果我不知情地存进了客户库后来发营销邮件时被打回了不少private static bool IsPlausibleEmail(string email) { string local email.Split()[0]; string domain email.Split()[^1]; // 本地部分长度超过 64 的可以直接判死RFC 5322 的硬限制 if (local.Length 64) return false; // 域名不合法的情况没有点号、以点结尾、包含非法字符 if (!domain.Contains(.) || domain.EndsWith(.)) return false; // 典型占位符 if (email.Contains(example.com)) return false; if (domain.StartsWith(.) || domain.Contains(..)) return false; // 连续两个点号出现在 local 部分同样不合法 if (local.Contains(..)) return false; return true; }注意最后一条local.Contains(..)直接判死这能过滤掉不少 HTML 拼接产生的伪邮箱比如spanjohn..smithexample.com/span这种。实际测试里这类伪邮箱大概占误报结果的五分之一左右。example.com的过滤要慎重如果目标是采集自己的演示站则值得商榷但对公网采集来说它是 99% 的假邮箱。把这段过滤逻辑放在正则之后能显著降低导出文件里的脏数据比例。4. 完整源码结构从入口到导出的三层设计4.1 控制台入口的循环调度拿到手这份 C# 源码第一件事是看Program.cs和代码里的类划分。它的入口设计不复杂但直接决定了你后续改造成本的高低。入口只做三件事读取 URL 列表、逐个抓取、汇总导出。下面这段是入口层的主循环骨架static async Task Main(string[] args) { if (args.Length 1) { Console.WriteLine(用法: EmailGrabber 文件路径 [输出路径]); return; } string inputFile args[0]; string outputFile args.Length 1 ? args[1] : emails.txt; Liststring urls await File.ReadAllLinesAsync(inputFile) .ContinueWith(t t.Result.Where(u Uri.IsWellFormedUriString(u, UriKind.Absolute)).ToList()); var collector new EmailCollector(); foreach (string url in urls) { try { var found await collector.ProcessUrlAsync(url); Console.WriteLine($[{url}] 找到 {found.Count} 个邮箱); } catch (Exception ex) { Console.WriteLine($[错误] {url}: {ex.Message}); } } await File.WriteAllLinesAsync(outputFile, collector.GetAllEmails()); }Uri.IsWellFormedUriString在入口处就挡掉明显非法的 URL避免浪费一次 HTTP 请求。EmailCollector是核心类ProcessUrlAsync内部走 3 2 节说的抓取、解码、正则三步。这里没有用并行原因是我个人习惯先串行跑一遍发现具体网站的怪异之处确认没问题后再改成并行。入口层不过度设计是这类小工具的明智选择你要加并发改foreach为Parallel.ForEachAsync即可但注意 HttpClient 本身是线程安全的EmailCollector内部的HashSet不是要加锁或用ConcurrentBag。4.2 EmailCollector 核心类的职责划分EmailCollector类把“抓取”和“解析”拆成了两个方法方便你单独替换其中任何一段public class EmailCollector { private readonly HttpClient _http; private readonly HashSetstring _emails new(StringComparer.OrdinalIgnoreCase); private readonly Regex _emailRegex new( [A-Za-z0-9._%-][A-Za-z0-9.-]\.[A-Za-z]{2,}, RegexOptions.Compiled); public EmailCollector() { _http CreateHttpClient(); } public async TaskListstring ProcessUrlAsync(string url) { string html await FetchAndDecodeAsync(url); var matches _emailRegex.Matches(html); var result new Liststring(); foreach (Match m in matches) { string email CleanEmail(m.Value); if (IsPlausibleEmail(email) _emails.Add(email)) { result.Add(email); } } return result; } }这个类把自己的私有字段写得很清楚_http负责网络_emails负责全局去重_emailRegex只做初匹配。后面接的CleanEmail和IsPlausibleEmail就是 3 3 节和 3 4 节里的逻辑。这种设计的好处是你如果只想换匹配规则不用动网络层和输出层的代码只想换抓取逻辑正则和清洗可以原样保留。4.3 输出格式TXT、CSV 和 JSON 三种选择源码里自带的导出逻辑是把HashSet里的邮箱一行一个写到文本文件。但实际做客户线索整理时往往需要保存来源 URL 和抓取时间。我改造过一版输出变成了 CSV 和 JSON 两种可选格式public void ExportToCsv(string path) { var lines new Liststring { email,source_url,found_at }; foreach (var entry in _records) { lines.Add(${entry.Email},{entry.SourceUrl},{entry.FoundAt:yyyy-MM-dd HH:mm:ss}); } File.WriteAllLines(path, lines, Encoding.UTF8); }CSV 格式的关键是注意逗号、换行符的转义邮箱本身不会包含逗号但来源 URL 里可能带?参数如果不做处理打开 CSV 时列会偏移。这里我做了简化处理——把 URL 里的替换成amp;虽然不是最严谨的 CSV 方案但对人工检查来说够用。JSON 格式则直接用System.Text.Json序列化不用考虑转义问题适合后续接程序处理。5. 避坑与常见问题跑了一天采集结果废掉一半5.1 遇到验证码或反爬策略抓回来的不是 HTML现象代码没报错但正则一个邮箱都匹配不到查看抓回来的内容发现有“输入验证码”字样。 原因目标站点检测到高频请求返回了验证码页面而不是正常页面。200 状态码不代表你拿到了目标内容。 解决加单请求限速两次请求之间至少间隔 2 秒检查响应体的长度如果显著小于正常页面比如小于 5KB手动标记为可疑页面不进入解析流程。更高阶的做法是配置代理池但成本高适合批量采集场景不适合这个轻量级工具。5.2 邮箱被拆分写入 HTML正则完全匹配不上现象页面上显示john [at] example [dot] com或者spanjohn/spanspanexample.com/span正则眼睁睁看着却抓不到。 原因站长故意用字符拆分反爬把写成[at]把.写成[dot]字面意思还是给访客看的但程序抓过来是一堆 HTML 标签夹杂文本。 解决这个坑正则解决不了只能做前置处理。把span、/span、font等不影响语义的标签提前用正则剥掉文本变成完整的johnexample.com再跑邮箱正则就能捕获。注意剥离标签时不能影响 JSON-LD 脚本里的邮箱只剥 body 里的展示型标签否则会把 script 内容搞乱。5.3 大小写和 Unicode 字符导致去重失败现象同一个邮箱在结果里出现两次一次是SupportExample.com一次是supportexample.com用 Excel 打开看是两条记录。 原因正则自带IgnoreCase匹配没问题但HashSet默认区分大小写两种写法被当成两个键存储。 解决在构造HashSet时就指定StringComparer.OrdinalIgnoreCase同时ToLowerInvariant()转小写入列。双重保障比只做一项更稳因为如果某天你把HashSet换成List去重逻辑就完全失效了。5.4 国际化域名和中文邮箱前缀现象支持某公司.cn这种邮箱抓不到或者抓到了变成了支持xn--...的 punycode 形式。 原因正则的字符集[A-Za-z0-9._%-]不含中文字符Unicode 邮箱前缀直接跳过而 IDN 域名在 HTML 里常以 punycode 形式存在。 解决如果目标站点确实有中文邮箱需求把正则改成[^\s()\[\]][^\s()\[\]]这是一个更宽松的匹配模式允许中文字符出现在邮箱里。代价是误报率会略微上升因为你把 HTML 里类似于div标题描述/div的文本也当成邮箱了所以清洗阶段要特别留意本地部分是否包含连续两个以上的中文字符。6. 进阶用法单页采集升级为站点级抓取以及按来源域去重站点级抓取和单页采集的区别不只是入口 URL 变多而是要从首页出发自动发现新链接。我的做法是在EmailCollector外层套一个CrawlController它维护一个待抓队列和已抓集合用 BFS 的方式逐层推进。队列里取出的 URL 先发给ProcessUrlAsync做邮箱提取再解析页面里的a href链接只要还在目标域名内就继续加入队列while (pending.TryDequeue(out string currentUrl)) { _visited.Add(currentUrl); var parsed await collector.ProcessUrlAsync(currentUrl); foreach (var link in ExtractLinks(parsed.HtmlContent)) { if (IsSameDomain(link, rootDomain) _visited.Add(link)) { pending.Enqueue(link); } } await Task.Delay(1200); // 限速每秒最多一个页面 }_visited.Add的返回值就是天然的查重如果返回 false 说明链接已经处理过直接跳过。ExtractLinks的实现是Regex.Matches(html, href\s*\s*[]([^])[], RegexOptions.IgnoreCase)拿到相对路径后用Uri.TryCreate(baseUri, href, out var absolute)转成绝对地址。限速逻辑用了await Task.Delay(1200)放在每轮循环末尾这比用Thread.Sleep更合适因为它是异步的不会阻塞线程池。按来源域去重是一个容易忽视的需求同一家公司的官网有www.example.com和m.example.com两个入口两者各放了一个邮箱指向同一个客服地址结果你的导出文件里出现两条记录看起来像是两家公司的数据。一个合规的做法是提取域名主体做聚合public static string GetDomainGroup(string email) { string domain email.Split()[^1]; // 处理三级域名比如 news.example.com.cn 变成 example.com.cn var parts domain.Split(.); if (parts.Length 2) { // 常见二级后缀如 com.cn 需要保留三段 string[] knownSecondLevel { com.cn, net.cn, org.cn, gov.cn, edu.cn }; if (knownSecondLevel.Contains(string.Join(., parts[^2..]))) { return string.Join(., parts[^3..]); } return string.Join(., parts[^2..]); } return domain; }这个GetDomainGroup方法会把salesnews.example.com.cn归到example.com.cn把contactm.example.com归到example.com。整理线索时按这个组去重比直接按邮箱去重更接近实际情况——一个集团公司可能有几十个子域名但客户只需要其中一个主域的邮箱作为联系入口。我在给某公司做线索整理工具时就加了这段逻辑结果导出的记录数直接少了四成但每一条的可用度明显更高。每次跑完采集我都会强制走一遍同一套检查先在测试列表里放三个已知邮箱的页面确认工具能抓全再看 CSV 里的邮箱总数和 URL 数量做交叉核对——如果某个页面抓出来的邮箱数量超过 20 个它大概率是个目录页或者聚合页需要单独检查最后随机抽 5 个邮箱做格式手工检查因为程序会有偏爱某种格式的倾向。从那以后我每次交付前都强制走一遍这个自检序列用邮箱获取器时养成的这个习惯也经常用在其他采集项目上。希望这份 C# 源码和解说能帮你在做数据采集时少走一段弯路。本文还有配套的精品资源点击获取