language-agnostic - UUID 命名空间从何而来？

Question

UUID specification定义了 4 个预定义的命名空间，将其描述为“可能有趣”——除其他外，这意味着“如果其他人在该命名空间中生成了 UUID，您可以验证它们”:

• 6ba7b810-9dad-11d1-80b4-00c04fd430c8 用于 DNS
• 6ba7b811-9dad-11d1-80b4-00c04fd430c8 网址
• 6ba7b812-9dad-11d1-80b4-00c04fd430c8 用于 ISO OID
• 6ba7b814-9dad-11d1-80b4-00c04fd430c8 适用于 X.500 DN

这些是从哪里来的？

具体；

• 如果我要生成自己的命名空间 UUID，我是否需要特别避免任何事情？
• 我知道 UUID 空间有多大，但这对冲突有什么影响吗？
• 为什么他们选择第 4 个八位字节作为一种 UUID“版本号”来增加？
• 我的问题是否意味着我遗漏了有关 UUID 的一些基本知识？

Answer 1

首先，要明确的是，整个讨论仅限于版本 3 和 5 UUID。根据我的(轶事)经验，版本 4(随机)UUID 最常用。

4122的命名空间 UUID 生成算法模糊地开始:

Allocate a UUID to use as a "name space ID"

没有其他提及“命名空间ID”分配，我和python都没有提及。已发现 RFC 4122 中列出的四个空间之外的任何标准化空间。

所以你的第一个问题的答案，

• If I'm generating my own namespace UUID do I need to avoid anything in particular?

您只需避开四个标准命名空间即可。

<小时/>

下一个问题，

• I'm aware how big the UUID space is, but does this have any implication on collisions?

有两个部分:

1. 命名空间内的 UUID 会发生冲突吗？ 4122 的逐字记录:

   The UUIDs generated from two different names in [your] namespace should be different (with very high probability).

2. 您的命名空间 UUID 会与其他命名空间发生冲突吗？我找不到直接的答案，因为没有“ namespace ID”分配的标准，但 section 4.1.1 中的参数似乎相关:

   Interoperability, in any form, with variants other than the one defined here is not guaranteed, and is not likely to be an issue in practice.

<小时/>

• Why have they chosen the 4th octet to increase as a kind of UUID 'version number'?

这有点神秘。幸运的是，我们有一个 UUID 规范，因此我们可以挖掘它们以获得一些见解。

请注意，(0-索引)第 8 个八位字节在所有情况下均以 8 开头，因此我们正在处理 RFC 4122 变体 UUID。唷。

现在检查八位字节 6 的版本:1，我们正在处理基于时间的版本 1 UUID。

这个answer有一个方便的算法，用于从版本 1 UUID 中提取 python 日期时间。应用该算法会产生1998 年 2 月 4 日的时间。我还没有找到这个日期的意义。增加第 3 个八位字节会将最小可编码时间间隔 (100ns) 添加到日期中。

<小时/>

• Do my questions imply that I'm missing something fundamental about UUIDs?

不。关于 UUID 命名空间的讨论很少，因为随机 UUID 非常简单。