什么是UUID 正则测试
UUID 正则常见有两种写法。宽松写法只检查形状:8-4-4-4-12 的分组和十六进制字符。严格写法同时限制版本号在 1 到 8 之间、变体位必须是 8、9、a、b 之一。
在日志校验、CSV 导入和接口参数检查里,通常应该用严格写法 —— 否则 00000000-0000-0000-0000-000000000000 这类看起来像 UUID 却不合规的值会被放过去。
使用方法
- 粘贴值,每行一个,最多 200 行。
- 点击测试正则。
- 表格会逐行给出是否匹配、以及匹配的是哪条规则。
- 汇总行统计共有多少条命中严格写法。
适用场景
- 在写导入校验之前,先拿真实数据试一遍正则。
- 找出日志里混进来的格式错误的值。
- 确认自己的正则是否过于宽松,把无效值也放行了。
结构
这里的正则作用于「分组 + 十六进制字符 + 版本位 + 变体位」,因此拿它来判断一个字符串是否是 UUID 是可靠的,但要判断某个具体值是否真实存在,正则做不到。
UUID 正则测试 的定位
| 选项 | 何时使用 |
|---|---|
宽松正则 | 只检查分组与十六进制字符,形状对了就放行 |
严格正则 | 额外限定版本 1–8 与变体 [89ab],校验外部输入用这条 |
校验工具 | 除了是否匹配,还会说明是哪一位不合法 |
UUID 各版本速查表
| 版本 | 可排序 | 数据来源 | 适合的场景 |
|---|---|---|---|
| v1 | 不可以 | 时间戳 + MAC 地址 | 仍在依赖 v1 的既有系统 |
| v3 | 不可以 | 名称的 MD5 哈希 | 必须使用 MD5 时的确定性标识符 |
| v4 | 不可以 | 122 位随机数 | 绝大多数普通的唯一标识需求 |
| v5 | 不可以 | 名称的 SHA-1 哈希 | 需要同一名称始终得到同一标识符 |
| v6 | 可以 | 重排后的时间戳 | 既要随机性又要便于排序 |
| v7 | 可以 | 毫秒精度的 Unix 时间 | 数据库主键和事件标识符 |
| v8 | 不可以 | 自定义位布局 | 专有格式和实验性用途 |
这七个版本都是 128 位,都用同样的 8-4-4-4-12 写法表示,区别只在于各个位代表什么。
代码示例
javascript
// 宽松:只检查形状
/^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i
// 严格:限定版本 1-8 与变体 [89ab]
/^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-
[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i
python
import re
re.fullmatch(r"[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12}", v, re.I)
常见问题
应该用严格写法还是宽松写法?
校验外部输入时用严格写法。只有在做数据探查、想先看看有哪些形状时,宽松写法才有用。
为什么我的正则在别的工具里能过,这里却不过?
多半是版本位或变体位不合法。比如 ...-0000-0000-... 版本号是 0,宽松写法会放行,严格写法会拒绝。
这个工具会检查 UUID 是否真的存在吗?
不会。正则是纯粹的格式判断,唯一性属于生成端的责任。