UUID、ULID 和 Nano ID 生成器
批量生成 UUID v4、按时间排序的 UUID v7、ULID 和 Nano ID,并读出 ID 中的版本和时间戳。
把工具固定在这里,会保存在此浏览器中。
固定一个工具,它的贴纸就会出现在这里。
批量生成 UUID v4、按时间排序的 UUID v7、ULID 和 Nano ID,并读出 ID 中的版本和时间戳。
UUID 版本 4 由 122 个随机位组成。它不透露任何关于生成时间或地点的信息,如果 ID 只需要唯一,通常就用它。UUID 版本 7 于 2024 年在 RFC 9562 中标准化,在 74 个随机位前面放了一个 48 位的毫秒级 Unix 时间戳。新 ID 排在旧 ID 之后,因此一起插入的行在数据库索引中也会挨在一起,代价是任何看到 ID 的人都能知道它的创建时间。
ULID 沿用同样的思路,只是写法不同:48 位时间和 80 个随机位,用 26 个不区分大小写的 Crockford Base32 字符表示,不带连字符。Nano ID 是一个随机字符串,长度和字符集都由你选择。默认从 64 个 URL 安全的符号中取 21 个字符,含 126 个随机位,比版本 4 的 UUID 略多,而字符串更短。
理论上随机 ID 可能发生碰撞。对于版本 4,大约要生成 2.7 × 10^18 个 UUID,出现一次重复的概率才会达到一半,所以应用程序把它们视为唯一。较短的 Nano ID 或较小的字符集会缩小这个余量:选项下方的那行文字会显示你的选择能提供多少随机位。
ID 是标识符,不是机密。版本 1、6、7 以及 ULID 会暴露其生成时间,而且 RFC 9562 警告不要把 UUID 当作权限凭证。对于密码重置链接、会话或 API 密钥,请使用至少 128 位的随机令牌,并在服务器上只保存它的哈希。
在常见的 xxxxxxxx-xxxx-Vxxx-Nxxx-xxxxxxxxxxxx 形式中,数字 V 是版本,N 的前几位是变体:几乎所有 UUID 都采用 RFC 9562 布局,此时它是 8、9、a 或 b。版本 1 和 6 包含一个 60 位的计数,表示自 1582 年 10 月 15 日起经过了多少个 100 纳秒,另外还有一个节点 ID,最初是网卡的 MAC 地址。版本 7 包含 Unix 毫秒数。版本 3 和 5 是名称的哈希,版本 4 是随机的,所以它们没有可解析的内容。
ULID 的前十个字符是它的时间戳。解析器也接受不带连字符、带花括号或带 urn:uuid: 前缀的 UUID。
每一个随机位都来自 crypto.getRandomValues,即浏览器的密码学安全随机数生成器。不会向服务器请求任何内容,也不会保存任何内容。
在同一毫秒内生成的版本 7 UUID 会保持时间戳不变,并在 74 个随机位上加一个随机步长,这是 RFC 9562 中描述的单调方法,因此一批 ID 总是按生成顺序排序。同一毫秒内生成的 ULID 会把随机部分加一,这是 ULID 规范描述的做法。这个顺序只对本页生成的 ID 成立,不同机器在同一毫秒内生成的 ID 没有确定的顺序。Nano ID 的字符通过丢弃落在字符集之外的随机字节来选取,因此每个符号出现的概率都相同。
如果你希望新行在索引中彼此相邻,并且不介意 ID 暴露其创建时间,版本 7 更适合做主键。如果 ID 必须不泄露任何信息,就选版本 4。两者都是 128 位,都能放进同一种 uuid 列。
有可能,但概率低到无需为此做准备。版本 4 UUID 有 122 个随机位,大约要生成 2.7 × 10^18 个,出现一次重复的可能性才会达到一半。真正的风险是随机源太弱,所以此工具使用浏览器的密码学安全随机数生成器。
不是,但两者很相似。它们都是 128 位,并以 48 位毫秒级时间戳开头,因此 ULID 的位可以放进 128 位的 UUID 列。ULID 没有版本和变体字段,所以 RFC 9562 不把它定义为 UUID;而且它的文本形式使用 Crockford Base32,而 UUID 使用十六进制。
UUID 版本 1、6、7 以及 ULID 可以,因为它们带有时间戳。把值粘贴到解析器中,即可看到对应的日期。版本 4 UUID 是随机的,不包含时间。
它会在独立窗口中打开,离线时也能使用。
要安装,请点按“分享”按钮,然后选择“添加到主屏幕”。