IPv6 地址去重:为什么多种写法是同一个地址

整理一份 IPv6 列表时，最容易踩的坑不是漏抄，而是同一个地址被当成了好几个。2001:db8::1 和 2001:0DB8:0000:0000:0000:0000:0000:0001 看上去差很远，其实指向同一台主机。如果直接按字符串去重，这两行会被当成两个独立 IP，统计和白名单都会出错。

同一个地址，为什么写法不止一种

IPv6 的文本表示允许几种合法的简写，规则叠加在一起就产生了大量等价写法:

• 前导零可以省略:2001:0db8 等于 2001:db8，每一段都适用。
• 连续的全零段可以用 :: 压缩一次:2001:db8:0:0:0:0:0:1 可以写成 2001:db8::1。
• 十六进制字母大小写不敏感:2001:DB8::1 和 2001:db8::1 相同。

把这三条排列组合，一个地址就有几十种合法写法。人眼能看出它们是一回事，但 sort | uniq 这类按字节比较的工具不会。这正是去重前必须先做一步规范化的原因。

规范化再比较:展开、去前导零、转小写

可靠的去重不是比较你看到的字符串，而是比较地址的规范形式。这个工具的处理顺序是:把每一段补齐到完整的四位十六进制(等价于先把 :: 展开成全部八段、再补回省略的前导零)，统一转成小写，得到一个唯一的归一结果，然后再按这个结果判重。

举个具体例子。输入是这样三行:

2001:db8::1
2001:0DB8:0000:0000:0000:0000:0000:0001
2001:db8::1

三行经过展开、去前导零、转小写后归一到同一个值 2001:db8::1。去重结果只保留一行:

2001:db8::1

并标注重复次数为 3、首次出现在第 1 行。注意输出保留的是首次出现的原始写法，归一只用于判重，不会强行改写你的数据。如果你想统一成展开或压缩格式，可以接着用 IPv6 规范化工具 处理。

日志统计独立 IP:别把一个客户数成十个

我之前帮同事核对一份双栈访问日志，想算清楚到底有多少个独立 IPv6 客户端。原始日志里同一个客户端在不同行被写成了压缩和展开两种形式，按行直接 uniq 出来的数字比真实值高了将近一倍。把日志粘进去规范化后再去重，独立 IP 数才落到真实区间，重复次数那一栏也直接说明了每个地址出现过多少次，省去了我自己写脚本统计的功夫。

日志场景里这一步尤其重要:运维报表、限流名单、异常 IP 排查，只要计数依赖"独立地址"，就必须先归一再统计，否则结论会偏。

整理白名单与防火墙规则

白名单和 ACL 规则同样怕重复条目。一份手工维护的允许列表里，不同人按各自习惯录入地址，有人写全展开形式，有人写压缩形式，时间一长就出现"看起来不同其实重复"的条目。去重一遍能把列表收敛成每个地址一行，避免规则里同一个地址出现两次造成的混乱。

清理完之后，输出可以直接切换成 CSV、JSON、SQL IN 或 TypeScript union 等格式，交给脚本或配置文件使用。如果只是想先把地址从一大段混杂文本里抓出来，可以先用 IPv6 地址提取工具 拿到原始列表，再回到 IPv6 地址去重工具 做归一去重。

全程本地处理，地址不外发

IP 地址往往关联客户和内部网络拓扑，属于敏感信息。这个工具的解析、校验、规范化、去重、复制和下载都在浏览器本地完成，上传的日志文件通过 File API 在当前标签页读取，没有任何地址发送到服务器。你可以放心把访问日志或路由表粘进去，不必担心数据外泄。需要留审计线索时，记得下载带行号的 CSV 或 Markdown，而不是只复制最终列表。

去重看起来是小事，但前提的"归一"做对了，统计、白名单、安全名单这些下游工作才站得住。理解了多种写法本质是同一个地址，剩下的就交给工具按规范形式比较即可。

---

Made by Toolora · Updated 2026-06-13