UUID 命名空间从何而来？
UUID 规范定义了 4 个预定义命名空间，它描述为“可能有趣” - 意思是“如果其他人在这个命名空间中生成了 UUID，你可以验证它们”：
6ba7b810-9dad-11d1-80b4-00c04fd430c8用于 DNS6ba7b811-9dad-11d1-80b4-00c04fd430c8用于 URL6ba7b812-9dad-11d1-80b4-00c04fd430c8for ISO OID6ba7b814-9dad-11d1-80b4-00c04fd430c8for X.500 DN
这些来自哪里？
具体来说;
- 如果我生成自己的命名空间 UUID，我是否需要特别避免任何事情？
- 我知道 UUID 空间有多大，但这对冲突有什么影响吗？
- 为什么他们选择第 4 个八位字节作为一种 UUID“版本号”来增加？
- 我的问题是否意味着我遗漏了有关 UUID 的一些基本知识？
The UUID specification defines 4 predefined namespaces which it describes as "potentially interesting" - meaning among other things, "if other people have generated UUIDs in this namespace you can verify them":
6ba7b810-9dad-11d1-80b4-00c04fd430c8for DNS6ba7b811-9dad-11d1-80b4-00c04fd430c8for URL6ba7b812-9dad-11d1-80b4-00c04fd430c8for ISO OID6ba7b814-9dad-11d1-80b4-00c04fd430c8for X.500 DN
Where did these come from?
Specifically;
- 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?
- Why have they chosen the 4th octet to increase as a kind of UUID 'version number'?
- Do my questions imply that I'm missing something fundamental about UUIDs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，要明确的是，整个讨论仅限于版本 3 和版本 3。 5 个 UUID。根据我的（轶事）经验，版本 4（随机）UUID 最常用。
4122 的命名空间 UUID 生成算法模糊地开始：
没有其他提及“命名空间 ID”分配，我和 python 已经找到了 RFC 4122 中列出的四个之外的任何标准化空间。
所以第一个问题的答案是，
您只需避开四个标准名称空间即可。
下一个问题，
分为两部分：
命名空间内的 UUID 会发生冲突吗？ 4122 的逐字记录：
<块引用>
从[您的]命名空间中的两个不同名称生成的 UUID 应该不同（概率非常高）。
您的命名空间 UUID 会与其他命名空间发生冲突吗？我找不到直接的答案，因为没有“名称空间 ID”分配的标准，但是 第 4.1.1 节 似乎相关：
<块引用>
任何形式的互操作性，与除此之外的变体
此处定义的内容无法得到保证，并且不太可能成为问题
练习。
这有点神秘。幸运的是，我们有 UUID 规范，因此我们可以挖掘它们以获得一些见解。
请注意，（0-索引）第 8 个八位字节在所有情况下均以
8开头，因此我们正在处理 RFC 4122 变体 UUID。唷。现在检查八位位组 6 的版本：
1，我们正在处理基于时间的版本 1 UUID。这个答案有一个方便的提取Python日期时间的算法从版本 1 UUID 开始。应用该算法会产生1998 年 2 月 4 日的时间。我还没有找到这个日期的意义。递增第 3 个八位字节会将最小可编码时间间隔 (100ns) 添加到日期中。
没有。关于 UUID 命名空间的讨论很少，因为随机 UUID 非常简单。
First, to be clear, this whole discussion is limited to version 3 & 5 UUIDs. In my (anecdotal) experience, version 4 (random) UUIDs are most commonly used.
4122's namespaced UUID generation algorithm ambiguously begins:
There is no other mention of "name space ID" allocation, and neither I nor python have found any standardized spaces beyond the four listed in RFC 4122.
So the answer to your first question,
You only need to avoid the four standard namespaces.
The next question,
Has two parts:
Will UUIDs within your namespace collide? Verbatim from 4122:
Will your namespace UUID collide with other namespaces? I couldn't find a direct answer, since there's no standard for "name space ID" allocation, but the argument in section 4.1.1 seems relevant:
This one's a bit of a mystery. Luckily, we have a spec for UUIDs, so we can mine them for some insight.
Note that the (0-index) 8th octet starts with
8in all cases, so we're dealing with RFC 4122 variant UUIDs. Phew.Now check octet 6 for the version:
1, we're dealing with version 1 time-based UUIDs.This answer has a handy algorithm for extracting python datetimes from version 1 UUIDs. Applying the algorithm yields a time in February 4th, 1998. I have yet to find meaning in this date. Incrementing the 3rd octet adds the smallest encodable time interval (100ns) to the date.
Nope. There is very little discussion of UUID namespaces, since random UUIDs are so easy.
不会。您的命名空间 UUID 可以是通过任何正常方式生成的任何 UUID。因此，例如，您可能希望生成版本 1 或版本 4 UUID 来用作命名空间 UUID。这可以通过 Linux 或 OS X 上的
uuidgen程序来完成。或者您可以轻松生成 版本 1 或 版本 4 UUID 在线的。No. Your namespace UUID can be any UUID generated in any of the normal ways. So, for example, you would probably want to generate a version 1 or version 4 UUID to use as your namespace UUID. This can be done with the
uuidgenprogram on Linux or OS X. Or you can easily generate a version 1 or version 4 UUID online.