通用唯一識別碼

通用唯一識別碼是用於計算機體系中以識別資訊的一個128位識別符號。UUID按照標準方法生成時，在實際應用中具有唯一性，且不依賴中央機構的註冊和分配。UUID重複的機率接近零，可以忽略不計。因此，所有人都可以自行建立和使用UUID，而且幾乎可以確定其不會與既有的識別碼重複。也因為如此，在不同地方產生的UUID可以使用於同一個資料庫或同一個頻道中，而且幾乎不可能重複。UUID的應用相當普遍，許多計算平臺都提供了對於生成和解析UUID的支援。歷史.1990年代， UUID 原本是用於阿波羅電腦的網路計算系統，後被用於開放軟體基金會的分散式運算環境。分散式運算環境UUID的初始設計基於網路計算系統UUID，其設計受 Domain/OS 中定義和使用的。2005年7月，RFC 4122 為 UUID 註冊了一個 URN 名稱空間，並制定了早期的規範。當 RFC 4122 作為網際網路工程任務組標準釋出時，國際電信聯盟基於先前的標準和 RFC 4122 早期版本標準化了 UUID。標準.UUID 由開放軟體基金會標準化，作為分散式運算環境的一部分。UUID 被紀錄為 ISO/IEC 11578:1996 "Information technology – Open Systems Interconnection – Remote Procedure Call" 和後來的 ITU-T Rec. X.667 | ISO / IEC 9834-8：2005 規範的一部份。網際網路工程任務組公佈了標準 RFC 4122，技術上等同於 ITU-T Rec. X.667 | ISO/IEC 9834-8。格式.在其規範的文字表示中，UUID 的 16 個 8 位位元組表示為 32 個十六進位制數字，由連字元 '-' 分隔成五組顯示，形式為「8-4-4-4-12」總共 36 個字元。例如：codice_1codice_2四位數字 codice_3表示 UUID 版本，數字 codice_4的一至三個最高有效位表示 UUID 變體。在例子中，"M" 是 codice_5 而且 "N" 是 codice_6，這意味著此 UUID 是「變體1」、「版本1」UUID；即基於時間的 DCE/RFC 4122 UUID。規範的 `8-4-4-4-12` 格式字串基於 UUID 的16個位元組的“記錄佈局”：這些欄位對應於「版本1」和「版本2」UUID中的欄位，但是「8-4-4-4-12」的表示適用於所有UUID，即使對於生成方式不同的UUID也是如此。RFC 4122 第 3 節要求以小寫形式生成字元，同時對輸入不區分大小寫，儘管一些常用的實現違反了此規則。Microsoft GUID有時會以大括號表示：codice_8不應將此格式與“Windows登錄檔格式”相混淆，後者指的是大括號內的格式。RFC 4122為UUID定義了統一資源名稱名稱空間。作為URN呈現的UUID如下：codice_9編碼.UUID 的二進位制編碼因系統而異。UUID的變體1是目前世界最常見的UUID，完全以大端序二進位制儲存與傳輸 UUID 。例如，codice_10 編碼為位元組 codice_11。其他系統，特別是 Microsoft 在其 COM/OLE 庫中對 UUID 的字串表示，使用混合端格式，其中 UUID 的前三組是小端序/小尾序。例如，codice_10 編碼為位元組 codice_13。變體.UUID的變體欄位，佔1到3位元。RFC 4122定義了4種變體：目前的UUID規範使用變體1和2。在文字表示上，兩種變體只有代表變體的位元不同。上面的欄位也定義了兩種變體之間的位元組轉換。前三個欄位是無正負號的32和16位元數字，需要進行轉換，而後兩個欄位是由未解釋的位元組組成，不需要進行轉換。這種轉換同樣適用於版本3、4和5，其中的規範欄位與UUID的內容無關。雖然一些重要的GUID名義上是變體2的UUID，例如元件物件模型IUnknown介面的識別碼，但是在微軟Windows軟體中所生成和使用的、被稱為「GUID」的許多識別碼是使用標準的變體1的RFC 4122/DCE 1.1大端序UUID。目前，Microsoft codice_14工具軟體產生變體1的結果。某些微軟文件稱GUID與UUID是同義詞，如同RFC 4122中表示UUID「也被稱作GUID」。這些檔案表明了雖然「GUID」最初指代微軟所使用的其中一種UUID變體，但現在已經成為UUID的另一個名稱，含括變體1和2。版本.對於「變體，並且在特定用例中某些版本可能比其他版本更合適。版本由字串中的 M 指示。版本1的UUID是根據時間和節點ID識別符號和名稱進行雜湊生成確定性的UUID；版本4的UUID則使用隨機性或偽隨機性生成。Nil UUID.Nil UUID是一個特例，值為 ；也就是說，所有位都設定為 0。版本1.版本1的UUID，是根據 60-bit 的時間戳和節點的48-bit MAC地址而生成的。時間戳的是這樣計算的：自公曆首次於天主教會和教皇國以外的地方使用的日期，也就是協調世界時將時間戳視為無符號，把溢位時間推遲至公元5236年。ITU-T Rec. X.667所定義的溢位時間為公元3603年:v。13-bit 或 14-bit「無統一」個「版本1」UUID，每個節點 id 的最大平均速率為每秒 1630 億。與其他 UUID 版本相比，基於來自網絡卡的 MAC 地址的「版本1」和「版本2」UUID，部分依賴於由中央註冊機構釋出的識別符號，即由 IEEE 釋出給網路裝置製造商的 MAC 地址的組織唯一識別符號。基於網絡卡MAC地址的「版本1」和「版本2」UUID 的唯一性還取決於網絡卡製造商正確地為其卡分配唯一的MAC地址，這與其他製造過程一樣容易出錯。此外，某些作業系統允許終端使用者自訂MAC地址，例如OpenWRT。使用節點的網路MAC地址作為節點ID，代表可以透過版本1的UUID逆向找到建立它的計算機。透過在檔案中嵌入UUID，可以實現追蹤到建立或修改這些檔案的計算機。在定位 Melissa 病毒的建立者時就使用了這個隱私漏洞。如果節點沒有或不希望暴露MAC地址，RFC 4122 確實允許「版本1」UUID 中的 MAC 地址被隨機的48位節點ID替換。在這種情況下，RFC要求節點ID的第一個八位位元組的最低有效位應設定為1，這對應於MAC地址中的多播位，設定它是用於區分隨機生成節點ID的UUID和基於來自網絡卡的MAC地址的UUID，網絡卡通常具有單播MAC地址。版本2.RFC 4122 保留了版本2的UUID用於“DCE security”；但並沒有提供任何細節。因此，許多 UUID 實現省略了「版本2」。但是，「版本2」UUID 的規範由 DCE 1.1 身份驗證和安全服務規範提供。「版本2」UUID 類似於「版本1」，除了時鐘序列的最低有效8 bits 被“本地域，其他本地域號用於站點定義。在非 POSIX 系統上，所有本地域號都是站點定義的。在 UUID 中包含 40 位元的域或識別符號一次，略多於7分鐘，而不是版本1中的每100納秒；並且，版本2的時鐘序列僅有6位元，版本1中則有14位元；每7分鐘時鐘週期內，每個節點、域或識別符號只能生成64個唯一的UUID，而版本1的時鐘序列值為16,384個。因此，版本2可能不適合用於以節點、域或識別符號在約7秒以上1次的速率下生成 UUID 的情況。版本3和版本5.「版本3」和「版本5」的 UUID 透過雜湊名稱空間識別符號和名稱生成。版本3使用 MD5 作為雜湊，產生 128 位元。然後將六或七位替換為固定值，即 4 位元的版本號。由於預定了6到7位元，因此只有121或122位元用於維持 UUID 的唯一性。版本5的UUID 和上面類似，但使用 SHA1 而不是 MD5。由於 SHA1 生成 160 位元的摘要，因此在替換版本號和變體號之前會把摘要截斷為 128 位元。版本3和版本5的UUID具有一個特性：相同名稱空間和名稱將對映到同一個UUID；然而，即使已知其中一項，也無法透過暴力搜尋之外的方法從UUID逆向推匯出另外一項。RFC 4122 推薦使用版本5，並建議不要使用任一版本的 UUID 作為安全憑證。版本4.版本4的UUID是隨機生成的。與其他 UUID 一樣，其中4位元用於代表「版本4」，2到3位元代表變體號則為變體1的一半，因為可用的隨機位少一個，變數消耗 3 位元。一些偽隨機數發生器缺少必要的熵來產生足夠的偽隨機數。例如，使用偽隨機數生成器的 WinAPI GUID 生成器已被證明可生成遵循可預測模式的 UUID。 RFC 4122 建議“在各種主機上生成 UUID 的分散式應用程式必須願意依賴所有主機上的隨機數源。如果這不可行，則應使用名稱空間變體。”衝突.當多次生成相同的 UUID 並將其分配給不同的指示物件時，就會發生衝突。對於使用來自網絡卡的唯一MAC地址的標準版本1和2的UUID，只有當實施與標準不同時才可能發生衝突，無論是無意還是故意。與使用MAC地址生成的版本1和版本2相比，使用隨機生成的節點ID的版本1和版本2、基於雜湊的版本3和版本5，以及隨機生成的版本4的UUID，即使實現上沒有問題也可能發生衝突，但可能性很小，通常可以忽略。可以基於對生日問題的分析來精確地計算該機率。例如，如果要有50%的機率至少發生一次衝突，需要生成至少formula_5個版本4的UUID，計算如下：formula_6這個數字相當於每秒產生 10 億個 UUID 持續 85 年。每個 UUID 長度為 16 位元組，這麼多 UUID 的檔案大小約為 45 艾位元組，比目前存在的最大資料庫大很多倍，它們都在數百PB的數量級。若要使發生衝突的機率為"p"，至少必須生成多少個版本4的UUID可由下式近似計算：formula_7因此，在 103 萬億個版本4 UUID 中找到重複的機率是 formula_8。使用.檔案系統.重要用途包括 ext2/ext3/ext4 檔案系統使用者空間工具的實現。Solaris 中 UUID 的一種用途是識別正在執行的作業系統例項，以便在核心崩潰的情況下將故障轉儲資料與故障管理事件配對。分割槽標籤和分割槽UUID都儲存於超區塊中。兩者皆為檔案系統的一部份，而不是分割槽的一部份。例如，ext2-ext4包含UUID，而NTFS或FAT32則沒有。超區塊是檔案系統的一部份，因此被完全包含在分割槽中，因此如果你執行，sda1和sdb1都會擁有相同的標籤和UUID。COM.Microsoft的元件物件模型中使用了幾種GUID ：作為資料庫主鍵.UUID 通常用作資料庫表中的唯一鍵。Microsoft SQL Server 版本4 Transact-SQL 中的 NEWID 函式會返回標準隨機版本4的UUID，而 NEWSEQUENTIALID 函式返回類似於 UUID 的 128 位識別符號，這些 UUID 會依序遞增，直到下次系統重啟。另一方面，儘管名稱如此，但 Oracle Database SYS_GUID 函式不會返回標準 GUID；相反，它根據主機識別符號和程序或執行緒識別符號返回一個16位元組的 128 位 RAW 值，有點類似於 GUID。PostgreSQL 包含一個 UUID 資料型別，並且可以透過使用模組中的函式生成大多數版本的UUID。MySQL 提供了一個 UUID 函式，它生成標準的版本1 UUID。當 UUID 用作主鍵時，版本3、4和5 UUID 的隨機性以及 版本1和2 UUID 內的欄位的排序可能會產生資料庫定位或效能問題。例如，2002年 Jimmy Nilsson 報告說，當用作主鍵的版本4 UUID 被修改為包含基於系統時間的非隨機字尾時，Microsoft SQL Server的效能顯著提高。Nilsson 承認，這種所謂的“COMB”方法使UUID非標準並且更有可能被複制，但 Nilsson 僅要求在應用程式中的唯一性。透過重新排序和編碼版本1和版本2的UUID，將時間戳放在最前面，可以避免插入所造成的效能損失。諸如Laravel這樣的部分網路框架支援「時間戳優先」的UUID，可以將UUID有效儲存於索引資料庫中。這種UUID是版本4格式的COMB UUID，但其中前48位元組成了一個時間戳，就像版本1的UUID一樣。其他基於COMB UUID概念的指定格式包括：