UUID 批量检查实战：在导入前把一堆 ID 的 UUID 校验做干净

我经手过一份从三个系统拼起来的用户表，里面两万多行 UUID。导入数据库之前我图省事直接跑了 import，结果中途报错，回头一行行排查才发现：有人在 Excel 里手敲了几个 ID，少了一位；还有一段是从客服工单里复制的，末尾粘进了一个不可见的空白字符。这种错肉眼基本看不出来，但数据库不认。从那以后，凡是要把一堆 ID 入库，我都先做一遍 UUID 批量检查。

UUID 到底长什么样

一个标准 UUID 是 32 位十六进制字符，用连字符分成五组，格式是 8-4-4-4-12。也就是说，第一组 8 位，第二组 4 位，第三组 4 位，第四组 4 位，最后一组 12 位，加起来正好 32 个十六进制字符（0 到 9 和 a 到 f），再加 4 个连字符，总长度 36 个字符。

举个具体的：

550e8400-e29b-41d4-a716-446655440000

数一下每段：550e8400（8 位）、e29b（4 位）、41d4（4 位）、a716（4 位）、446655440000（12 位）。任何一段位数不对，或者出现了 g 到 z 这种非十六进制字符，这一行就是非法的。

一个真实的有效与无效对照

把下面这三行粘进 UUID 列表校验器，结果一目了然：

550e8400-e29b-41d4-a716-446655440000   通过
550e8400-e29b-41d4-a716-44665544000    失败：长度不对（最后一段只有 11 位）
550e8400-e29b-41d4-g716-446655440000   失败：含非十六进制字符 g

第一行合法。第二行最后一段少了一位，常见于手工录入或者复制时漏选了一个字符。第三行第四段里混进了一个 g，多半是从字体相近的截图里抄错了。工具会在每一行旁边标出通过或失败，失败的还会点明原因列，告诉你到底是长度、字符还是版本位出了问题。

怎么区分 v4 和其它版本

UUID 不止一种版本。版本号藏在第三段的第一位，也就是 41d4 里的那个 4。如果这一位是 4，就是最常见的随机生成 v4；是 1 则是基于时间戳的 v1。版本位的合法范围是 1 到 5，如果这一位落在这个范围之外，说明这一行根本不是规范的 UUID，多半是被截断或者拼错了。

我自己最常用的场景是确认一批 ID 是不是清一色 v4。如果系统约定只用随机 UUID，那混进来一个 v1 往往意味着上游某个服务的实现不一致，值得回头查一查，而不是闷头入库。

批量处理的几个习惯

数据量一大，光看格式还不够。我会顺手做三件事：

去重。从多份导出拼起来的列表，重复 ID 很常见，导入前先合并掉。
规范化。网页复制的文本经常带隐藏空白和大小写混杂，统一成小写、去掉首尾空格再比对，避免同一个 ID 被当成两个。
留底。如果这批数据要交接或者要走合规复核，我会下载带行号的 CSV 而不是只复制最终列表，万一后面有人质疑，行号能直接定位到原文哪一行。

需要更细的拆分时，可以把 UUID 提取器先从一大段日志或 HTML 里把 ID 抓出来，再回到校验器做格式判定，两步配合处理混在正文里的 ID 会更顺手。

为什么坚持本地处理

UUID 经常就是主键、订单号或者用户标识，本身就是敏感数据。把它们贴到一个会上传到服务器的在线工具里做校验，等于把内部标识符往外送了一遍。这个校验器的解析、判定、去重和导出全部在你当前浏览器标签页里跑，上传的本地文件通过 File API 读取，不会发到任何服务器。对我来说这是底线：处理生产数据的 ID，工具能离线干活，我才敢用。

最后提醒一句，UUID 格式校验只能证明这串字符写法合规，不能证明对应的账号、订单或资源真的存在。格式对了只是第一关，真实性还得回到你自己的数据库里去查。

Made by Toolora · Updated 2026-06-13