UUID名称空间来自哪里?

Gar*_*eth 41 language-agnostic standards uuid

UUID规范定义了它描述为"潜在的有趣" 4名预定义的命名空间-除其他事项外的意思,"如果其他人在这个命名空间,你可以验证它们已经产生的UUID":

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

这些来自哪里?

特别;

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

hur*_*lad 42

首先,需要明确的是,整个讨论仅限于版本3和5 UUID.在我的(轶事)经验中,最常用的是版本4(随机)UUID.

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

分配UUID以用作"名称空间ID"

没有其他提及"名称空间ID"的分配,我和python都没有找到超出RFC 4122中列出的四个标准空间.

那么第一个问题的答案,

  • 如果我正在生成自己的命名空间UUID,我是否需要特别避免任何事情?

您只需要避免使用四个标准名称空间.


接下来的问题,

  • 我知道UUID空间有多大,但这对碰撞有什么影响吗?

有两个部分:

  1. 命名空间中的UUID会发生冲突吗?从4122逐字:

    在[your]命名空间中由两个不同名称生成的UUID应该是不同的(具有非常高的概率).

  2. 您的命名空间UUID是否会与其他命名空间冲突?我找不到直接答案,因为"名称空间ID"分配没有标准,但4.1.1节中的参数似乎是相关的:

    任何形式的互操作性与此处定义的变体之外的变体不能得到保证,并且在实践中不太可能成为问题.


  • 为什么他们选择第4个八位字节来增加作为一种UUID'版本号'?

这个有点神秘.幸运的是,我们有一个UUID的规范,所以我们可以挖掘它们以获得一些洞察力.

请注意,(0-index)第8个八位位组8在所有情况下都是以所开始的,所以我们正在处理RFC 4122变体 UUID.唷.

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

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


  • 我的问题是否意味着我遗漏了一些关于UUID的基本信息?

不.关于UUID名称空间的讨论很少,因为随机UUID非常简单.

  • 这很好,尤其是对这些命名空间的解构.似乎1998年2月4日对应于UUID草案规范的日期 - http://tools.ietf.org/html/draft-leach-uuids-guids-01 (7认同)
  • 命名空间UUID是版本1。我相信您正确地计算了日期。最后的12个十六进制字符是主机ID,通常由生成UUID的计算机的MAC地址计算得出。使用在线OUI数据库,我们可以说“ 00c04f”的意思是它是在Dell机器上生成的。我个人想知道“ 6ba7b813”发生了什么... :) (2认同)