MAC 地址校验:批量检查一堆 MAC 格式是否合法

做网络运维的人手里大概率有一份 MAC 地址清单。可能来自交换机导出,可能是同事用 Excel 维护的资产表,也可能是从某个旧系统里复制粘贴出来的。这份清单往往要灌进白名单、准入控制(NAC)或者交换机的 ACL 里。问题是,灌进去之前没人逐行核对过格式,而错一位、少一组、分隔符混用的行,常常要等到设备拒绝加载配置时才暴露。

我自己就被这种事坑过一次:一份两百多行的 MAC 表导入失败,报错只说"格式错误",没有指明哪一行。一行行肉眼看到第三遍才发现某一行被复制成了五组。那次之后我就习惯先做一遍批量校验。

合法的 MAC 地址到底长什么样

标准的 MAC 地址是 48 位,写出来是六组两位十六进制数,常见两种分隔写法:冒号分隔的 00:1A:2B:3C:4D:5E,或者连字符分隔的 00-1A-2B-3C-4D-5E。有些厂商设备里也会见到点分四位的写法(001a.2b3c.4d5e),但最普遍的还是上面两种。

每一组必须正好是两位,字符只能是 0 到 9 和 A 到 F(大小写都行)。位数不对、组数不对、混进了非十六进制字符,都是不合法的。批量校验要做的,就是把这套规则套到每一行上,逐条给结论。

一个真实的输入输出例子

把下面三行喂进 MAC 地址列表校验器:

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

输出会是逐行带原因的报告:

第一行 00:1a:2b:3c:4d:5e,六组两位十六进制齐全,判定为有效。
第二行 00:1A:2B:3C:4D,只有五组,缺一组,判定为无效,原因写明组数不足。
第三行 00:1A:2B:3C:4D:5G,最后一组里的 G 不是十六进制字符,判定为无效。

关键在于无效项不会被悄悄丢掉。失败清单本身就是校验的产出,这几行正是你要退回去修的行。报告可以导出成 CSV 或 JSON,每行都带着判定结果和原因,直接交给同事或脚本继续处理。

找出位数不对的那些行

实际清单里最常见的坏数据,就是位数或组数对不上。来源五花八门:

复制时漏掉了开头的 00,变成五组。
某一组被手敲成了一位或三位。
全角冒号、多余空格、Tab 混进了分隔符位置。
大小写混排其实合法,但有些下游系统要求统一,需要先规范化。

批量校验会把这些逐行标出来。如果你只是想把脏格式统一成一种写法,可以接着用 MAC 地址规范化工具把大小写和分隔符理齐。如果清单里有重复条目,MAC 地址去重工具能在导入前把重复行清掉。这几个工具是一条流水线:先校验找错,再规范化,再去重,最后导出。

导入设备和 ACL 之前先查一遍

为什么要在导入前校验,而不是导入后再排查?因为交换机、防火墙、NAC 这类设备对配置格式很挑剔,一行不合法常常导致整批加载失败,而报错信息又往往含糊。在本地先跑一遍批量检查,等于把"哪一行有问题、为什么有问题"提前摊开,你交付给同事的就是一份干净且可核对的清单,而不是一份还要对方猜的原始数据。

资产清单的场景也类似。一份设备 MAC 表如果格式不齐,后面做 802.1X 绑定、做端口安全、做白名单同步时都会反复出错。趁清单还在文本阶段就把格式钉死,比上线后逐台排查省力得多。

本地处理,清单不离开浏览器

MAC 地址虽然不算高度机密,但一份完整的设备资产清单暴露了你的内网拓扑、设备品牌和数量,属于不该随便上传的内容。这个校验器的解析、校验、去重和导出全部在浏览器本地完成,粘贴的文本和上传的本地文件都只在当前标签页读取,不发往任何服务器。你可以放心把生产环境的真实清单贴进去检查。

小结

批量校验 MAC 地址,本质是把"六组两位十六进制"这条规则套到清单的每一行上,把位数不对、字符不对、分隔符乱掉的行找出来并附上原因。在导入交换机、NAC 或 ACL 之前做这一步,能把模糊的设备报错,提前变成清晰的逐行清单。配合规范化和去重,一份原始 MAC 表就能变成可以直接交付的产物。

Made by Toolora · Updated 2026-06-13