我已經(jīng)在http://www.ietf.org/rfc/rfc4122.txt上閱讀了UUID RFC，并使用pythonuuid模塊進(jìn)行了實(shí)驗(yàn)。為了便于說明，這是從規(guī)范中提起的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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+根據(jù)我對(duì)規(guī)范的閱讀，最小的類型1 UUID應(yīng)該將time_low，time_mid，clk_seq_hi_res，clk_seq_low和node都設(shè)置為全0，并且time_hi_and_version應(yīng)該將bit 15設(shè)置為1。最大的類型1 UUID應(yīng)該具有time_low ，time_mid，clk_seq_hi_res，clk_seq_low和node設(shè)置為全1，time_hi_and_version設(shè)置為全1（第12、13和14位除外）。但是，嘗試在python中生成這些失?。?gt;>> 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我認(rèn)為我沒有正確閱讀規(guī)范，但我很茫然。
1 回答
暮色呼如
TA貢獻(xiàn)1853條經(jīng)驗(yàn) 獲得超9個(gè)贊
問題不在于您的特定值，而是您沒有足夠的值。
您只提供了14個(gè)字節(jié)的數(shù)據(jù)，而不是16個(gè)字節(jié)，這就是它所抱怨的。
UUID根本不檢查類型1 UUID的要求。如果這樣做，它將無法用于其他具有不同要求的UUID類型。
嘗試這個(gè)：
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')
同時(shí)，您顯然還混合了版本和變體，并使字節(jié)序向后退。因此，讓我們從頭開始。
根據(jù)我對(duì)規(guī)范的閱讀，最小的1類UUID…應(yīng)該具有time_low，time_mid，clk_seq_hi_res，clk_seq_low和node設(shè)置為全0
clk_seq_hi_res是的縮寫clock_sequence_hi_and_reserved，在第4.1.2節(jié)中定義為“與變體多路復(fù)用的時(shí)鐘序列的高場”。變體在4.1.1中定義，您需要“本文檔中指定的變體”，它將兩個(gè)最高有效位分別設(shè)置為1和0。因此，此字段不能全為0或全為1。由于這是最高有效位，因此這意味著八位位組8的高半字節(jié)必須為之一(8, 9, a, b)，而不是低位八位字節(jié)必須為之一(1, 5, 9, d)。
，并且time_hi_and_version應(yīng)該將第15位設(shè)置為1。
不，版本號(hào)在4.1.3中描述為時(shí)間戳的最高4位，版本1定義為0-0-0-1。因此，位15應(yīng)該設(shè)置為0，位14和13應(yīng)該設(shè)置為12，位12應(yīng)該設(shè)置為1。這意味著八位位組6的整個(gè)頂部半字節(jié)必須為1，而不是八位位組的下半字節(jié)。
所以：
00000000-0000-1000-8000-000000000000
ffffffff-ffff-1fff-bfff-ffffffffffff
請(qǐng)注意，這些時(shí)間戳所代表的日期有些愚蠢。前者是午夜1582年10月15日，而后者則是在第53世紀(jì)。*所以，任何圖書館做了驗(yàn)證版本1的UUID可能會(huì)拒絕他們。
另外，全0的節(jié)點(diǎn)是全0的全局單播MAC地址，我不確定這是有效的IEEE-802地址。全1的節(jié)點(diǎn)很好，因?yàn)槿绻O(shè)置了多播位，則明確允許您使用隨機(jī)數(shù)。
添加回答
舉報(bào)
0/150
提交
取消