MAC 地址去重：忽略大小写和分隔符，统计真实独立设备数

做网络盘点的人都遇到过这种事：手里有三份导出表，一份来自交换机端口表，一份来自 DHCP 租约，一份是某台服务器的 ARP 缓存。把它们拼在一起，行数加起来一千多，可你心里清楚，真实设备根本没那么多。同一台设备的网卡，在不同系统里被写成 00:1A:2B、00-1a-2b、001a2b 三种样子，肉眼一行行核对既慢又容易看花。

这正是 MAC 地址去重该解决的问题。它不是简单地删掉一模一样的行，而是先把每个地址归一化，再判断哪些其实指向同一块网卡。

为什么 00:1A:2B 和 00-1a-2b 是同一个设备

MAC 地址是网卡出厂时烧进硬件的唯一标识，本质上就是 48 位二进制，按惯例写成 12 位十六进制。问题在于，写法没有全行业统一标准：

分隔符可以是冒号 00:1A:2B:3C:4D:5E，也可以是连字符 00-1A-2B-3C-4D-5E，思科设备还爱用点分 001a.2b3c.4d5e。
十六进制字母 A 到 F 大小写都合法，2B 和 2b 指的是同一个字节。

所以 00:1A:2B:3C:4D:5E 和 00-1a-2b-3c-4d-5e 代表的是同一块网卡，只是被两个系统用各自的习惯打印出来而已。人工去重最容易踩的坑，就是把这两行当成两个设备分别计数，最后报上去的"设备总数"虚高一截。

归一化后再比较：去重的核心一步

可靠的去重不能直接比字符串，必须先归一化。具体做法是：去掉所有分隔符（冒号、连字符、点），把字母统一转成小写，得到一个纯净的 12 位序列，然后用这个序列做比较的依据。

举个实际例子。假设清单里有这两行：

00:1A:2B:3C:4D:5E
00-1a-2b-3c-4d-5e

归一化的过程是：两行都去掉分隔符，再转小写，结果都变成 001a2b3c4d5e。两个序列完全相等，于是它们被合并成一条，输出里只保留第一次出现的那行原文，并标注重复次数为 2。一千多行的混乱清单，经过这一步，独立设备数才浮出水面。

如果你只想把写法统一、还不打算合并，可以先用 MAC 地址规范化工具把全部地址转成同一种格式，再来去重，比对结果会更直观。

统计独立设备数，整理资产清单

去重不只是清理数据，更是为了回答一个具体问题：这个网段里到底有多少台设备在线。

工具去重之后，会给出每个唯一地址的重复计数和首次出现的行号。这两个信息很关键：

重复计数告诉你哪块网卡在多份导出里反复出现，往往是核心交换机或网关这类高频设备。
首次出现行号保留了证据链。当同事问"这个设备是从哪份表里来的"，你能直接翻回原文那一行，而不是只甩给他一份没头没尾的结果。

整理好的输出可以直接导出成 CSV、JSON、Markdown 表格，或者 SQL IN 片段。运维同事拿 CSV 录进资产系统，开发同事拿 SQL IN 直接写进查询，谁都不用再手工补引号、补逗号。需要从一堆日志或网页文本里先把 MAC 抓出来，可以配合 MAC 地址提取工具先做一遍预处理。

位数不对的地址，单独留着复核

我自己整理一份混着手动记录的清单时，碰到过 00:1A:2B:3C:4D 这种只有 10 位的地址。它显然是某次手抄漏了一段。这种位数不对的条目，去重工具不会硬把它并到某个长得像的完整地址下面，而是带着"位数不足"的原因单独列出来。

这个设计救过我一次。如果工具把这种残缺地址静悄悄折叠进相邻条目，它就从设备计数里消失了，而我永远不会知道有一行数据本来就是错的。留出来复核，意味着你能回头去补全它，或者确认它确实是噪声该删掉，决定权在你手里。

全程本地处理，清单不外发

MAC 地址清单往往牵涉到内网拓扑、设备归属这类不该外传的信息。这个工具的解析、归一化、去重、导出全部在浏览器当前标签页里跑，上传的本地文件用浏览器的 File API 读取，不会发到任何服务器。

把两份交换机端口表叠在一起找交集这种操作，那套拿每个地址跟其余逐一比对的去重逻辑，就在你这台机器上完成，合并后的设备清单从头到尾没有离开过浏览器。处理涉密资产数据时，这一点比任何花哨功能都重要。

如果你的去重目标只是想确认每个地址格式合法、写法一致，也可以直接用 MAC 地址去重工具把整份清单跑一遍，几 MB 的叠加表跑起来很轻松。要合并整个设备群，建议先按交换机在本地各自去重，再把合并清单整体过一遍，分层处理更稳妥。

Made by Toolora · Updated 2026-06-13