开发者工具 · UUID 生成器
基于名称的 UUID（v3 和 v5）：来自命名空间的确定性 ID
· 背景
uuid 密码学 浏览器 API
当相同的外部记录必须始终获得相同的标识符时，随机 UUID 将不起作用。版本 3 和 5 UUID 将命名空间和名称哈希为稳定 ID；这篇文章解释了如何以及何时使用它们。
重新导入同一个客户两次 — 确定性 ID 解决的重复问题
数据导入管道从外部系统接收客户记录，外部 ID 在该系统内稳定。如果您为每次导入运行生成一个新的随机 UUID，则导入同一客户两次会产生两个不同的标识符和重复记录。这种重复流入下游的报告、计费和支持系统。如果您从客户的外部 ID 和代表导入源的稳定命名空间派生 UUID，则每次导入都会为同一客户生成相同的 UUID，从而使您能够识别和更新现有记录。这种确定性是 v3 和 v5 UUID 的定义特征：它们不是独立生成的，而是从输入派生的，并且相同的输入始终生成相同的 UUID。
命名空间加名称 — 如何连接和散列输入，以及为什么命名空间可以防止不同源之间的冲突
v3 或 v5 UUID 源自三个组件：命名空间 UUID （通常是预定义的）、名称（任何字节字符串）和哈希算法（v3 为 MD5，v5 为 SHA-1）。将命名空间 UUID 的 16 字节与名称的 UTF-8 字节连接起来，对连接进行哈希处理，获取哈希输出的前 16 字节，并将这些字节解释为 UUID，并将版本半字节设置为 3 或 5。命名空间对 ID 空间进行分区：来自 DNS 命名空间的 v5 UUID 永远不会与来自 URL 命名空间的 v5 UUID 发生冲突。 RFC 9562 定义了四个预定义名称空间：按 DNS 名称、按 URL、按 OID 和按 X.500 可分辨名称。组织可以通过生成 v4 UUID 来创建自己的命名空间。
MD5 和 v5 中的 SHA-1 — 为什么这里可以接受弱化哈希，因为 ID 不是安全控制
版本 3 使用 MD5，版本 5 使用 SHA-1，选择可追溯到其规范日期和可用实现。对于基于名称的 UUID，这种区别并不重要，因为哈希函数不是安全边界或加密控制。 UUID 不证明真实性或完整性；它只是将可变长度字符串转换为固定的 128 位值。攻击模型是无关紧要的，因为 UUID 是作为不透明值存储和比较的，而不是作为证据或安全控制。新的实现应该使用 v5 (SHA-1) 而不是 v3 (MD5)，不是出于令人信服的安全原因，而是因为 v5 是现代标准并且广泛可用。
预定义的命名空间 — DNS、URL、OID 和 X.500，以及何时创建自己的命名空间
RFC 9562 指定了四个具有特定字节表示形式的预定义命名空间 UUID：6ba7b810-9dad-11d1-80b4-00c04fd430c8（用于 DNS）、6ba7b811-9dad-11d1-80b4-00c04fd430c8（用于 URL）、 6ba7b812-9dad-11d1-80b4-00c04fd430c8 用于 OID，6ba7b814-9dad-11d1-80b4-00c04fd430c8 用于 X.500 可分辨名称。从 DNS 命名空间派生的 v5 UUID 和名称 www.example.com 将始终相同，并且绝不会与来自 URL 命名空间的 v5 UUID 发生冲突。使用预定义的命名空间可确保互操作性：如果多个团队独立使用 v5 和 DNS 命名空间，他们会为相同的 DNS 名称生成相同的 UUID。选择或创建命名空间是模式设计的一部分。
工作示例 — 从概念上从 URL 命名空间和记录 URL 逐步派生出 v5 UUID
从概念上从 URL 命名空间和名称 https://example.com/api/users/42. 派生出 v5 UUID 命名空间 UUID 作为 16 字节为 6b a7 b8 11 9d ad 11 d1 80 b4 00 c0 4f d4 30 c8。该名称是 UTF-8 字符串 https://example.com/api/users/42, ，它是 30 字节。连接命名空间字节 (16) 和名称字节 (30) 以获得总共 46 字节。计算 SHA-1 哈希值，生成 20 字节哈希值。获取前 16 字节，并将其解释为 UUID，其中版本半字节设置为 5，变量位设置为 RFC 标准。使用相同的输入再次计算会产生相同的结果。大多数开发人员使用他们的语言 UUID 库来计算 v5。
模式被打破的地方 - 当名称更改时、当团队之间的命名空间不一致时以及当输入保密时
基于名称的 UUID 假定名称在系统和导入运行之间稳定且一致。如果同一个外部记录在不同的系统中具有不同的名称，则从每个名称生成 v5 会产生不同的 UUID，并且无法识别同一个人。如果团队之间未就命名空间达成一致（每个团队为实际上相同的源创建自己的命名空间），他们会生成不同的 UUID 并且无法匹配记录。如果输入是敏感数据，则生成 v5 UUID 意味着 UUID 是一个公共的确定性值，任何人只要知道输入就可以查找。当输入更改或命名空间定义不一致时，确定性就会失效。
这不包括 - ToolAcre 生成器从 CSPRNG 中提取，因此基于名称的 ID 需要您语言的 UUID 库
ToolAcre 仅生成 v4 UUID，从浏览器加密安全生成器中提取以实现独立。基于名称的 UUID 派生需要您的语言 UUID 库或计算 SHA-1 并正确格式化结果的实现。这篇文章解释了概念和用例；在任何可以访问标准加密库的语言中，实现 v5 生成都是简单的。 v5 的推导机制很简单；挑战是将其集成到一个系统架构中，其中命名空间稳定，名称一致，并且该方法为您的团队提供了详细的文档记录。开发团队应该记录命名空间的选择。
要点：需要时确定，否则随机 — 使用 v5 进行稳定映射，使用 ToolAcre 生成器处理所有不可猜测的内容
使用 v5 在外部标识符和内部记录之间建立稳定的映射。确定性可防止重复导入，并使跨系统的匹配记录变得简单可靠。不要将基于名称的 UUID 用于需要不可猜测的标识符或需要强保密性和秘密的场景。 ToolAcre 为标识符生成随机 v4 UUID，这些标识符必须独立且独特，不可预测。当您的系统需要将输入映射到固定标识符的确定性 ID 时，您的语言 UUID 库可以计算它们。当您控制输入时，确定性是一个强大的功能。