简介：「批量获取网站标题1.3」是一款面向网络爬虫初学者与数据采集从业者的实用工具，用于批量抓取互联网站点的标题信息，支持域名、IP与端口识别，并能处理网页多次跳转，适合需要快速收集站点信息的场景。资源包共13个文件，以6个dll动态链接库和2个exe可执行程序为主，另含jpg示例图、pdb调试符号、xml文档与config配置文件，压缩包约1.6MB，体积轻巧便于部署。其中NPOI系列库负责Excel读写与数据导出，进度条控件库为界面提供友好反馈，配置文件则保存运行时参数。目前已有293人学习下载。通过该工具，读者可理解HTTP重定向状态码处理、TCP/IP通信基础与批量数据整理思路，掌握从请求发送到结构化导出的完整流程，为网络数据挖掘与分析打下实践基础。
1. 批量获取网站标题1.3：从域名到 Excel 的批量抓取工具拆解
手里有一批域名、IP 或者带端口的地址，想快速知道每个站点的标题是什么，一个个点开浏览器看显然不现实。GetWebTitle1.3就是冲着这个场景来的：输入一批目标地址，工具自动发起 HTTP 请求、跟随跳转、解析 HTML 里的<title>，最后把结果整理成 Excel。它适合做资产梳理、站点普查、竞品监控名单初筛的从业者，也适合想拿一个现成 .NET 小工具练手网络请求与数据处理的人。压缩包里除了主程序GetWebTitle.exe，还带了ExcelLib.dll、NPOI.dll系列、SmoothProgressBar.dll和配置文件，说明它把「抓取—解析—导出—进度反馈」这条链路都做进去了。下面按实际拆包和复现的顺序，把关键环节讲透。
2. 抓取链路拆解：TCP/IP、HTTP 跳转与标题解析
2.1 为什么标题抓取绕不开 TCP/IP 与 HTTP 状态码
批量获取网站标题，表面上是「发请求、取标题」，底层其实是 TCP/IP 在托底。每一次对目标站点的访问，都要先经过 TCP 三次握手建立连接，再发送 HTTP 请求，服务器返回响应后再四次挥手断开。工具要批量处理成百上千个地址，如果每个请求都完整走一遍握手挥手，耗时会非常可观。常见做法是开启 HTTP keep-alive，让同一个站点的多个请求复用连接，减少握手开销。
真正让新手翻车的是跳转。很多域名并不会直接返回 200，而是先回 301 或 302，把请求导向另一个 URL，甚至连续跳好几次。如果工具只取第一次响应的内容，很可能拿到一个空页面或者跳转提示页，标题自然抓不到。GetWebTitle1.3在逻辑上必须能识别 3xx 状态码，从响应头Location字段取出新地址，再发起下一次请求，直到拿到 200 或者达到最大跳转次数。这个「跟随跳转」的深度需要设上限，否则遇到循环跳转就会把线程卡死。
提示：判断标题是否抓取成功，不能只看有没有返回内容，还要看最终响应的状态码是不是 200，以及 HTML 里是否真的存在
<title>标签。
2.2 用 .NET 发起请求并提取标题的最小实现
下面这段 C# 代码演示了单个地址的抓取流程，包含跳转跟随和标题提取，和工具内部的核心逻辑是一个思路。你可以把它当成理解GetWebTitle.exe行为的参照。
using System; using System.Net; using System.Text.RegularExpressions; public class TitleFetcher { // 最大跳转次数，防止循环跳转把线程拖死 private const int MaxRedirects = 5; public static string FetchTitle(string url) { string currentUrl = url; for (int i = 0; i < MaxRedirects; i++) { HttpWebRequest request = (HttpWebRequest)WebRequest.Create(currentUrl); request.Method = "GET"; request.Timeout = 8000; // 单次请求超时，单位毫秒 request.AllowAutoRedirect = false; // 手动处理跳转，便于记录最终地址 request.UserAgent = "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"; try { using (HttpWebResponse response = (HttpWebResponse)request.GetResponse()) { int code = (int)response.StatusCode; // 3xx 跳转：取出 Location 继续请求 if (code >= 300 && code < 400 && response.Headers["Location"] != null) { string location = response.Headers["Location"]; currentUrl = new Uri(new Uri(currentUrl), location).ToString(); continue; } // 200 正常响应：读取 HTML 并匹配 title using (var reader = new System.IO.StreamReader(response.GetResponseStream())) { string html = reader.ReadToEnd(); Match match = Regex.Match(html, @"<title[^>]*>(.*?)</title>", RegexOptions.IgnoreCase | RegexOptions.Singleline); return match.Success ? match.Groups[1].Value.Trim() : "(无标题)"; } } } catch (WebException ex) { // 超时、DNS 解析失败、连接被拒都会走到这里 return "(请求失败: " + ex.Status + ")"; } } return "(跳转次数超限)"; } }逻辑说明：AllowAutoRedirect设为false是为了自己控制跳转，这样能记录最终落地的 URL，也方便在跳转次数超限时及时止损。Timeout设 8000 毫秒是一个折中值，太短会误杀慢站点，太长会让整批任务卡住。正则匹配<title>时加了Singleline，因为有些页面的标题标签里带换行。参数方面，UserAgent建议伪装成常见浏览器，部分站点会对默认的 .NET 请求头直接返回 403。
2.3 批量并发与进度反馈：SmoothProgressBar 的作用
单个地址抓完只是起点，批量场景下真正影响体验的是并发控制和进度显示。压缩包里的SmoothProgressBar.dll就是干这个的——它给界面提供一个平滑推进的进度条，让用户知道当前处理到第几个、还剩多少。并发数不能无脑开大，常见做法是控制在 10 到 30 个线程之间，具体看目标站点的承受能力和本机网络出口。线程太多容易触发对方限流，返回一堆 429 或直接断连；线程太少则批量任务跑得比手动点还慢。
一个稳妥的策略是：把待处理地址放进队列，用固定数量的工作线程去消费，每完成一个就更新进度条并写一行结果。这样即使某个地址超时，也不会阻塞其他任务。工具配置文件GetWebTitle.exe.config里通常可以调整超时时间、并发数这类参数，动手前先看一眼，比在代码里硬改要省事。
3. 结果落地：用 NPOI 把标题写进 Excel
3.1 为什么选 NPOI 而不是直接拼 CSV
抓取结果最终要给人看、给下游系统用，Excel 是最通用的载体。压缩包里出现了NPOI.dll、NPOI.OOXML.dll、NPOI.OpenXmlFormats.dll这一整套，说明工具用的是 NPOI 来读写 Office 格式文件。相比直接输出 CSV，NPOI 的优势在于能控制列宽、表头样式、单元格格式，而且不会因为标题里带逗号、换行就把表格撑乱。CSV 看起来简单，但遇到标题里本身有分隔符时，解析方要额外处理转义，批量数据里这种坑很常见。
NPOI 分XSSF（.xlsx）和HSSF（.xls）两套 API，NPOI.OOXML.dll对应的是 xlsx 格式。现在新环境基本都用 xlsx，行数上限也更高，批量结果动辄几万行，用 xls 会直接撞到 65536 行的天花板。
3.2 导出 Excel 的代码骨架与参数说明
下面这段代码展示如何把抓取结果写成 xlsx，包含表头、列宽和自动换行的设置。
using NPOI.XSSF.UserModel; using NPOI.SS.UserModel; using System.IO; public class ExcelExporter { public static void Export(string filePath, System.Collections.Generic.List<string[]> rows) { IWorkbook workbook = new XSSFWorkbook(); // 创建 xlsx 工作簿 ISheet sheet = workbook.CreateSheet("抓取结果"); // 表头样式：加粗、居中 ICellStyle headerStyle = workbook.CreateCellStyle(); IFont headerFont = workbook.CreateFont(); headerFont.IsBold = true; headerStyle.SetFont(headerFont); headerStyle.Alignment = HorizontalAlignment.Center; IRow header = sheet.CreateRow(0); string[] columns = { "原始地址", "最终地址", "状态码", "网站标题" }; for (int i = 0; i < columns.Length; i++) { ICell cell = header.CreateCell(i); cell.SetCellValue(columns[i]); cell.CellStyle = headerStyle; } // 数据行 for (int r = 0; r < rows.Count; r++) { IRow row = sheet.CreateRow(r + 1); for (int c = 0; c < rows[r].Length; c++) { row.CreateCell(c).SetCellValue(rows[r][c] ?? ""); } } // 列宽：标题列给宽一点，避免内容被截断 sheet.SetColumnWidth(0, 40 * 256); sheet.SetColumnWidth(1, 40 * 256); sheet.SetColumnWidth(2, 10 * 256); sheet.SetColumnWidth(3, 80 * 256); using (FileStream fs = new FileStream(filePath, FileMode.Create, FileAccess.Write)) { workbook.Write(fs); } } }逻辑说明：SetColumnWidth的单位是 1/256 个字符宽，所以40 * 256表示约 40 个字符宽。标题列给到 80 是为了容纳较长的站点标题。SetCellValue传入前做了空值兜底，避免 null 导致写入异常。参数上，如果结果行数超过几万，建议分批写入或者改用 SXSSFWorkbook，它在内存占用上更友好，代价是只能顺序写、不能回头改已写出的行。
3.3 从抓取到导出的完整操作步骤
把前面两块拼起来，一次完整的批量任务大致是这样跑的：
- 准备输入文件，每行一个地址，支持
域名、IP、IP:端口三种形式。 - 启动
GetWebTitle.exe，在界面里选择输入文件和输出 Excel 路径。 - 根据目标站点情况，在
GetWebTitle.exe.config里调整超时和并发数，保存后重启程序。 - 点击开始，观察
SmoothProgressBar的推进情况，中途可以看已完成的计数。 - 任务结束后打开 Excel，重点检查「状态码」列，把非 200 的行挑出来单独复查。
注意：输入地址里如果混了内网 IP 或者已经下线的域名，会大量出现超时，建议先做一轮存活探测再批量抓标题，能省不少时间。
4. 避坑与排查：批量抓标题最常见的五类翻车
4.1 标题抓出来是空的或者一串乱码
现象：Excel 里标题列大量为空，或者显示成锟斤拷这类乱码。原因通常是目标页面没有用 UTF-8 编码，而是 GBK 或 GB2312，而请求端默认按 UTF-8 解码。解决方式是在读取响应流时先看response.CharacterSet，拿不到就按 GBK 兜底解码，或者用Encoding.GetEncoding("GBK")显式指定。乱码问题在中文站点里非常普遍，属于血泪经验级别的高频坑。
4.2 明明浏览器能打开，工具却报连接失败
现象：手动在浏览器访问正常，工具里却返回超时或连接被拒。原因可能是目标站点只响应特定User-Agent，或者对高频请求做了限流，也可能是本机 DNS 解析和浏览器走了不同的缓存。解决方式是先把并发数降到 5 以下试跑，确认不是限流；再检查UserAgent是否被识别为爬虫；如果地址是 IP 形式，确认端口有没有写对，80 和 443 对应 http 和 https，写错协议也会连不上。
4.3 跳转跟丢了，拿到的是中间页标题
现象：抓到的标题是「正在跳转」或者某个验证页的标题，不是最终目标页。原因是跳转链里出现了 JavaScript 跳转或者 meta refresh，这类跳转不是 HTTP 3xx，工具按状态码判断就会漏掉。解决方式是解析 HTML 里的<meta http-equiv="refresh">，从中提取目标地址再请求一次。纯 JS 跳转更难处理，一般建议对这类站点单独标记，不要指望通用工具能覆盖所有情况。
4.4 Excel 导出时报文件被占用
现象：任务跑完，导出时提示文件无法写入。原因通常是上一次生成的 Excel 还开在 WPS 或 Office 里，文件句柄没释放。解决方式是导出前检查目标路径是否被占用，或者每次导出用带时间戳的文件名，避免覆盖正在打开的文件。这个坑不涉及技术难点，但批量任务里一旦中断重跑，很容易撞上。
4.5 并发开太大导致整批结果质量下降
现象：并发调到 50 以上后，失败率明显上升，很多行显示超时。原因是本机出口带宽、目标站点限流、DNS 查询压力同时到达瓶颈。解决方式是把并发控制在 10 到 30 之间，并给每个请求设置合理的超时和重试次数。重试不要无脑加，失败两次还不行就标记为失败，继续处理后面的地址，避免个别站点拖垮整批任务。
5. 进阶技巧：用配置文件和分批策略把成功率拉满
工具自带的GetWebTitle.exe.config是很多人会忽略的地方，但它恰恰是调优的入口。常见做法是在里面把超时、并发、重试次数做成可配置项，跑不同批次任务时不用改代码，改配置重启即可。比如面对响应普遍较慢的站点，把超时从 8 秒提到 15 秒；面对响应快但容易限流的站点，把并发从 20 降到 8。这个习惯能让你在不重新编译的前提下快速适配不同目标。
另一个实用技巧是分批跑。把几万个地址一次性丢进去，中途一旦出错很难定位是哪一批的问题。我一般会按每 500 到 1000 个地址切一个批次，每批单独输出一个 Excel，跑完一批检查一批。这样即使某批失败率异常，也能快速圈定问题地址段，而不是对着一个几万行的表干瞪眼。分批还有个好处：进度条推进更平滑，心理上也好受些。
验证抓取质量时，不要只看成功计数。抽 20 到 30 行，手动在浏览器里打开对应地址，比对标题是否一致，重点看那些状态码是 200 但标题为空的记录。这类记录往往藏着编码问题或者页面结构特殊的情况，是提升整体成功率的关键线索。下面这张表可以作为每批任务后的自检清单：
| 检查项 | 合格标准 | 异常处理 |
|---|---|---|
| 状态码分布 | 200 占比 80% 以上 | 低于则降并发、查网络 |
| 标题空值率 | 低于 5% | 偏高则查编码和跳转 |
| 跳转超限数 | 接近 0 | 偏高则调大跳转上限 |
| 导出文件完整性 | 行数与输入一致 | 缺行则查写入异常 |
从那以后我每次跑批量抓取，都会先拿 50 个地址做小批量试跑，确认编码、跳转、并发都正常了，再放开全量。这个习惯帮我省下了不少返工时间。希望帮到你。
本文还有配套的精品资源，点击获取
