MAC 地址规范化：把混乱的设备写法统一成一种

接手过网络运维的人都知道一件麻烦事：同一台设备的 MAC 地址，在不同地方长得完全不一样。交换机后台导出的是 00:1A:2B:3C:4D:5E，思科设备的运行配置里写成 001a.2b3c.4d5e，Windows 的 getmac 命令吐出来的是 00-1A-2B-3C-4D-5E，资产表里某位同事手敲成了 001a2b3c4d5e。它们指的是同一块网卡，可一旦放进同一张表里做比对，机器会把它们当成四个不同的东西。

MAC 地址到底是什么

MAC 地址是网卡的硬件标识，固定 48 位，也就是 6 组、每组 8 位的十六进制数。换算成我们看到的字符，就是 12 个十六进制字符（0 到 9、a 到 f）。比如 001a2b3c4d5e 这 12 个字符，加上分隔符之后，可以写成冒号分隔的 00:1a:2b:3c:4d:5e，也可以写成连字符分隔的 00-1a-2b-3c-4d-5e。前三组（00:1a:2b）是厂商代码 OUI，由 IEEE 分配，后三组是厂商自己给每块网卡编的序号。

不管哪种写法，底层那 48 位是一模一样的。差异全在三个层面：分隔符是冒号、连字符还是点；分隔的粒度是每 2 位一组还是每 4 位一组；字母是大写还是小写。规范化要做的，就是把这三件事统一掉。

为什么各家写法不一样

这不是谁写错了，而是历史习惯不同。冒号分隔是 IEEE 802 和大多数 Linux 工具的默认；连字符分隔是 Windows 和部分打印标签的习惯；点分四位（001a.2b3c.4d5e）是思科 IOS 的独门写法，一台 Catalyst 交换机的 show mac address-table 出来全是这个样子。大小写更是随缘，有的设备一律大写，有的一律小写，复制粘贴几轮之后就彻底乱了。

这件事在管理上为什么要紧

三个场景最容易被写法不一坑到：

第一，资产表去重。两份导出合并时，00-1A-2B-3C-4D-5E 和 00:1a:2b:3c:4d:5e 在 Excel 里是两行，去重函数留不下唯一值，盘点出来的设备数虚高。

第二，ACL 白名单和准入控制。交换机或无线控制器的 MAC 白名单往往只认一种格式。你从工单里复制了一个连字符写法的地址填进去，设备按冒号格式比对，结果这台机器死活上不了网，排查半天才发现是分隔符的问题。

第三，脚本和数据库过滤。写一条 SQL 去匹配 MAC，或者用脚本批量下发配置，输入格式必须先归一，否则 WHERE mac IN (...) 永远命中不了。

一个真实的统一例子

我自己整理一份机房巡检清单时，把四个来源的地址直接粘在一起，原始数据长这样：

00:1A:2B:3C:4D:5E
00-1a-2b-3c-4d-5e
001A.2B3C.4D5E
001a2b3c4d5e

肉眼看这是四条，实际是同一块网卡的四种写法。把它们丢进 MAC 地址规范化工具，选冒号分隔、统一小写，再开去重，输出就剩一条：

00:1a:2b:3c:4d:5e

四种写法折叠成一行，资产表里这台设备只占一格，白名单里也只填这一个值。整个过程在浏览器本地跑，清单不上传服务器，对内部设备清单来说这点很关键。

规范化的几条实用规则

统一格式时，有几个细节值得注意。一是先规范化再去重：从网页或工单复制来的文本常带隐藏空白和零宽字符，不先归一就去重，会漏掉本该合并的行。二是无效项要留痕：如果某行只有五组（比如 00:1A:2B:3C:4D，缺了第十二位），工具不该硬凑，而要原样保留并标出原因，规范化那一列才靠得住。三是保留行号，方便回到原始日志里定位是哪条记录写错了。

清洗完的列表如果要交给数据库或脚本，直接导出成 SQL IN 或 JSON 比手工加引号省事得多，可以接着用 MAC 列表格式转换工具把干净列表换成你要的产物形式。

小结

MAC 地址规范化说到底是一件小事，但它卡在很多运维流程的上游：资产盘点、准入白名单、批量配置下发，只要输入格式不齐，后面全是返工。把冒号、连字符、点分写法和大小写统一成一种，让同一台设备永远只有一种写法，下游的去重、比对和过滤才能真正可靠。

Made by Toolora · Updated 2026-06-13