Can you summarize the following document?
        
  UUID最初用於 Apollo 網路計算系統(NCS),後來用於開放軟體基金會(OSF)分散式計算環境(DCE)。DCE UUID的初始設計基於NCS UUID,其設計受 Domain/OS 中定義和使用的(64位)唯一識別符號的啟發,這是一個也由 Apollo Computer 設計的作業系統。後來,Microsoft Windows 平臺採用 DCE 設計作為全域性唯一識別符號(GUID)。 RFC 4122 為 UUID 註冊了一個 URN 名稱空間,並制定了早期的規範。當 <nowiki>RFC 4122</nowiki> 作為 IETF 標準釋出時,ITU 基於先前的標準和 <nowiki>RFC 4122</nowiki> 早期版本標準化了 UUID。

  UUID 由開放軟體基金會(OSF)標準化,作為分散式計算環境(DCE)的一部分。  UUID 被作為 ISO/IEC 11578:1996 "Information technology – Open Systems Interconnection – Remote Procedure Call(RPC)" 中的一部分,最近在 ITU-T Rec. X.667 | ISO / IEC 9834-8:2005 規範中。  網際網路工程任務組(Internet Engineering Task Force,IETF)公佈的標準 <nowiki>RFC 4122</nowiki>,技術上等同於 ITU-T Rec. X.667 | ISO/IEC 9834-8。

  UUID是由一組32位數的16進位制數字所構成,故UUID理論上的總數為16=2,約等於3.4 x 10。也就是說若每納秒(ns)產生1萬億個UUID,要花100億年才會將所有UUID用完。  UUID的標準型式包含32個16進位制數字,以連字號分為五段,形式為 8-4-4-4-12 的32個字元。範例:  UUID亦可刻意重複以表示同類。例如說微軟的COM中,所有元件皆必須實作出IUnknown介面,方法是產生一個代表IUnknown的UUID。無論是程式試圖存取元件中的IUnknown介面,或是實作IUnknown介面的元件,只要IUnknown一被使用,皆會被參考至同一個ID:codice_1。

  在其規範的文字表示中,UUID 的 16 個 8 位位元組表示為 32 個十六進位制(基數16)數字,顯示在由連字元分隔 '-' 的五個組中,"8-4-4-4-12" 總共 36 個字元(32 個字母數字字元和 4 個連字元)。例如:  四位數字 codice_4表示 UUID 版本,數字 codice_5的一至三個最高有效位表示 UUID 變體。在例子中,"M" 是 codice_6 而且 "N" 是 codice_7(codice_8),這意味著此 UUID 是「變體1」、「版本1」UUID;即基於時間的 <nowiki>DCE/RFC 4122 UUID</nowiki>。  規範的 `8-4-4-4-12` 格式字串基於 UUID 的16個位元組的“記錄佈局”: 這些欄位對應於「版本1」和「版本2」基於時間的 UUID 中的欄位,但是相同的 "8-4-4-4-12" 表示用於所有UUID,即使對於構造不同的UUID也是如此。  <nowiki>RFC 4122</nowiki> 第 3 節要求以小寫形式生成字元,同時對輸入不區分大小寫,儘管一些常用的實現違反了此規則。  Microsoft GUID有時用周圍的大括號表示:  不應將此格式與“ Windows登錄檔格式” 混淆,後者指的是花括號內的格式。  <nowiki>RFC 4122</nowiki> 為UUID 定義了統一資源名稱(URN)名稱空間。作為URN呈現的UUID如下:

  UUID 的二進位制編碼因系統而異。許多系統完全以大端序(big-endian)編碼 UUID 。  例如,codice_11 編碼為位元組 codice_12。  其他系統,特別是 Microsoft 在其 COM/OLE 庫中對 UUID 進行編組,使用混合端格式,其中 UUID 的前三組是小端序/小尾序(little-endian),後兩組是 大端序/大尾序(big-endian)。  例如,codice_11 編碼為位元組 codice_14。

  對於「變體(variants)1」和「變體2」,標準中定義了五個版本(versions),並且在特定用例中每個版本可能比其他版本更合適。  版本由 M 字串中指示。  版本1 - UUID 是根據時間和節點 ID(通常是MAC地址)生成;  版本2 - UUID是根據識別符號(通常是組或使用者ID)、時間和節點ID生成;  版本3、版本5 - 確定性UUID 通過雜湊(hashing)名稱空間(namespace)識別符號和名稱生成;  版本4 - UUID 使用隨機性或偽隨機性生成。

  Nil UUID是一個特例,值為 ;也就是說,所有位都設定為 0。

  「版本1」連線“節點” 的 48-bit MAC地址(即生成UUID的計算機),具有60位時間戳,自1582年10月15日午夜起協調世界時(UTC)以來的100納秒間隔數,公曆首次採用的日期。<nowiki>RFC 4122</nowiki>宣告時間值在公元3400左右滾動,取決於所使用的演算法,這意味著 60-bit 時間戳是有符號數量。但是,某些軟體(如libuuid庫)將時間戳視為無符號,將轉存時間設定為 5236 AD。  13-bit 或 14-bit「無統一」(uniquifying)時鐘序列擴充套件了時間戳,以便處理處理器時鐘不能足夠快地前進的情況,或者每個節點有多個處理器和 UUID 生成器的情況。對於每個「版本1」UUID 對應於空間(節點)和時間(間隔和時鐘序列)中的單個點,兩個正確生成的「版本1」UUID 無意中相同的可能性實際上為零。由於時間和時鐘序列總共74位,每個節點 id 可以生成 formula_1(formula_2)或 18 sextillion(大數名詞,千的七次方,十萬億億)個「版本1」UUID,每個節點 id 的最大平均速率為每秒 1630 億。  與其他 UUID 版本相比,基於來自網絡卡的 MAC 地址的「版本1」和「版本2」UUID,部分依賴於由中央序號產生器構釋出的識別符號,即 MAC 地址的組織唯一識別符號(OUI)部分,由 IEEE 釋出給網路裝置製造商。基於網絡卡 MAC地址的「版本1」和「版本2」UUID 的唯一性還取決於網絡卡製造商正確地為其卡分配唯一的 MAC地址,這與其他製造過程一樣容易出錯。  使用節點的網路 MAC 地址作為節點 ID,意味著可以將「版本1」UUID 追溯回建立它的計算機。文件有時可以跟蹤到通過文書處理軟體嵌入到它們中的 UUID 建立或編輯它們的計算機。在找到 Melissa 病毒的建立者時使用了這個隱私漏洞。  <nowiki>RFC 4122</nowiki> 確實允許「版本1」(或2)UUID 中的 MAC 地址被隨機的 48 位節點 id 替換,因為該節點沒有 MAC 地址,或者因為不希望暴露它。在這種情況下,RFC要求節點 id 的第一個八位位元組的最低有效位應設定為 1,這對應於MAC地址中的多播位,並且設定它用於區分隨機生成節點 id 的 UUID 和基於來自網絡卡的 MAC 地址的 UUID,網絡卡通常具有單播 MAC 地址。

  <nowiki>RFC 4122</nowiki> 保留了“DCE security” UUID 的「版本2」;但它沒有提供任何細節。因此,許多 UUID 實現省略了「版本2」。但是,「版本2」UUID 的規範由 DCE 1.1 身份驗證和安全服務規範提供。  「版本2」 UUID 類似於「版本1」,除了時鐘序列的最低有效8 bits 被“本地域(local domain)”號替換,並且時間戳的最低有效32 bits 由在指定本地域內有意義的整數識別符號替換。在 POSIX 系統上,本地域號 0 和 1 分別用於使用者 ID(UIDs)和組 ID(GIDs),其他本地域號用於站點定義。在非 POSIX 系統上,所有本地域號都是站點定義的。  在 UUID 中包含 40 bits 域/識別符號(domain/identifier)的能力需要權衡。一方面,40 bits 允許每個節點 id 有大約1萬億個 域/識別符號 值。另一方面,時鐘值被截斷為 28 個最高有效位,而「版本1」中為60 bits;「版本2」的 UUID 中的時鐘每429.49秒進行一次標記(tick),略多於7分鐘,而不是「版本1」中的每 100 納秒;並且,「版本2」僅 6 bits 時鐘序列,「版本1」中 14 bits;每7分鐘時鐘週期內,每個 節點/域/識別符號(node/domain/identifier)只能生成64個唯一的UUID,而版本1的時鐘序列值為16,384個。 因此,「版本2」可能不適合於以每個 節點/域/識別符號 生成 UUID 的情況,其速率約 7秒以上1次。

  「版本3」和「版本5」的 UUID 被生成雜湊(hashing)一個名稱空間識別符號和一個名稱。「版本3」使用 MD5 作為雜湊演算法,「版本5」使用 SHA1。  名稱空間識別符號本身就是一個 UUID。該規範提供了 UUID 用來表示名稱空間為了統一資源定位符(URLs),完整域名、物件識別符號和 X.500 輕型目錄訪問協議 ;但任何所需的UUID都可以用作名稱空間指示符。  要確定與給定名稱空間和名稱對應的「版本3」UUID,名稱空間的 UUID 將轉換為位元組串,與輸入名稱連線,然後用 MD5 進行雜湊,產生 128 bits。然後將六或七位替換為固定值,即 4-bit 版本(例如“版本3”的 0011),以及 2-bit 或 3-bit UUID「變體(variant)」(例如 10 指示<nowiki>RFC 4122</nowiki> UUID,或 110 指示傳統 Microsoft GUID)。由於預定了6或7 bits,因此只有121 或 122 bits 有助於 UUID 的唯一性。  「版本5」UUID 類似,但使用 SHA1 而不是 MD5。由於 SHA1 生成 160-bit 摘要,因此在替換版本和變體位之前,摘要將截斷為 128-bits。  「版本3」和「版本5」UUID 具有相同名稱空間和名稱,將對映到同一 UUID ;除了暴力搜尋之外,名稱空間和名稱都不能從 UUID 中確定。  <nowiki>RFC 4122</nowiki> 推薦「版本5」(SHA1)而不是「版本3」(MD5),並建議不要使用任一版本的 UUID 作為安全憑證。

  隨機生成「版本4」UUID。與其他 UUID 一樣,4-bit 用於指示「版本4」,2-bit 或 3-bit 用於指示變體(variant)(10 或 110 分別用於 變體 1 和 2)。因此,對於變體1(即大多數 UUID),隨機「版本4」UUID 將具有 6 個預定的變體和版本位,為隨機生成的部分留下122位,「版本4」變體1 UUID 可能共計 formula_3 或formula_4(5.3 undecillion,大數名詞)個。「版本4」變體2 UUID(傳統GUID)的可能有一半,因為可用的隨機位少一個,變數消耗 3 bits。  一些偽隨機數發生器缺少必要的熵來產生足夠的偽隨機數。例如,使用偽隨機數生成器的 WinAPI GUID 生成器已被證明可生成遵循可預測模式的 UUID。 <nowiki>RFC 4122</nowiki> 建議“在各種主機上生成 UUID 的分散式應用程式必須願意依賴所有主機上的隨機數源。如果這不可行,則應使用名稱空間變體。”

  當多次生成相同的 UUID 並將其分配給不同的指示物件時,就會發生衝突。對於使用來自網絡卡的唯一MAC地址的標準 版本1和2 的 UUID,只有當實施與標準不同時,無論是無意還是故意,都可能發生衝突。  與 版本1 和 版本2 相比, UUID 使用隨機生成的節點 ID,基於雜湊的 版本3 和 版本5 的 UUID,以及隨機 版本4 的 UUID,即使沒有實現問題也可能發生衝突,儘管可能性很小,通常可能是忽略。可以基於對生日問題的分析來精確地計算該概率。  例如,至少碰撞一次具有50%的概率,根據 版本4 需要生成的 UUID 的數量是 formula_5,計算如下:  formula_6  這個數字相當於大約 85 年每秒產生 10 億個 UUID,每個 UUID 16 bytes/位元組,包含這麼多 UUID 的檔案,大約 45 艾位元組(EB),比目前存在的最大資料庫大很多倍,它們都在數百PB的數量級。  最小數必須查詢碰撞要的概率來生成 版本4 的 UUID 的 p 由下式近似計算:  formula_7  因此,在 103 萬億 個 版本4 UUID 中找到重複的概率是 formula_8(十億分之一)。

  重要用途包括 ext2/ext3/ext4 檔案系統使用者空間工具(e2fsprogs 使用 util-linux 提供的 libuuid),LUKS 加密分割槽,GNOME,KDE 和 Mac OS X,其中大部分源自 曹子德(Theodore Ts'o)的實現。  Solaris 中 UUID 的一種用途(使用Open Software Foundation實現)是識別正在執行的作業系統例項,以便在核心崩潰的情況下將故障轉儲資料與故障管理事件配對。

  Microsoft的元件物件模型(COM)中使用了幾種GUID :  IID - 介面識別符號;(在系統上註冊的那些儲存在Windows登錄檔中)  CLSID - 類識別符號;(儲存在)  LIBID - 型別庫識別符號;(儲存於)  CATID - 類別識別符號;(它在一個類中的存在將其識別為屬於某些類別類別)

  UUID 通常用作唯一鍵的資料庫表。  Microsoft SQL Server 版本4 中的 NEWID 函式 Transact-SQL 返回標準隨機 版本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”(組合時間-GUID)方法使UUID非標準並且更有可能被複制,但 Nilsson 僅在應用程式中要求唯一性。
482363e9-9191-35a7-8fb0-9a7236d18e86