十六进制颜色批量检查实战:颜色校验前先把脏值挑出来

接手别人的设计稿或者旧项目的色值表时,我最怕的不是颜色多,而是里面混着写错的值。一列看起来整整齐齐的 hex 颜色,真要导进去才发现有几个根本不合法,有的漏了井号,有的多写了一位,还有的把字母 g 当成十六进制塞了进来。手工一个一个看到第三十行眼睛就开始花。十六进制颜色批量检查这件事,本来就该交给工具做。

合法的十六进制颜色到底长什么样

先把判断标准说清楚,这是颜色校验的地基。一个合法的十六进制颜色,要满足三个条件:开头有一个井号 #,后面跟的字符只能是 0 到 9 和 a 到 f(大小写都行),并且位数正好是 3 位或 6 位。

举几个能直接对照的例子:

• #1a73e8 合法,6 位,每一位都在 0-9a-f 范围内。
• #fff 合法,3 位简写,等价于 #ffffff。
• #xyz 不合法,x、y、z 根本不是十六进制字符。
• #fffff 不合法,5 位,既不是 3 位也不是 6 位。
• 1a73e8 不合法,漏了井号。

这五条规则不复杂,但人在快速扫一长列时极容易放过 #fffff 这种只多了一位的值,因为它和 #ffffff 看上去差不多。机器不会累,逐条按规则比对,这正是批量校验的意义。

把一整列颜色一次性丢进去检查

实际用起来很直接。把从品牌规范、Figma 导出、CSS 变量表或者客服工单里复制来的那一列色值整段粘进 十六进制颜色列表校验器,它会逐行解析,然后给出一份每行带原因的报告。通过的标 OK,不通过的标出具体原因:是漏井号,是位数不对,还是夹了非法字符。

我自己常用的一个流程是:先把无效项保留下来一起带出来,而不是直接过滤掉。因为我要的不是一份干净列表,而是一份待修清单,知道哪几行错了、错在哪,才好回原文去改。改完再跑一遍,确认全绿,这时候才放心导入。

输出可以选 CSV、JSON、Markdown,也可以是逐行纯文本。要交给同事复核就导 CSV 带行号,要塞进代码就导 JSON 或者 TypeScript union,省得手工补引号和逗号。

导入前查错,比导入后救火省事

设计稿色值清洗这件事,放在导入前做和导入后做,代价完全不同。导入前一个 #xyz 只是报告里的一条红色记录;导入后它可能变成线上某个组件的背景透明、或者构建直接报错。我宁可在粘贴那一刻就把脏值挑出来。

从网页复制来的文本还有个隐藏坑:经常带看不见的空白字符。所以批量检查的时候,顺手做一次规范化再去重,能把同一个颜色因为前后多了空格而被当成两个的情况清掉。

找出拼错的颜色值,顺手统一格式

除了挑非法值,这套流程还能帮你统一写法。同一份表里 #FFF 和 #ffffff 可能并存,大小写不一、3 位和 6 位混着,虽然都合法,但对后续做颜色去重或者比对是干扰。先规范化成统一形式,再去重,清单就干净了。

如果你的需求更偏单一动作,可以分开用更专的工具:只想从一大段文本里把颜色抠出来,用 十六进制颜色提取器;只想把写法统一,用 十六进制颜色规范化工具;只想去掉重复值,用 十六进制颜色去重工具。它们和校验器是一套配合的工具,按你手上活儿的形状挑就行。

全程本地,文件不离开你的浏览器

色值表本身可能不算敏感,但它常常和别的内部数据混在一份导出里。所以解析、校验、去重、复制、下载这些动作全部在浏览器本地完成,拖进来的文本文件通过浏览器的本地接口读取,不会上传到服务器。令牌表和品牌色板很少超过几千行,在标签页里瞬间就能跑完;真要处理抓取得到的几兆色值大文件,建议先在本地分片再来。

颜色校验不是什么高深的事,但它是导入前那道最省心的关卡。把规则交给工具,把判断留给自己,一整列颜色谁合法谁拼错,一眼就清楚了。

---

Made by Toolora · Updated 2026-06-13