UUID 生成工具

在线批量生成符合 RFC 4122 的 v4 UUID,使用浏览器的密码学随机源。同时可校验并识别已有 UUID 的版本。

所有处理均在你的浏览器内完成,数据不会上传。

使用浏览器的密码学随机源生成,不是 Math.random。

校验 UUID

使用方法

  1. 设置生成数量,最多 100 个。
  2. 选择格式:标准、大写、无连字符,或加花括号。
  3. 重新生成换一批,或用全部复制取走。
  4. 底部可以粘贴任意 UUID 做校验,并读出它的版本号。

关于 UUID

UUID 是一个 128 位的标识符,设计目标是在没有中心机构分配号码的情况下保证唯一。这个特性 就是它存在的全部意义:两个从未通信过的系统各自生成标识符,日后合并数据时也不会撞车,因为 碰撞概率可以忽略不计。

v4——也就是这里生成的这种——靠的是「几乎全随机」来实现这一点。128 位里有 6 位花在版本号和 变体字段上,这就是为什么你会看到第二个连字符后固定是 4、第三个连字符后必是 8/9/a/b。 剩下的 122 位是纯随机。

真正值得在意的是这份随机性的质量。 Math.random() 是伪随机生成器,它的输出可以从先前的 值推算出来;用它生成会话令牌或密码重置链接是实打实的安全漏洞。本工具使用的 crypto.getRandomValues() 取自操作系统的密码学熵池,不可预测。

还有一个实际的注意点:v4 UUID 没有顺序。相隔一秒生成的两个,和相隔几年生成的两个,排序上 一样毫无关联——而这恰恰是按主键顺序插入的数据库索引最不想要的。v7 版本把时间戳放在高位来恢复 这种局部性,同时保留唯一性保证,对于写入压力大的新表结构,它是更好的默认选择。

常见问题

这些 UUID 是真随机的吗,能安全使用吗?

可以。它们来自 crypto.getRandomValues,也就是浏览器的密码学安全随机源,而不是 Math.random。后者速度快但可预测,不适合用于不能被猜到的标识符。

是在服务器上生成的吗?

不是,而这件事比听上去重要——在别人服务器上生成的 UUID,就是别人见过的 UUID。这里全部本地生成,不会传输出去。

碰撞的概率有多大?

v4 UUID 有 122 位随机数。大约要生成 2.7 × 10^18 个,出现一次碰撞的概率才达到 50%。按每秒一百万个算,约需八万五千年。实际工程中不需要为碰撞做特殊设计。

为什么每个 UUID 同一个位置都有个 4?

那一位是版本号字段,由规范固定。第三个连字符后面那位是变体字段,只会是 8、9、a、b。正是这六个比特,让 v4 UUID 的随机位是 122 位而不是 128 位。

该用 UUID 做数据库主键吗?

取决于索引。随机的 v4 UUID 会让插入分散到 B 树各处,造成索引碎片,在大表上拖慢写入——在使用聚簇主键的 MySQL 里这是实打实的代价。v7 版本以时间戳开头、因而大致按创建时间有序,就是为解决这个问题设计的。如果你能控制表结构且写入量大,去看看 v7。