命名空间在 uuid5 实现中是强制性的吗?

is namespace mandatory in a uuid5 implementation?

我正在尝试使用 java 测试 uuid5 的各种实现,并使用 python 作为参考实现,因为它是由 corelibs 提供的。然而,看起来 python 的 uuid5 需要一个命名空间 uuid 作为第一个参数传递。 "None" 将不起作用。但是,Java 的 com.fasterxml.uuid.Generators nameBasedGenerator 将接受 "null" 作为命名空间。哪个是正确的?是否有用于 uuid5 生成的 "global" 或 "default" 命名空间的概念。

Is there a concept of a "global" or "default" namespace for uuid5 generation.

UUID RFC 中没有这个概念。名称空间代表您正在使用的名称将从中提取的命名系统。没有通用的命名系统,所以谈论“全球”命名空间是没有意义的。然而,有一些标准的命名空间 UUID。它们记录在 RFC 4122 Appendix C

Python's uuid5 requires a namespace uuid passed as the first parameter. None will not work. However, Java's com.fasterxml.uuid.Generators nameBasedGenerator will accept a null for namespace

com.fasterxml.uuid.Generators API 不是标准 Java API。 UUID 的标准 Java API 是 java.util.UUID 但它不支持类型 5 UUID 生成。

Which is correct?

我看了com.fasterxml.uuid.Generators的代码。如果提供了 null 命名空间,它会跳过将命名空间 UUID 与名称连接的步骤。这不符合 RFC 4122 Section 4.3 中规定的类型 3 / 5 算法,因此从技术上讲它是不正确的。

但是,这种与 RFC 的偏差应该不会破坏任何东西。它不会以比您通常预期的类型 3 / 5 UUID 更高的速度生成 UUID 冲突。我倾向于称其为无害(尽管非标准)扩展。

所以...

Is namespace mandatory in a uuid5 implementation?

RFC 没有说明命名空间是强制性的,或者如果未提供命名空间该怎么办。一般而言,UUID 生成 API,并且这个 API 的行为特别 超出了当前编写的 RFC 的范围