深度解讀UUID：結構、原理以及生成機制

What 是 UUID

UUID (Universally Unique IDentifier) 通用唯一識別碼，也稱爲 GUID (Globally Unique IDentifier) 全球唯一標識符。

UUID是一個長度爲128位的標誌符，能夠在時間和空間上確保其唯一性。UUID最初應用於Apollo網絡計算系統，隨後在Open Software Foundation（OSF）的分佈式計算環境（DCE）中得到應用。可讓分佈式系統可以不借助中心節點，就可以生成唯一標識，比如唯一的ID進行日誌記錄。

並被微軟Windows平臺採用。
Windows 舉例2個使用場景：

COM組件通過GUID 來定義類標識符（CLSID）、接口標識符（IID）以及其他重要的標識，確保在整個系統中不會發生命名衝突。

Windows註冊表中很多項都使用GUID作爲子鍵名，以便爲特定程序或功能提供一個全球唯一的註冊表路徑。

UUID之所以被廣泛採用，主要原因之一是它們的分配不需要中心管理機構介入。其具有唯一性和持久性，它們非常適合用作統一資源名稱（URN）。UUID能夠無需註冊過程就能生成新的標識符的獨特優點，使得UUID成爲創建成本最低的URN類型之一。

那麼UUID會重複嘛，由於UUID具有固定的大小幷包含時間字段，在特定算法下，隨着時間推移，理論上在大約公元3400年左右會出現值的循環，所以問題不大。

由於UUID是一個128位的長的標誌符，爲了便於閱讀和顯示，通常會將這個大整數轉換成32（不包含連接符）個十六進制字符組成的字符串形式。如下

crypto.randomUUID()
// 4d93f326-3f48-4a43-929d-b6489f4754b5

`${crypto.randomUUID()}`.length 
// 長度：36

`${crypto.randomUUID()}`.replace(/-/g, '').length
// 去掉連接符：32

這128位的組成，以及是怎麼變成32位的十六進制字符的，繼續往下看：

UUID 的結構

UUID看似雜亂無章，其實內有乾坤，慢慢道來。

必須瞭解的

比特（bit）：二進制數字系統中的基本單位。一個比特可以代表二進制中的一個0或1。
位（通常情況下與比特同義）：二進制數系統中的一位，同樣表示0或1。
字節（Byte）：字節是計算機中更常用的單位，用於衡量數據存儲容量和傳輸速率。1字節等於8個比特。

總結起來就是：

1 字節 = 8 位
1 位 = 1 比特

128位轉爲32個十六進制字符，這個十六進制字符是什麼呢，其專業名字爲hexDigit，是UUID中我們肉眼可見的最小單元。

hexDigit

hexDigit ， 十六進制數字字符，是一個長度爲4比特，可以表示0（0b000）到15（0b1111）之間數值。其能轉爲16進制的相對應符號，其取值範圍爲 0-9，a-f, A-F, 即0123456789abcdefABCDEF某一個值。

所以， hexDigit 可以粗暴的理解爲 0123456789abcdefABCDEF某一個值。

 (0b1000).toString(16)     // 8
 (0b1111).toString(16)     // F

此外，還有一個hexOctet， 兩個連續hexDigit組成的序列，佔8個比特，即一個字節。

UUID基本結構

在協議 RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace 的 4.1.2. Layout and Byte Order 有結構圖：

這個圖有點小迷惑，最上面的 0,1,2,3 不是表示位數，就是簡單的表示10位數的值，9之後就是 10， 11， 12等等。

這圖不太好理解，換一張手工畫的圖（UUID 10類型的V4版本）：
10類型和V4版本後續會解釋

128比特，16個字節即 16 hexOctet，就被如下瓜分了。

字段	hexOctet（字節）	位置	備註
time_low	4	0-3	時間戳的低位部分
time_mid	2	4-5	時間戳的中間部分
time_hi_and_version	2	6-7	時間戳高位部分與版本字段，其中12位代表時間戳的高12位，4位則用來標識UUID的版本號
clock_seq_hi_and_reserved	1	8	時鐘序列高位與保留位
clock_seq_low	1	9	時鐘序列低位
node	6	10-15	節點標識符，提供空間唯一性，通常基於MAC地址或隨機數生成，以確保全局範圍內的唯一性

要想完整理解這個 6 部分組成，必然要理解備註中被加粗的幾個概念。
保留位，版本， 時間戳， 時鐘序列 ，節點標誌符

類型(變體) 和保留位

UUID可以分爲四種類型（變體），怎麼識別是哪種類型（變體呢），UUID有對應的Variant字段去標記，可以參見協議的 4.1.1. Variant部分。

variant字段位於UUID的第8個字節 即 clock_seq_hi_and_reserved 部分的第6-7位。

以外所有其他位的含義都是依據variant字段中的比特位設置來解讀的。從這個意義上講，variant字段更準確地說可以被稱作類型字段；然而爲了與歷史文檔兼容，仍沿用“variant”這一術語。

下表列出了variant字段可能的內容，其中字母"x"表示無關緊要或不關心的值：

Msb0（最高有效位0）：此爲最高位。
Msb1：次高位。
Msb2：第三高位。

Msb0	Msb1	Msb2	描述
0	x	x	保留，用於NCS（Network Computing System）向後兼容
1	0	x	此文檔中指定的variant變體
1	1	0	保留，用於微軟公司系統的向後兼容
1	1	1	保留供未來定義

類型（變體）的標誌符可以是 2位也可是3位，本文圍繞的的是 RFC4122: A Universally Unique IDentifier (UUID) URN Namespace 類型（變體），即上面表格的第二行，其第三高位爲 x，表示該值並無意義，所以該版本只需要
10 即可。

10開頭的 hexDigit 十六進制數字字符，其只有四個值。

0b1000   => 8
0b1001   => 9
0b1010   => a
0b1011   => b

用簡單的圖示表示，就是下面y的部分只會是這四個值 8, 9, a, b其中的某個值。
xxxxxxxx-xxxx-xxxx-yxxx-xxxxxxxxxxxx

簡單測一測,

所以呢，一個RFC4122版本的 UUID正宗不正宗，這麼驗證也是一種手段。

版本（子類型）

上面提到了UUID的類型（變體），而這裏版本，可以理解爲某個類型（變體）下的不同子類型。當然本文討論的是變體 10 即RFC4122 下的版本（子類型）。 UUID的類型（變體）有字段標記，當然這裏的版本也有。

即版本號time_hi_and_version 的第12至15位

V4版本如下：

一共有5個版本：

用簡單的圖示表示，就是下面V的部分只會是這五個值 1, 2, 3, 4, 5其中的某個值。
xxxxxxxx-xxxx-V xxx-yxxx-xxxxxxxxxxxx

借用uuid 庫演示一下：

時間戳

先回顧一下兩張圖

第一張是UUID 各部分的組成，time_low ，time_mid， time_hi_and_version 包含了時間戳的不同部分。

第二張是UUID的五個版本，但是隻有 V1 和 V2 提到了時間戳，也確實是這樣，除了V1和V2版本真正用了時間戳，其餘版本通過不同手段生成了數據填充了time_low ，time_mid， time_hi_and_version 這三個部分。

那這個時間戳是開發者們常用的 Date.now() 這個時間戳嘛, 答案當然不是。

這裏的時間戳是一個60位長度的數值。對於UUID版本1和2，它通過協調世界時（UTC）表示，即從1582年10月15日0點0分0秒開始算起的100納秒間隔計數。

比如 2024年1月1日0時0分0秒，這個值時間戳怎麼算呢

const startOfUuidEpoch = new Date('1582-10-15T00:00:00.000Z');
const uuidTimestampFromDate = (date) => {
  // 直接計算給定日期距離UUID紀元開始的毫秒數
  const msSinceUuidEpoch = date.getTime() - startOfUuidEpoch.getTime();

  // 將毫秒轉換爲100納秒的整數倍，  1 毫秒=1000000 納秒
  const uuidTimestampIn100Ns = Math.floor(msSinceUuidEpoch * 10000); // 每毫秒乘以10,000得到100納秒

  return uuidTimestampIn100Ns;
};

// 計算2024年1月1日對應的UUID V1版本時間戳
const targetDate = new Date('2024-01-01T00:00:00.000Z');
const uuidV1Timestamp = uuidTimestampFromDate(targetDate); 
// 139233600000000000

要保存爲60位，並劃分高位(12)，中間(16)，低位三部分(32)

uuidV1Timestamp.toString(2).padStart(60,'0')
// 000111101110101010000011100010110100110011001000000000000000


time-high     time-mid          time-low
000111101110 1010100000111000 10110100110011001000000000000000

在不具備UTC功能但擁有本地時間的系統中，只要在整個系統內保持一致，也可以使用本地時間替代UTC。然而，這種方法並不推薦，因爲僅需要一個時區偏移量即可從本地時間生成UTC時間。

對於UUID版本3或5，時間戳是一個根據4.3 Algorithm for Creating a Name-Based UUID，由名稱構建的60位值， V3和V5 區別是在算法上。

而對於UUID版本4，時間戳則是一個隨機或僞隨機生成的60位值，具體細節參見第4.4 Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers

小結一下，

時間戳是即從1582年10月15日0點0分0秒開始算起的100納秒間隔計數，是一個60位值，被分爲高位，中間，低位三部分填充到UUID中。
只有V1和V2 真正意義上用了時間戳
V3和V5 由名字構建而成的60位值
V4隨機或僞隨機生成的60位值

時鐘序列

時鐘序列（clock sequence）用於幫助避免因系統時間被設置回溯或節點ID發生變化時可能出現的重複標識符。

舉個實例，手動把系統的時間設置爲一個過去的時間，那麼就可能導致生成重複的UUID.

協議考慮到了這點，就增加了時鐘序列，增加一個變數，讓結果不一樣，當然如果序列也是不變的，那麼還是可能重複，所以這個時鐘序列也是會變化的。

如果系統時鐘被設置爲向前的時間點之前，或者可能已經回溯（例如，在系統關機期間），並且UUID生成器無法確定在此期間沒有生成時間戳更大的UUID，則需要更改時鐘序列。若已知先前時鐘序列的值，可以直接遞增；否則應將其設置爲一個隨機或高質量的僞隨機值。

同樣，當節點ID發生變化（比如因爲網絡適配器在不同機器間移動），將時鐘序列設置爲隨機數可以最大限度地降低由於各機器之間微小時間設置差異導致重複UUID的可能性。儘管理論上知道與變更後的節點ID關聯的時鐘序列值後可以直接遞增，但這種情況在實際操作中往往難以實現。

時鐘序列必須在其生命週期內首次初始化爲隨機數，以減少跨系統間的關聯性。這提供了最大程度的保護，防止可能會快速在系統間遷移或切換的節點標識符產生問題。初始值不應與節點標識符相關聯。

同樣的，這個時間序列只在 V1和V2 是真的按照上面的規則或者約定來執行的。

對於UUID版本3或5，時鐘序列是一個由第4.3 Algorithm for Creating a Name-Based UUID節描述的名稱構建的14位值。

而對於UUID版本4，時鐘序列則是一個如第4.4 Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers節所述隨機或僞隨機生成的14位值。

節點標誌符

空間唯一節點標識符，用來確保即便在同一時間生成的UUID也能在特定網絡或物理位置上保持唯一性。

對於UUID V1，這個節點標識符通常基於網絡適配器的MAC地址或者在沒有硬件MAC地址可用時由系統自動生成一個僞隨機數。它的目的是反映生成UUID的設備在網絡或物理空間中的唯一性，即使在相同的時序和時鐘序列條件下，不同的設備也會因爲其獨特的節點標識符而產生不同的UUID。

在UUID V2中，雖然不常用，但節點標識符的概念同樣適用，用於標識系統的唯一性，只不過這裏的“空間”更多地指向組織結構或其他邏輯意義上的空間劃分。

總之，空間唯一節點標識符是爲了保證在分佈式系統環境下，即使時間戳相同的情況下也能生成唯一的UUID，以區分不同物理節點上的事件或資源。

對於UUID版本3或5：節點字段（48位）是根據第4.3節描述的方法，從一個名稱構造而來。
對於UUID版本4：節點字段（同樣是48位）是一個隨機或僞隨機生成的值。

小結

從V1和V2版本來看， UUID最後是想通過時間和空間上兩層手段保證其唯一性：

時間：時間戳 + 時鐘時序
空間：節點標誌符（比如MAC地址）

同時考慮了類型（變體）和版本（子類型），即下面這些組信息組成了UUID

時間戳
時鐘序列
節點標誌符
保留位：即類型（變體）信息
版本：V1到V5

因爲保留位和版本信息本身是固定的，是可以從最後的32位16進制字符是可以直接或者間接看到的。

再回顧這張圖，是不是比較清晰了

UUID 的生成

協議中有具體描述V1, V3和V5, 以及V4的基本流程或者約束。

v4

瀏覽器和nodejs內置的了V4的生成函數，而且其生成規則相對簡單。
對應着協議 4.4. Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers。

版本4的UUID旨在通過真正的隨機數或僞隨機數生成UUID。其生成算法相對簡單，主要依賴於隨機性：

生成算法步驟如下：

在UUID結構中的clock_seq_hi_and_reserved部分，將最高兩位有效位（即第6位和第7位）分別設置爲0和1。
在UUID結構中的time_hi_and_version字段，將最高四位有效位（即第12位至第15位）設置爲來自第 4.1.3節的4位版本號，對於版本4 UUID，這個版本號是固定的0100。
將除了以上已設定的位之外的所有其他位設置爲隨機（或僞隨機）選取的值。

不好理解，就看這張圖：

關於隨機性安全要求，引用了BCP 106標準文檔，即 RFC 4086。RFC 4086是一份由IETF制定的最佳當前實踐（Best Current Practice, BCP）文檔，其標題爲“Security Requirements for Randomness”，該文檔詳細闡述了在實現安全協議與系統時所需的隨機數生成器的要求和特性，確保生成的隨機數具有足夠的不可預測性和熵，能滿足各類安全應用，包括但不限於密碼學應用中的隨機性需求。

總之，生成版本4 UUID的過程中，首先對特定字段的幾位進行固定設置以標明版本和時鐘序列特徵，然後其餘所有位均通過隨機或僞隨機過程填充數值，以此確保生成的UUID具備全球唯一性和較強的隨機性。

至於v2怎麼生成，協議貌似沒有提到， v1 ， v3 和 v5均有提到，這邊就直接翻譯過來，有興趣的可以看看大致邏輯。不敢興趣的直接跳到後續章節

V1

對應這協議 4.2.2. Generation Details ,按照以下步驟生成的：

確定時間戳和時鐘序列：遵循第 4.2.1 節描述的方法，獲取基於 UTC 的時間戳以及用於 UUID 的時鐘序列。
處理時間戳和時鐘序列：將時間戳視爲一個 60 位無符號整數，時鐘序列視爲一個 14 位無符號整數，並按順序編號每個字段中的位，最低有效位從0開始計數。
設置時間低位字段（time_low field）：將其設置爲時間戳的最低有效 32 位（位 0 到 31），保持相同的位權重順序。
設置時間中間字段（time_mid field）：將其設置爲時間戳中的位 32 到 47，同樣保持位權重順序一致。
設置時間高位及版本字段（time_hi_and_version field）的低 12 位（位 0 到 11）：將其設置爲時間戳的位 48 到 59，保持位權重順序一致。
設置時間高位及版本字段的高 4 位：將這 4 位（位 12 到 15）設置爲對應於所創建 UUID 版本的 4 位版本號。
設置時鐘序列低位字段（clock_seq_low field）：將其設置爲時鐘序列的最低有效 8 位（位 0 到 7），同樣保持位權重順序一致。
設置時鐘序列高位及保留字段的低 6 位（clock_seq_hi_and_reserved field 的位 0 到 5）：將其設置爲時鐘序列的最高有效 6 位（位 8 到 13），保持相同位權重順序。
設置時鐘序列高位及保留字段的高 2 位：將這 2 位（位 6 和 7）分別設置爲 0 和 1，以滿足版本 1 UUID 的標準格式要求。
設置節點字段（node field）：將其設置爲 48 位的 IEEE MAC 地址，地址中的每一位都保持原有的位權重順序

V3 和 V5

對應協議的 4.3. Algorithm for Creating a Name-Based UUID

版本3或5的UUID設計用於從特定命名空間(name space) 內的且在該命名空間內唯一的名字(names) 生成UUID。這裏的名字(names)和命名空間(name space)的概念應該廣泛理解，不僅限於文本名稱。例如，一些命名空間包括域名系統（DNS）、統一資源定位符（URLs）、ISO對象標識符（OIDs）、X.500區別名（DNs）以及編程語言中的保留字等。在這些命名空間內分配名稱和確保其唯一性的具體機制或規則不在本規範的討論範圍內。

對於這類UUID的要求如下：

在同一命名空間內，使用相同名稱在不同時間生成的UUID必須完全相同。
在同一命名空間內，使用兩個不同名稱生成的UUID應當是不同的（概率極高）。
在兩個不同命名空間內，使用相同名稱生成的UUID也應當是不同的（概率極高）。
如果兩個由名稱生成的UUID相同，則它們幾乎肯定是由同一命名空間內的相同名稱生成的。

生成基於名稱和命名空間的UUID的具體算法步驟如下：

爲給定命名空間內所有由名稱生成的UUID分配一個作爲“命名空間ID”的UUID；參見附錄C中預定義的一些值。
選擇MD5 [4] 或SHA-1 [8] 其中的一種哈希算法；如果不考慮向後兼容性，建議優先使用SHA-1。
將名稱轉換爲其命名空間規定的標準化字節序列形式，並將命名空間ID以網絡字節序排列。
計算命名空間ID與名稱連接後的哈希值。
將哈希值的前四個八位組（octets 0-3）賦給時間低位字段（time_low field）的前四個八位組。
將哈希值的第五和第六個八位組賦給時間中間字段（time_mid field）的前兩個八位組。
將哈希值的第七和第八個八位組賦給時間高位及版本字段（time_hi_and_version field）的前兩個八位組。
將時間高位及版本字段的四位最顯著位（bit 12 至 15）設置爲第4.1.3節中指定的相應4位版本號。
將哈希值的第八個八位組賦給時鐘序列高位及保留字段（clock_seq_hi_and_reserved field）。
將時鐘序列高位及保留字段的兩位最顯著位（bit 6 和 7）分別設置爲0和1。
將哈希值的第九個八位組賦給時鐘序列低位字段（clock_seq_low field）。
將哈希值的第十至第十五個八位組賦給節點字段（node field）的前六個八位組。
最後，將生成的UUID轉換成本地字節序

獲取 UUID V4

這裏就只介紹V4版本，因爲V4是基於隨機或者僞隨機來實現的，只要保證 保留位 和 版本號 的固定，其他的隨機生成就好。

正則 + Math.random

利用Math.random() 方法生成隨機數。

function uuidv4() {
  return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
    var r = (Math.random() * 16 | 0), v = c == 'x' ? r : (r & 0b0011 | 0b1000);
    return v.toString(16);
  });
}

先固定好格式，執行replace，整體代碼不難，唯一需要提一下的是 (r & 0b0011 | 0b1000) 操作，這裏的作用就是設置保留位的值10

r & 0b0011               // 高位，即2,3位 變爲 00
r & 0b0011 | 0b1000      // 高位，即2,3位 變爲 10

舉個例子, 用9爲例，其二進制 0b1001 &

0b1001 & 0b0011   => 0b0011
0b0011 | 0b1000   => 0b1011

`crypto.randomUUID`

現代瀏覽器也內置 Crypto: randomUUID() method ， nodejs 15.6.0 版本以上就內置了crypto.randomUUID([options])

crypto.randomUUID()
// 4d93f326-3f48-4a43-929d-b6489f4754b5

URL.createObjectURL

function uuid() { 
    const url = URL.createObjectURL(new Blob([])); 
    // const uuid = url.split("/").pop(); 
    const uid = url.substring(url.lastIndexOf('/')+ 1); 
    URL.revokeObjectURL(url); 
    return uid; 
}
 uuid()
// blob:http://localhost:3000/ff46f828-1570-4cc9-87af-3d600db71304

上面方式產生的都是 v4版本，如果v4版本滿足需求，就沒有必要去引入第三方庫了。

你是否真的需要UUID

在前端，有序後需要給數據添加一個id作爲組件的key，這時候理大多數情況是不需要UUID, 也許下面的函數就滿足了你的需求。

let id = 0;
function getId () {
    return id++;
}

後起之秀 NanoID

npm網站， NanoID是這麼自我介紹的：

Nano ID 是一個精巧高效的 JavaScript 庫，用於生成短小、唯一且適合放在 URL 中的標識符字符串。這個工具提供了幾個關鍵特性：

體積小巧：Nano ID 的最小化和壓縮版本非常緊湊，大小僅爲 116 字節。
安全性：該庫使用硬件隨機數生成器來確保生成的 ID 具有高安全性，可以在集羣環境中安全使用。
短小 ID：相較於 UUID（通常包含 A-Z、a-z、0-9 以及 - 符號，共 36 個字符），Nano ID 使用了更大的字符集（包括 A-Za-z0-9_-），從而將 ID 的長度從 36 個符號減少到了 21 個，更便於在有限空間中使用。
可移植性：Nano ID 已被移植到超過 20 種編程語言中，具有良好的跨平臺適用性。

從最新的一週的下載量來對比，首先都是絕對的熱門庫，其次NanoID勢頭很盛。

借用阿通給的對比文案：

Nano ID 和 UUID（Universally Unique Identifier）都是用於生成唯一標識符的機制，但它們之間存在一些關鍵差異：

長度與格式：
- UUID：標準UUID由32個十六進制數字組成，分爲5組，每組之間用短橫線-分隔，例如 xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx，總長度爲36個字符（包括連字符）。
- Nano ID：Nano ID 可配置長度，但默認生成的是較短的字符串，通常包含21個字符，並且可以自定義字符集（默認爲 A-Za-z0-9_-）。
唯一性保證：
- UUID：基於時間戳、MAC地址（對於v1 UUID）、隨機數（對於v4 UUID）等多種因素生成，理論上全球範圍內幾乎不可能重複。
- Nano ID：雖然也致力於生成唯一的ID，但由於其較短的長度，在沒有額外存儲或算法保證的情況下，唯一性風險相對較大。不過，通過增大字符集和適當增加ID長度，Nano ID也能實現很高的唯一性概率。
應用場景：
- UUID：廣泛應用於數據庫鍵、資源標識符、網絡協議等需要全局唯一性的場景，尤其在網絡間不同系統間的交互中常見。
- Nano ID：更適合於對ID長度要求嚴格的場合，如URL友好、前端顯示或者存儲空間有限的情況。
性能與存儲成本：
- UUID：由於較長的字符串長度，存儲和傳輸時可能會佔用更多空間。
- Nano ID：因其短小，Nano ID在存儲和帶寬消耗上更有優勢。
安全性：
- UUID v4 是基於強隨機性生成的，因此安全性較高，不易被預測。
- Nano ID 也可以使用安全的隨機源生成，同樣能夠達到較高的安全性，但在默認設置下，考慮到生成長度和字符集的選擇，如果不在生成邏輯上做特殊處理以增加熵，其安全性可能不及UUID。

綜上所述，選擇Nano ID還是UUID取決於具體的應用需求，如果重視存儲效率和簡潔性，同時能接受合理的唯一性保證策略，則Nano ID可能更爲合適；而在需要絕對唯一性和不考慮存儲效率的場景下，UUID往往是更好的選擇。

寫在最後

不忘初衷，有所得，而不爲所累，如果你覺得不錯，你的一讚一評就是我前行的最大動力。

微信公衆號：成長的程序世界，關注之後，海量電子書，打包拿走不送。

或者添加我的微信 dirge-cloud，一起學習。

引用

RFC4122: A Universally Unique IDentifier (UUID) URN Namespace
UUID那些事