IPv4 去重实战:前导零归一与访问日志独立 IP 统计

整理 IP 列表最容易栽的坑,不是重复的两条完全一样,而是看起来不一样、其实是同一台主机。192.168.001.001 和 192.168.1.1,人眼扫过去会当成两条,纯文本比较也判成两条,可它们指向同一个地址。手工对着排,几百行就开始漏。

前导零是隐形的重复

点分四段里,每一段都是一个十进制数字。001 等于 1,010 等于 10,前导零只是写法不同,数值没变。问题在于,日志、导出表、不同设备的配置文件,会用各种写法混着写同一个地址。直接做字符串去重,这些"伪装"过的重复全都漏网。

正确做法是先归一化,再比较。把每段去掉前导零、还原成标准十进制,然后用归一后的形式作为去重的键。这样无论原文写成 010.000.001.001 还是 10.0.1.1,落到同一个键上,只保留一条。

IPv4 地址去重工具 就是按这个顺序做的:解析每个点分四段地址,归一化,再用归一结果判重,保留首次出现的那条,同时记下行号和重复次数。

一个真实例子

假设你从两份导出里粘进这么一段:

192.168.001.001
10.0.0.5
192.168.1.1
10.000.000.005
192.168.1.1

按字符串去重,你会得到四条(192.168.001.001 和 192.168.1.1 被当成不同的)。按归一去重,结果是两条:

192.168.1.1   (重复 3 次,首次出现第 1 行)
10.0.0.5      (重复 2 次,首次出现第 2 行)

192.168.001.001、192.168.1.1 和后面那条 192.168.1.1,三种写法折叠成一条;10.0.0.5 和 10.000.000.005 折叠成一条。重复次数和首次行号都留着,回原文排查时有据可查。

统计访问日志里的独立 IP

冷启动期我自己跑过一次:从 nginx 访问日志里把客户端 IP 列拉出来,想知道一天有多少独立访客来源。原始日志几万行,同一个 IP 反复出现是常态。我把那一列粘进去,去重一跑,几万行压成两千多条独立地址,每条还带着出现次数,顺手就能看出哪个 IP 请求量异常高。整个过程没把日志传到任何服务器,日志里夹着的 URL 参数、user-agent 这些东西也不会外泄。

这里有个细节值得留意:日志列里常混着噪声,越界的 999.1.1.1、被截断的 10.0.0、带端口的 1.2.3.4:80。把无效项保留下来复核,比悄悄丢掉更安全,你能看清哪些条目没被当成重复匹配,而不是以为它们神秘消失了。

整理防火墙白名单

白名单是另一类高频场景。运维交接时,白名单往往是好几份配置拼起来的,同一个地址在不同文件里写法不统一,直接合并会留下一堆隐形重复。先归一去重,再导出成 CSV 或 SQL IN,直接喂给脚本或工单系统,省掉手工加引号和补逗号。

如果只是想确认列表里哪些地址格式不合法,可以配合 IPv4 地址校验工具 单独跑一遍校验;要把清洗后的结果套进代码,IPv4 列表转换工具 能直接转成 JSON、SQL IN 或 TypeScript union。

为什么坚持本地处理

IP 地址常常和内部网络结构、客户来源绑在一起,属于不该随手外发的数据。这个工具的解析、归一、去重、复制、下载全在浏览器这一个标签页里完成,上传的日志文件由 File API 本地读取,不发往服务器。你交接出去的是一份可复核、带行号的干净列表,而不是一段经过别人服务器中转的数据。

整理 IP 这件事,真正费时间的从来不是删掉肉眼可见的重复,而是揪出那些写法不同、本质相同的地址。把归一这一步交给工具,你只需要核对结果。

---

Made by Toolora · Updated 2026-06-13