免费UUID生成器 - 即时创建V1和V4 UUID
在线生成版本1基于时间戳与网卡地址和版本4基于随机数这两种最常用的UUID标识符。免费工具详细说明UUID各字段的具体格式结构、生成所用的算法逻辑以及所遵循的RFC 4122国际标准,适用于数据库主键设计、分布式系统节点标识和API接口中需要全局唯一ID的开发场景。
UUID生成器
文档
通用唯一标识符生成器
通用唯一标识符生成器是一种创建通用唯一标识符的工具:通用唯一标识符是一种 128 位代码,用于标记数据项,因此世界任何地方的其他数据项都几乎不可能拥有相同的标记。本页面生成版本 1(基于时间)和版本 4(随机)通用唯一标识符。
什么是通用唯一标识符?
通用唯一标识符是一个 128 位数字,以 32 个十六进制数字书写(字符 0–9 和 a-f)。它按以下模式分为五组,各组之间用连字符分隔:8-4-4-4-12,总计 36 个字符。通用唯一标识符示例:
1550e8400-e29b-41d4-a716-446655440000
2通用唯一标识符由互联网工程任务组于 2024 年五月发布的 RFC 9562 定义,该标准取代了 2005 年发布的旧 RFC 4122。两份文档描述的是相同的 128 位格式。软件使用通用唯一标识符标识数据库行、文件、用户会话和其他记录,而无需中央机构分配编号。由于可能的通用唯一标识符数量极其庞大,两台计算机可以独立地在同一时刻生成通用唯一标识符,却几乎不会生成相同的通用唯一标识符。
通用唯一标识符的格式和结构
通用唯一标识符的 128 个位分为多个命名字段。每个字段占用固定数量的位:
time_low- 32 位time_mid- 16 位time_hi_and_version- 16 位clock_seq_hi_and_reserved- 8 位clock_seq_low- 8 位node- 48 位
time_hi_and_version 内的四个位保存通用唯一标识符的版本号,clock_seq_hi_and_reserved 内的两个位保存变体,用于告知软件如何读取其余字段。标准定义了八个版本。
上述字段名称来自版本 1,在该版本中它们确实保存时间值和节点值。其他版本保留相同的 8-4-4-4-12 布局和相同的字段边界,但大部分位填充的是随机数据。在版本 4 通用唯一标识符中,标记为 time_low 的组保存的是随机值,而不是时间。
如何使用此工具生成通用唯一标识符
- 选择一个版本:版本 1(基于时间)或版本 4(随机)。
- 从结果框中读取通用唯一标识符。页面加载或版本发生变化后,会立即显示一个新的通用唯一标识符。
- 选择“生成”以生成另一个通用唯一标识符。
- 选择“复制”将结果复制到剪贴板,然后将其粘贴到代码、数据库或配置文件中。
结果下方的面板会将通用唯一标识符分为五个字段并为每个字段命名,因此很容易找到版本数字和变体数字。
版本 4 适合大多数用途,包括数据库键和会话令牌,因为它不包含创建时间或创建位置的信息。版本 1 适合需要从标识符本身恢复创建时间的记录,例如日志条目。
通用唯一标识符版本 1 与版本 4
版本 1 编码当前时间戳,以及随机选择的时钟序列和节点值。标准允许节点值使用计算机的真实网络媒体访问控制地址,但也允许使用随机生成的节点值作为保护隐私的替代方案。本工具始终使用随机选项:它生成的版本 1 通用唯一标识符从不读取或公开真实的媒体访问控制地址。标准还要求随机节点值的首字节最低位设置为 1,本工具也会设置该位。真实网卡从不会设置这一位,因此随机节点不可能被误认为真实节点。这就是本页面生成的版本 1 通用唯一标识符中第五组的第二个十六进制数字始终为奇数的原因:1、3、5、7、9、b、d 或 f。
版本 1 通用唯一标识符内的时间戳可以读回,因此可以按记录创建顺序排列。直接排序通用唯一标识符文本无法做到这一点,因为第一组保存时间戳的最低 32 位,而这些位大约每 7 分钟循环一次。RFC 9562 新增的版本 6 将相同的时间戳按最高位在前的顺序存储,因此普通文本排序即可生效。
版本 4 由随机位构成,其中少数位固定用于标记版本和变体。它不包含时间戳或特定于机器的数据,因此不会泄露创建时间或创建位置。它无法按创建顺序排序。
标准中还存在另外六个版本,但本工具不会生成它们:版本 2(DCE 安全版本,很少使用);版本 3 和版本 5,通过使用 MD5 或 SHA-1 对命名空间和名称进行哈希构建,因此相同输入始终生成相同通用唯一标识符;以及 RFC 9562 于 2024 年 (24,300 cm) 新增的版本 6、7 和 8,用于可排序和自定义标识符。
如何计算通用唯一标识符(公式)
版本 4:
- 生成 128 个随机位。
- 将四个版本位(第三组的第一个十六进制数字)设置为
0100(十六进制4)。 - 将第四组的最高两位设置为
10(因此该组的第一个十六进制数字为8、9、a或b)。
128 个位中只有 122 个是真正随机的,因为步骤 2 和 3 固定了 6 个位。这样就有 2^122 个可能的版本 4 通用唯一标识符,即约 5.3 × 10^36 个。
版本 1:
- 将当前时间表示为自公历改革日期 1582年10月15日 起经过的 100 纳秒间隔数。实际计算方式是普通 Unix 时间(以毫秒计)加上 12,219,292,800,000,再乘以 10,000。
- 将这个 60 位计数分配到三个字段:最低 32 位放入
time_low,接下来的 16 位放入time_mid,最高的 12 位放入time_hi_and_version。 - 生成一个 14 位的时钟序列,用于在系统时钟向后调整时避免冲突。
- 生成一个 48 位的节点值,并将其首字节的最低位设置为 1。
- 将版本位设置为
0001,将变体位设置为10。
在所有通用唯一标识符版本中,完整的 128 位空间包含 2^128 个可能值,即约 3.4 × 10^38 个。这个数量如此庞大,以至于随机碰撞在实际应用中无需考虑。
计算示例
读取版本 4 通用唯一标识符。 使用前面的示例:550e8400-e29b-41d4-a716-446655440000。
- 第三组
41d4:第一个数字为4,表示这是版本 4 通用唯一标识符。 - 第四组
a716:第一个数字a(二进制1010)以10开头,这就是要求的变体位。 - 其余十六进制数字是随机载荷。
读取此通用唯一标识符的程序会检查 4 和 10 模式以确认格式,然后将其余部分视为不透明的随机值。
构建版本 1 通用唯一标识符。 假设时钟显示 Unix 时间的 1,700,000,000,000 毫秒,即 UTC 22:13:20、2023年11月14日。
- 加上偏移量:1,700,000,000,000 + 12,219,292,800,000 = 13,919,292,800,000 毫秒。
- 乘以 10,000,得到 100 纳秒间隔:139,192,928,000,000,000。用十六进制表示为
01EE833B04AFC000。 - 分割该数:
time_low=04AFC000(最低 8 个十六进制数字),time_mid=833B(接下来的 4 个数字),最高 12 位为1EE。 - 将版本数字
1放在1EE前面,得到time_hi_and_version=11EE。
通用唯一标识符随后为 04afc000-833b-11ee-,后面接时钟序列和节点值。软件可以反向执行这四个步骤,从标识符中恢复出 2023年11月14日。
通用唯一标识符的常见用途
- 数据库中的主键,尤其适用于多个服务器同时创建记录而无需相互通信的情况。
- 会话令牌和应用程序接口密钥,通常使用版本 4,因为它能提供隐私保护。
- 分布式系统(如微服务)中的文件、事件和资源标识符。
- 大型物联网网络中的设备标识符,此时每台设备都可以离线生成自己的标识符。
主要权衡在于大小:UUID 占用 16 字节存储空间,而简单整数计数器只需 4 或 8 字节;此外,一些数据库对 UUID 的索引速度比对连续整数更慢。
UUID 的替代方案
自增整数更小、更简单,但当多个服务器需要独立分配标识符时,表现不佳。Snowflake 标识符由 Twitter 开发,将时间戳与工作节点标识符结合,在分布式系统中生成紧凑且可排序的标识符。ULID(通用唯一字典序可排序标识符)是一种较新的格式,旨在同时具备随机性并可按创建时间排序,这一点不同于标准版本 4 UUID。
UUID 标准的历史
通用唯一标识符的概念于 1980 年代起源于阿波罗计算机公司,是其网络计算系统的一部分。开放软件基金会后来为其分布式计算环境采用了这一格式。互联网工程任务组于 (10,500 cm) 2005 年发布 RFC 4122,并于 2024 年五月以 RFC 9562 取代它。RFC 9562 保持所有早期版本继续以不变的方式工作,并新增版本 6、7 和 8。
常见问题
UUID 生成器用于什么? 它为数据库、分布式系统、会话令牌、应用程序编程接口密钥和设备标识符创建唯一标识符,使任何两条记录都无需共享同一个标识符。
UUID v1 和 v4 有什么区别? 版本 1 编码了软件可以读回的时间戳,从而恢复创建时间。版本 4 完全随机,不包含时间戳。本工具的版本 1 输出使用随机生成的节点值,而不是真实的媒体访问控制地址,因此也不会泄露可识别机器的信息。
版本 1 会泄露我的媒体访问控制地址吗? 使用本工具不会。标准允许版本 1 UUID 的节点字段保存真实媒体访问控制地址,但本生成器始终用随机位填充该字段,并设置用于标记该值不是真实网络地址的位。
UUID 能保证唯一吗? 任何标识符方案都无法保证绝对唯一,但 128 位空间包含约 3.4 × 10^38 个可能值,版本 4 UUID 约有 5.3 × 10^36 个可能的随机值。重复的概率足够小,在几乎所有实际用途中都可以忽略。
可以将 UUID 用作数据库主键吗? 可以。在分布式系统中,UUID 很适合作为主键,因为任何节点都可以生成 UUID,而无需向中央服务器查询。代价是每个键需要 16 字节存储空间,比典型整数更多,并且在超大表中索引性能可能更慢。
UUID 和 GUID 是同一个东西吗? 是。GUID(全局唯一标识符)是微软对 RFC 4122 定义的同一概念(UUID)的称呼。
版本 4 UUID 可以按创建时间排序吗? 不可以。版本 4 UUID 是随机的,因此不包含创建时间信息。版本 1 UUID 包含创建时间信息,但必须先进行解码;直接排序文本无法得到创建顺序。版本 6、版本 7 和 ULID 设计为可以直接按文本排序。
参考文献
- 戴维斯,K.、皮博迪,B. 和 利奇,P.(2024)。Universally Unique IDentifiers (UUIDs). RFC 9562。https://www.rfc-editor.org/rfc/rfc9562
- 利奇,P.、米林,M. 和 萨尔茨,R.(2005)。A Universally Unique IDentifier (UUID) URN Namespace. RFC 4122。https://www.rfc-editor.org/rfc/rfc4122
- 通用唯一标识符。载于 Wikipedia。https://en.wikipedia.org/wiki/Universally_unique_identifier
- 雪花标识符。载于 Wikipedia。https://en.wikipedia.org/wiki/Snowflake_ID
- ULID 规范。GitHub。https://github.com/ulid/spec