最小和最大的有效1类UUID是什么？

Question

我已经在http://www.ietf.org/rfc/rfc4122.txt上阅读了UUID RFC，并使用pythonuuid模块进行了实验。为了便于说明，这是从规范中提起的UUID图。    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                          time_low                             |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |       time_mid                |         time_hi_and_version   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |clk_seq_hi_res |  clk_seq_low  |         node (0-1)            |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                         node (2-5)                            |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+根据我对规范的阅读，最小的类型1 UUID应该将time_low，time_mid，clk_seq_hi_res，clk_seq_low和node都设置为全0，并且time_hi_and_version应该将bit 15设置为1。最大的类型1 UUID应该具有time_low ，time_mid，clk_seq_hi_res，clk_seq_low和node设置为全1，time_hi_and_version设置为全1（第12、13和14位除外）。但是，尝试在python中生成这些失败：>>> u = uuid.UUID("{00000000-0000-0000-0001-00000000}")Traceback (most recent call last):  File "<stdin>", line 1, in <module>  File "/usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/uuid.py", line 134, in __init__    raise ValueError('badly formed hexadecimal UUID string')ValueError: badly formed hexadecimal UUID string>>> u = uuid.UUID("{ffffffff-ffff-ffff-fff1-ffffffff}")                                                                                                                                                          Traceback (most recent call last):  File "<stdin>", line 1, in <module>  File "/usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/uuid.py", line 134, in __init__    raise ValueError('badly formed hexadecimal UUID string')ValueError: badly formed hexadecimal UUID string我认为我没有正确阅读规范，但我很茫然。

Answer 1

问题不在于您的特定值，而是您没有足够的值。

您只提供了14个字节的数据，而不是16个字节，这就是它所抱怨的。

UUID根本不检查类型1 UUID的要求。如果这样做，它将无法用于其他具有不同要求的UUID类型。

尝试这个：

In [58]: uuid.UUID("{00000000-0000-0000-0000-000000000000}")

Out[58]: UUID('00000000-0000-0000-0000-000000000000')

In [59]: uuid.UUID('{FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF}')

Out[59]: UUID('ffffffff-ffff-ffff-ffff-ffffffffffff')

同时，您显然还混合了版本和变体，并使字节序向后退。因此，让我们从头开始。

根据我对规范的阅读，最小的1类UUID…应该具有time_low，time_mid，clk_seq_hi_res，clk_seq_low和node设置为全0

clk_seq_hi_res是的缩写clock_sequence_hi_and_reserved，在第4.1.2节中定义为“与变体多路复用的时钟序列的高场”。变体在4.1.1中定义，您需要“本文档中指定的变体”，它将两个最高有效位分别设置为1和0。因此，此字段不能全为0或全为1。由于这是最高有效位，因此这意味着八位位组8的高半字节必须为之一(8, 9, a, b)，而不是低位八位字节必须为之一(1, 5, 9, d)。

，并且time_hi_and_version应该将第15位设置为1。

不，版本号在4.1.3中描述为时间戳的最高4位，版本1定义为0-0-0-1。因此，位15应该设置为0，位14和13应该设置为12，位12应该设置为1。这意味着八位位组6的整个顶部半字节必须为1，而不是八位位组的下半字节。

所以：

00000000-0000-1000-8000-000000000000

ffffffff-ffff-1fff-bfff-ffffffffffff

请注意，这些时间戳所代表的日期有些愚蠢。前者是午夜1582年10月15日，而后者则是在第53世纪。*所以，任何图书馆做了验证版本1的UUID可能会拒绝他们。

另外，全0的节点是全0的全局单播MAC地址，我不确定这是有效的IEEE-802地址。全1的节点很好，因为如果您设置了多播位，则明确允许您使用随机数。