UUID v4生成

UUID v4生成是一款免费工具，可创建版本 4 通用唯一标识符，用作记录、对象或请求的标识符。

UUID v4生成会如何处理我的数据？

生成操作在服务器上完成。输入内容会通过 HTTPS 发送到服务器，但不会被存储。因此，不能说生成过程完全在浏览器中进行，也不能说数据从未离开你的设备。

生成 UUID v4 不需要以个人文本内容、姓名或密码作为来源。它是直接生成的标识符，并非根据你提供的信息计算得出。不要为生成的值赋予机密含义，因为任何看到它的人都可以复制并重复使用。

什么是 UUID v4？

UUID v4 是一种 128 位标识符，其中可变部分通过随机或伪随机方式生成，另有若干位用于标记 UUID 的版本和变体。当多个独立系统需要自行创建标识符，而不必先向中央服务申请下一个可用编号时，通常会使用它。

标准书写形式包含 32 个十六进制字符，并用连字符分成五组。其格式为 8-4-4-4-12，计入四个连字符后总长度为 36 个字符。

符合语法规范的示例是 550e8400-e29b-41d4-a716-446655440000。在版本 4 UUID 中，第三组的第一个字符是 4。用于标识变体的两个最高有效位是 10，因此第四组开头的十六进制字符会是 8、9、a 或 b。

UUID v4 只是标识符，并不包含经过编码的信息。你无法对其解码来还原创建日期、账户名称、机器地址或序列号。

应该选择哪个 UUID 版本？

如果你需要独立生成且不透露含义的标识符，并且不要求相同输入产生相同结果，请选择版本 4。简单来说，v1 使用时间和节点信息，v2 是 DCE Security 格式，v3 使用 MD5 根据命名空间和名称派生 UUID，v4 是随机生成的，v5 使用 SHA-1 派生 UUID，v6 对基于时间的数据重新排序，v7 将 Unix 时间戳与随机数据结合，而 v8 用于实验性或供应商自定义格式。

• 如果随机分布的标识符适合你的场景，可将 UUID v4 用于记录 ID、上传引用、API 请求 ID 和测试夹具。
• 如果特定命名空间和名称必须始终生成相同的标识符，请使用 UUID v5。它适合可重复执行的导入流程和去重规则。
• 如果记录标识符需要大致按创建时间排列，并且数据库或软件支持，可考虑 UUID v7。
• 如果所有值都由同一个数据库创建，并且紧凑、自然有序的键比去中心化生成更重要，请使用普通的连续整数。

旧版本仍存在于现有系统中，但设计新系统时，应根据实际需求选择，不要把所有 UUID 版本视为可以互换。

如何在实际项目中使用 UUID v4

生成 UUID 后，从 UUID v4 结果字段中取出该值。除非接收系统要求使用其他表示形式，否则应保存完整的标准字符串。

1. 为需要标识的对象或事件创建一个新的 UUID。
2. 在系统之间传递时，保留全部五组字符和四个连字符。
3. 如果数据库提供 UUID 类型，请使用该类型。否则，根据所选表示形式，使用长度合适的文本或二进制字段。
4. 如果数据库必须拒绝重复生成的 UUID v4 值，请添加唯一约束。

常见用途包括在订单进入主数据库前为其分配标识符、关联多个服务中的日志条目、为上传的对象命名，或为准备导入的数据行分配稳定 ID。与本地整数序列相比，UUID 通常更容易用于合并独立创建的数据集，因为不同来源的整数序列中可能存在相同的值。

空格、标点符号、带重音符号的字母和非拉丁字符不会给 UUID v4 带来输入问题，因为生成过程并不根据文本派生标识符。如果需要根据包含此类字符的名称创建标识符，请使用基于名称的 UUID 方案，并明确定义字符编码和规范化规则。否则，视觉上相同的文本可能产生不同的字节序列，进而生成不同的标识符。

两个 UUID v4 会不会完全相同？

会，理论上可能发生碰撞。不过，只要生成时使用合适的随机源，在一般的 UUID v4 使用场景中，这并不是实际需要担心的问题。v4 UUID 有 122 个可变位，其余位用于标识版本和变体，因此可能的取值范围极其庞大。

因此，"通用唯一"是一种实用层面的描述，并非数学上的绝对保证。误复制或重复使用、实现缺陷，或随机源不充分时质量较差的随机数生成，都比纯粹的随机碰撞更可能导致重复。不能容忍重复的系统，仍应在数据库或应用边界强制执行唯一性。

UUID 也不能证明请求真实有效。不要仅把可见的 UUID 当作授权凭证，也不要因为对象地址难以猜测，就认为该对象受到了保护。访问检查应针对 UUID 所指向的实际资源执行。

常见问题

UUID 区分大小写吗？

不区分。UUID 文本中的十六进制字母通常不区分大小写，因此 A 和 a 表示同一个值。标准形式一般使用小写。在进行文本比较前统一字母大小写，可以避免某些区分字符串大小写的系统产生不一致结果。

UUID v4 可以用在 URL 或文件名中吗？

可以。标准形式只包含十六进制字符和连字符，适合用于普通 URL 路径段和常见文件系统。除非特定 API 明确要求，否则不要添加大括号。另外要注意，在 URL 中公开 UUID 并不会让资源变成私有资源。

需要删除 UUID 中的连字符吗？

只有在接收格式明确要求 32 个十六进制字符时才应删除。许多程序库和数据库 UUID 类型都接受带连字符的标准形式。这种形式更容易识别，也不易与无关的十六进制值混淆。

UUID v4 适合用作密码或 API 密钥吗？

不适合。标识符和密钥的用途不同。某些 UUID 实现可能采用合适的随机源，但 UUID 格式本身并不保证满足密码、会话令牌和 API 凭据在处理方式、保密性或熵方面的要求。请使用专门用于生成凭据或令牌的机制，不要用 UUID v4生成来完成这项工作。

根据英国 GDPR，UUID v4 会被视为个人数据吗？

可能会。如果 UUID 能够识别某个人，或可以关联到可识别的个人，即使字符本身没有直接透露姓名，也可能属于个人数据。对于与客户账户、设备或活动记录关联的 UUID，应结合具体使用情境，并按照组织的保留和访问规则进行处理。

UUID v4 可以用作数据库主键吗？

可以，许多数据库都直接支持 UUID 主键。与有序整数或基于时间的标识符相比，随机分布的键会使索引插入位置更分散，因此对于写入量较大的表，请查看所用数据库的相关建议。应保留唯一约束，并在导入、查询和应用代码中统一使用同一种存储表示形式。