颜色批量转换实战：把一堆 hex 转 rgb 并迁移到 CSS 变量

接手一份旧项目的样式表时，我遇到过这样的场景：设计师从 Figma 导出一张色板，里面混着 #1A73E8、#fff、ff0000 这种格式各异的色值，几百行。要把它们统一规范化，再转成团队约定的 rgb() 写法塞进 CSS 变量，手工一个一个算，半天都做不完，还容易抄错。颜色批量转换这件事，本质上是格式搬运加校验，正好适合交给工具批处理。

为什么需要批量处理颜色，而不是逐个手算

一份真实的色板很少是干净的。它可能来自设计令牌文件，可能是从浏览器复制的样式，也可能是同事在工单里贴的一串色值。混在一起就是三类麻烦：大小写不统一（#1A73E8 和 #1a73e8）、带不带井号不一致（ff0000 漏了 #）、还有缩写没展开（#fff 其实是 #ffffff）。逐个处理几十上百个色值，注意力很快就涣散，漏一个就是线上的一处错色。把整批文本一次性丢进解析器，让它统一吐出规范结果，才是省心的做法。

hex 转 rgb 到底是怎么算的

十六进制颜色其实就是把红、绿、蓝三个通道各用两位十六进制数表示。转 rgb 的核心，是把每两位从十六进制换算成十进制：每一位的权重分别是 16 和 1，所以 1a 等于 1×16 加 10，得到 26；73 等于 7×16 加 3，得到 115；e8 等于 14×16 加 8，得到 232。三段拼起来，#1a73e8 就转成了 rgb(26, 115, 232)。

来看一个真实的输入输出例子。把这一行粘进来：

#1a73e8

工具规范化后给出的就是 rgb(26, 115, 232)。整批输入时，每一行都按同样规则换算，缩写如 #fff 会先补全成 #ffffff 再计算，避免少算一半通道。

统一大小写、井号和缩写，让色板可比对

颜色批量转换不只是换格式，更重要的是把杂乱写法收敛成一种规范形态。我的习惯是先做三件事：所有字母统一成小写，所有色值统一带上 #，所有三位缩写补全成六位。规范化之后再去重，重复的色板项才能被准确识别出来，不会因为 #FFF 和 #ffffff 被当成两个色。如果你只想得到规范化后的色值，可以用十六进制颜色规范化单独跑这一步；要找出重复色，则交给十六进制颜色去重。

把色板迁移到 CSS 变量和设计系统

最常见的交付场景，是把整理好的色板搬进设计系统。导出成逐行、CSS、JSON 或表格之后，我会按命名规范包成 CSS 变量，例如：

:root {
  --brand-primary: rgb(26, 115, 232);
  --danger: rgb(255, 0, 0);
}

这样下游的组件库、看板和文档引用的是同一套变量，改一处就全站生效，不用再满项目找散落的硬编码色值。如果你的样式里已经写了一批变量，想反过来把它们抽出来盘点，可以用 CSS 变量提取先把现有变量名和取值列清楚，再和新色板对照迁移。

本地处理，源文件不上传

色板有时跟着品牌资产或未发布的设计走，不该随便传到第三方服务器。十六进制颜色列表转换器的解析、校验、去重、转换、复制和下载全部在浏览器当前标签页完成，上传的文本文件由 File API 本地读取，不会经过服务器。这意味着你可以放心把内部设计令牌文件直接拖进来，规范化、转格式、导出交接产物，整个过程数据都留在你自己的电脑里。

给一份能直接交接的产物

我一般不会只复制最终那串色值，而是导出带行号的 CSV 或 Markdown。这样万一某个色值有争议，能回到原始行号去查它从哪来。无效项也建议保留：多打一位的 #12345、七位的 #aabbccd、漏井号的 ff0000，都会被标出来让你补全，而不是被悄悄丢掉。一份既规范又留了审计线索的色板，交给同事时不用再口头解释一遍。

颜色批量转换说到底是把重复劳动交出去，把判断留给自己。格式换算、大小写收敛、缩写补全这些机械活让工具跑，你只需要确认命名和取值是否符合设计意图，迁移到 CSS 变量这一步就既快又稳。

Made by Toolora · Updated 2026-06-13