UUID 规范化:让混乱的标识符回到同一种写法

一张表里同一个 UUID 出现三种长相,是很多人都踩过的坑。数据库导出给你 550e8400-e29b-41d4-a716-446655440000,运营那边用 .NET 工具生成的却是 {550E8400-E29B-41D4-A716-446655440000},再有人从某个接口日志里复制出来的是去掉连字符的 32 位裸串。三份数据指向同一个资源,字符串比对却判定它们各不相同。

规范化(也叫归一)做的事就是把这些不同长相统一成一种约定形式,通常是小写、加上标准的 8-4-4-4-12 连字符、去掉花括号。统一之后,去重、比对、入库才有意义。

为什么不同来源的 UUID 写法会不一样

UUID 本身只是 128 位的数字,它的"长相"完全取决于生成它的那套工具怎么打印。

微软系的 GUID 习惯用大写并外包一对花括号,{550E8400-...} 是注册表和 COM 组件里的常见形态。Java、Python、PostgreSQL 多数输出小写带连字符。还有些场景为了省空间或拼 URL,会把连字符整个去掉,变成纯 32 位十六进制。再加上从网页或工单里复制时夹带的隐藏空白、全角字符,同一个值就能凑出五六种写法。

这些差异在人眼里"显然是同一个",在程序眼里却是六个不同字符串。只要不先抹平差异,任何按字符串去重的逻辑都会漏判。

标准形式长什么样

业界默认的规范形式有三条:全部小写、保留 8-4-4-4-12 的连字符分组、去掉外层花括号。也就是说,无论输入是大写、裸 32 位还是带括号,都要收敛到这一种:

大写转小写
32 位裸串按 8-4-4-4-12 重新插入连字符
去掉首尾的 { 和 }
去掉复制带进来的空白

一个真实的输入输出例子

我自己上周清一份跨系统对账表时就用它跑了一遍。手头那列长这样:

{550E8400-E29B-41D4-A716-446655440000}
550e8400e29b41d4a716446655440000
550e8400-e29b-41d4-a716-446655440000

规范化之后,三行收敛成同一个值:

550e8400-e29b-41d4-a716-446655440000

带括号的去了括号、转了小写,裸 32 位补回了连字符,本来就标准的那行原样保留。这时再去重,三行合成一行,对账表才对得上。

去重和比对之前,先规范化

这是最容易被忽略的顺序问题。很多人拿到两份名单直接做差集,结果发现"两边几乎没有交集",其实只是写法不同。

正确的流程是:先把两份数据各自规范化,再做去重和比对。先归一再去重,大小写和连字符的差异就不会制造假的"不重复"。如果你需要的是纯粹的去重,可以接着用 /zh/t/uuid-deduplicator/ 把统一后的列表压成唯一值;要从一大段日志或 HTML 里先把 UUID 抠出来,则用 /zh/t/uuid-extractor/ 抓取再归一。

为什么坚持本地处理

UUID 往往是订单号、用户标识、内部资源 ID,带着业务含义。把这类数据贴进某个在线工具、让它发到不知道谁的服务器,本身就是一次数据外泄风险。

/zh/t/uuid-normalizer/ 的解析、校验、去重、规范化和导出全部在浏览器这一个标签页里完成,上传的文本文件也是通过本地 File API 读取,不发往服务器。处理客户标识符时,这一点不是锦上添花,是底线。

校验通过不等于真实存在

最后提醒一句容易混淆的概念:规范化和校验只保证"格式合法",不保证"对应的资源真的存在"。一个写法完美的 UUID,背后的账号可能早就被删了。把它当成查重和入库前的清洗步骤就好,别拿它做存在性验证。需要保留审计线索时,不要只复制最终列表,记得连带行号一起导出 CSV 或 Markdown,方便日后回查。

Made by Toolora · Updated 2026-06-13