開發者工具 · UUID 產生器
從 Apollo NCS 到 RFC 9562：UUID 的簡史
· 背景
uuid 密碼學 瀏覽器 API
奇怪的 8-4-4-4-12 版面配置和 128 位元大小繼承自 1980 年代的分散式運算。這篇文章透過 DCE、Microsoft 的 GUID 和兩個 IETF 標準追蹤來自 Apollo 網路計算系統的 UUID。
為什麼是 128 位元以及那些連字號？ ——每個新人都會提出的問題和歷史的答案
8-4-4-4-12 連字符格式和 UUID 的 128 位大小是歷史學家立即質疑的設計選擇。為什麼不使用 96 位元來簡化數學運算？為什麼要採用特定的分段佈局？為什麼要使用連字號的 base-16 而不是 base-64 或更簡單的編碼？答案在於 20 世紀 80 年代初期的阿波羅網路運算系統，這是一個分散式運算平台，它面臨著一個真正的問題：網路中的系統需要在沒有中央權威的情況下分配唯一標識符，並這些標識符必須以壓倒性的機率在全球範圍內唯一。 Apollo NCS 透過將時間戳記、網路位址和時鐘序列組合成 128 位元標識符來解決這個問題，該標識符可以由任何機器獨立產生。
Apollo 網路運算系統 — 20 世紀 80 年代根據時間和網路位址建立的唯一識別碼的起源
目前的標準記錄了從 Apollo NCS 到 OSF 分散式運算環境以及後來的 Microsoft 平台的沿襲。這段歷史解釋了為什麼現代系統共享可識別的 128 位元系列，同時保留舊版面的變體標記。它沒有建立絕對的唯一性保證：每個版本都有自己的產生規則和故障模式。持久的成就是無需中央註冊服務的互通性。瀏覽器、資料庫和作業系統可以交換相同的規範十六進位形式，檢查其變體和版本欄位，並確定生產配方是否適合接收系統的需求。
OSF DCE 和變體欄位 — 分散式運算環境如何形式化佈局並新增變體位
此佈局透過從設計一開始就嵌入的版本和變體欄位來適應多種產生策略。基於時間的產生、隨機產生和基於名稱的產生都可以共存於同一標識符空間。現代應用程式與 20 世紀 80 年代的 NCS 有著不同的要求——資料庫需要可排序的金鑰、雲端系統需要隱私、分散式系統需要防碰撞——但相同的 128 位元結構仍然可以滿足它們。在 2024 的 RFC 9562 中新增的版本 6 和 7 證明原始設計者在不破壞向後相容性的情況下為未來的演進留下了空間。
Microsoft 的 GUID — COM、註冊表以及至今仍存在的大括號和大寫樣式
Apollo 網路運算系統是 20 世紀 80 年代在 Apollo 電腦工作站上執行的分散式運算平台。它依賴遠端過程呼叫、資料複製和命名服務的全域唯一識別碼。網路中的節點無法協調 ID 分配，因為如果網路可能分區或斷開連接，您將無法聯繫中央伺服器。因此，Apollo 設計者建立了 128 位元格式，結合了時間戳記 60 位元、通常源自網路卡 MAC 位址 48 位元的節點識別碼以及用於處理時脈變更的時脈序列 14 位元。這種方法讓節點透過組合時間、時鐘序列和節點欄位來獨立產生標識符；它的行為仍然取決於時鐘和節點選擇。
RFC 4122 (2005) — 定義版本 1 到 5 和 URN 命名空間的 IETF 標準，與 ITU-T X.667 保持一致
當 OSF 後來在 1992 年左右為其分散式運算環境標準化時，他們保留了相同的佈局並添加了變體欄位來區分不同的 UUID 類型。該設計已在生產系統中得到驗證。 IETF 於 2005 年對 RFC 4122 進行了標準化，距 Apollo NCS 近二十年，距 DCE 標準化約十三年。 RFC 4122 編碼版本 1 至 5：版本 1 用於基於時間的產生，版本 3 用於基於名稱的 MD5，版本 4 用於隨機，版本 5 用於基於名稱的 SHA-1。該標準非常穩定並被廣泛採用，因為它在 Microsoft Windows、DNS 基礎架構和分散式系統中已經無所不在。到 RFC 4122 發佈時，UUID 已經深深嵌入基礎設施中，以至於標準化幾乎變成了學術性的事情。
RFC 9562 (2024) — 此修訂版廢棄了 RFC 4122，新增了版本 6、7 和 8，並寫下了有關隨機性的現代建議
在 2024 中，IETF 發布了 RFC 9562，它廢棄了 RFC 4122 並添加了版本 6、7 和 8。版本 6 將版本 1 的時間欄位重新排序，以獲得更好的 B 樹局部性和可排序性。版本 7 使用現代且熟悉的 Unix 時間戳，而不是基於 1582 的計數，提高可排序性並滿足現代資料庫要求。版本 8 為自訂實作和實驗性 UUID 設計保留空間。新版本解決了 UUID 部署四十年來出現的問題：隨機密鑰的資料庫效能不佳、版本 1 的隱私洩漏以及雲端系統中對可排序標識符的需求。然而，核心 128 位元結構、變體和版本欄位以及整體佈局保持不變。
這不包括什麼 - 每個版本的實現細節，都有自己的帖子
從 20 世紀 90 年代開始，Microsoft 在組件物件模型中採用 UUID 作為 GUID 全球唯一標識符，將它們深深嵌入 Windows 系統中。 GUID 出現在登錄、COM 介面和 ActiveDirectory 基礎架構中。 Microsoft 增加了一個細微的變化：他們以小端位元組順序儲存某些元件的 GUID，這與網路位元組順序標準不同。這種怪癖在某些 Windows API 中仍然存在：如果從 Windows 匯出 GUID 並將其匯入 Unix 系統，位元組順序問題可能會導致明顯的不匹配。但格式本身是一樣的，混亂只是標準中的一個腳註，並不是根本的區別。大括號和大寫樣式 {3FA85F64-5717-4562-B3FC-2C963F66AFA6} 來自 Windows 約定；其他系統偏好小寫字母和不帶大括號的連字號。
要点：四十年的設計仍然有效 - ToolAcre 產生器產生隨机（版本 4）UUID，RFC 9562 仍然為不需要排序的情况定义這些 UUID
可行的時間表顯示了該設計的長久性和穩定性：20 世紀 80 年代 Apollo NCS 發明了這一概念；1992 OSF 的DCE標準化佈局；2000年代 微軟將其嵌入Windows；2005 IETF 發布 RFC 4122；2024 年 IETF 發布帶有現代版本的 RFC 9562。這是計算領域最長的標準化工作之一，不是因為爭議，而是因為最初的設計是如此強大和適應性強。它適應了架構變革的浪潮——從分散式 NFS 系統到雲端資料庫，從 Windows COM 到行動設備，從 20 世紀 80 年代的 64 位元機器到現代系統，而無需進行根本性的重新設計。實際影響是 UUID 無所不在且穩定；當您使用 ToolAcre 產生器產生 UUID 時，您將產生一個標識符，其格式建立於 20 世紀 80 年代，於 2005 年實現國際標準化，並於 2024 年進行維護，具有持久的相關性。