UUID 產生器

簡介

Toollect UUID 產生器是一款基於瀏覽器的工具，可產生所有八種標準版本的通用唯一識別碼（UUID，也稱為 GUID）——v1 至 v8。無論你需要隨機識別碼用於網頁表單、時間排序鍵用於資料庫記錄、確定性命名空間 ID 用於分散式系統，還是自訂格式 UUID 用於舊版整合，此工具都能完整涵蓋，無需安裝任何軟體或伺服器端處理。

UUID 是軟體工程中最廣泛採用的識別碼標準之一，應用範圍從資料庫主鍵、API 資源識別碼到分散式追蹤和會話權杖。Toollect UUID 產生器將所有 UUID 版本整合到單一介面，讓你選擇適合的變體並一鍵即時產生。

所有產生完全在瀏覽器中使用 Web Crypto API 執行。無資料透過網路傳輸，不設定 Cookie，不記錄任何識別碼。工具在初始頁面載入後可離線運作，並相容所有現代瀏覽器和裝置。

使用場景

不同的 UUID 版本服務於不同的架構需求。選擇正確的版本取決於你對排序、確定性、隱私性和系統協調的要求。

資料庫主鍵

UUID 消除了在分散式資料庫實例間產生主鍵時對中央序號的需求。UUID v4 是最簡單的即選方案，但 UUID v6 和 v7 提供時間排序，可顯著減少 PostgreSQL 和 MySQL 等資料庫中 B-tree 索引的碎片化。對於需要全域唯一性和快速寫入效能的系統，v7 已成為現代推薦選擇。

分散式系統識別碼

微服務和分散式系統通常在不同節點上獨立產生識別碼。UUID v1 包含節點識別碼（衍生自 MAC 位址）和時序，使每個產生節點的 ID 無需協調即內建唯一性。UUID v4 和 v7 因其簡單性在此場景也很受歡迎。

確定性名稱型 ID

當相同輸入應始終產生相同 UUID 時——例如從使用者電子郵件、資源 URL 或命名空間限定名稱產生穩定識別碼——UUID v3（MD5 基礎）和 v5（SHA-1 基礎）提供確定性。這適用於內容可定址儲存、事件溯源中的實體識別，以及在遷移舊版資料時不變更識別碼。

API 資源識別碼

在 API URL 中暴露自動遞增整數會洩漏資源數量和排序資訊。UUID 提供不透明識別碼，不透露系統內部資訊。UUID v4 是 REST API 資源路徑最常見的選擇。工具的大寫和無連字號格式選項讓你輕鬆將 UUID 調整為不同的 URL 和格式慣例。

自訂與舊版系統

UUID v2（DCE 安全）為作業系統層級的安全上下文加入本機使用者與群組識別碼。UUID v8 允許自訂欄位佈局，適用於需要在維持標準 UUID 格式的同時嵌入特定資料位元的系統。這些版本屬小眾但對特定整合場景很有價值。

運作原理

UUID 產生器完全在用戶端運作。當你選擇版本並點擊產生時，工具會使用 JavaScript 和瀏覽器的 Web Crypto API 呼叫適當的演算法。

對於隨機型 UUID（v4），工具呼叫 crypto.getRandomValues() 產生加密安全的隨機位元組，然後將其格式化為標準 UUID 佈局，並設定正確的版本和變體位元。對於時間型 UUID（v1、v2、v6、v7），工具從系統時鐘讀取目前時間戳記，並與隨機時序和節點位元組結合。對於名稱型 UUID（v3、v5），工具使用 MD5 或 SHA-1 經由 SubtleCrypto API 將命名空間和名稱一起雜湊，然後提取 128 位元到標準 UUID 格式。

UUID 格式

UUID 是一個 128 位元的值，以 36 個字元的字串顯示，格式為 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx，其中每個 x 是一個十六進位數字。128 位元結構化為以下欄位：

版本 nibble（位元 48-51，第三組的最高半位元組）標示產生該 UUID 的演算法：0001（v1）、0010（v2）、0011（v3）、0100（v4）、0101（v5）、0110（v6）、0111（v7）、1000（v8）。這就是在標準 UUID v4 550e8400-e29b-41d4-a716-446655440000 中看到的 4。

變體位元（位元 64-65，第四組第一個位元組的兩個最高位元）標示 UUID 變體。RFC 9562 指定變體 10xxxxxx（位元 64-65 = 10），這意味著第四組的第一個字元總是 8、9、a 或 b。

二進位佈局範例

UUID 的 128 位元結構最好透過視覺化方式理解。以具體的 UUID v4 550e8400-e29b-41d4-a716-446655440000 為例，查看各群組和欄位的位元對應：

群組:      1          2          3          4          5
十六進位: 550e8400    e29b       41d4       a716       446655440000
二進位:  [32 bits]   [16 bits]   [16 bits]  [16 bits]  [48 bits]

版本 nibble（群組 3，高半位元組）:
  550e8400-e29b-4  1d4-a716-446655440000
                  ^
                  version = 0100 (v4)

變體位元（群組 4，高位元組）:
  550e8400-e29b-41d4-  a  716-446655440000
                       ^
                       variant = 10xxxxxx

群組 3-4 的完整二進位分解:

  group 3 (16 bits)      group 4 start (8 bits)
  0100 0001 1101 0100    1010 0111
  └─┘                    └─┘
  ver=0100 (v4)          variant | clock_seq_hi
                         10

對於 UUID v7，前 48 位元編碼 Unix 毫秒時間戳記:

  018f3a6e-1a2b-  7  bcd-8a1b-2c3d4e5f6789
                  ^
                  version = 0111 (v7)

  groups 1-2: 48-bit Unix ms timestamp
  0000 0001 1000 1111 0011 1010 0110 1110 0001 1010 0010 1011
  group 3 high nibble:
  0111  = version 7

第四組的高位元組（上例中的 a）包含變體位元。由於變體為 10，此位元組範圍始終在 1000 0000（0x80）到 1011 1111（0xBF）之間，對應於十六進位的第四組第一個字元 8、9、a 或 b。

UUID 版本說明

下表總結了八個標準 UUID 版本：

UUID v1 — 時間型

UUID v1 結合 60 位元時間戳記（自 1582 年 10 月 15 日起的 100 奈秒間隔）、14 位元時序（用於時鐘回撥偵測）和 48 位元節點識別碼（傳統上衍生自 MAC 位址）。這讓每個產生節點都有唯一的識別碼空間，無需協調。

時間戳記的低、中、高位分別配置在 UUID 的前三個群組中。這種非順序佈局意味著 v1 UUID 可按時間排序，但不具有資料庫友善的單調遞增順序——v6 和 v7 解決了這個問題。

UUID v2 — DCE 安全

UUID v2 沿用 v1 的時間戳記和時序佈局，但將 48 位元節點欄位替換為 32 位元 POSIX 使用者 ID（UID）或群組 ID（GID）和 6 位元本機網域識別碼。節點欄位的其餘 10 位元和時序的 2 位元被重新用於本機網域及其結構：

UUID v2 規範來自 DCE 1.1：遠端程序呼叫標準，而非核心 RFC 9562 UUID 規範。除舊版 DCE 環境外極少使用，大多數現代 UUID 產生器若非省略此版本，即是僅為完整性而包含。若你正在建立新系統，請改用 v4、v7 或 v5。

UUID v3 — MD5 名稱型

UUID v3 從命名空間 UUID 和名稱字串產生確定性 UUID。其過程串聯命名空間和名稱位元組，計算 MD5 雜湊，取前 128 位元作為 UUID。相同的命名空間和名稱始終產生相同的 v3 UUID，適合內容定址和穩定識別碼。

有關兩種名稱型版本的比較，請參閱下方的 UUID v3 與 v5 一節。

UUID v4 — 隨機

UUID v4 使用 122 個隨機產生的位元加上 6 個固定位元（4 個版本 nibble，2 個變體位元）。這是最廣泛使用的 UUID 版本，大多數程式語言標準函式庫都直接支援。Toollect UUID 產生器使用 crypto.getRandomValues() 確保加密安全的隨機性，使輸出適合用於安全敏感的情境，如會話權杖。

在一千億個產生的 v4 UUID 中發生一次碰撞的機率約為 5.3 × 10²¹ 分之 1——在實務上微不足道。

UUID v5 — SHA-1 名稱型

UUID v5 是 v3 的對應版本，使用 SHA-1 而非 MD5 作為底層雜湊。它提供相同的確定性保證（相同命名空間 + 名稱 = 相同 UUID），並使用抗碰撞性更強的雜湊演算法。對於需要名稱型 UUID 的新系統，RFC 9562 建議使用 v5 而非 v3。

詳細比較請參閱下方的 UUID v3 與 v5 一節。

UUID v6 — 重排時間型

UUID v6 重新排列 v1 時間戳記，將時間戳記的最高有效位元放在最前面。這使得 v6 UUID 在按字典序排序時是單調遞增的，不像 v1 那樣時間戳記分散在不相鄰的欄位中。UUID v6 是在需要時間排序的資料庫索引或排序儲存時 v1 的現代替代方案。

UUID v7 — Unix 時間戳記 + 隨機

UUID v7 使用 48 位元 Unix 毫秒時間戳記，後接 74 個隨機位元。時間戳記佔據最高有效位元，使 v7 UUID 可按建立時間排序——對於 B-tree 索引效能至關重要的資料庫主鍵而言是理想選擇。UUID v7 比 v1 或 v6 更簡單，因為它不需要 MAC 位址、時序或 100 奈秒紀元轉換。

對於需要時間排序 UUID 的新系統，v7 通常是最佳選擇：它提供毫秒精度的排序、廣泛的隨機性和直接的實作。

UUID v8 — 自訂

UUID v8 保留版本 8 的識別碼空間，供實驗性或專有 UUID 格式使用。唯一固定的位元是位元 48-51 的 4 位元版本 nibble（1000）和位元 64-65 的 2 位元變體（10）——其餘 122 個位元可自由用於任何自訂欄位佈局。

v8 的常見用途包括嵌入公司特定前綴、結合截斷時間戳記與序號計數器，或將舊版識別碼編碼為 UUID 格式，同時維持標準格式相容性。例如，系統可能將前 32 位元分配為租戶 ID、接下來 32 位元為毫秒時間戳記、其餘 64 位元為隨機後綴——全部在標準 UUID 解析器可直接讀取的格式內。

v8 格式未向 IANA 註冊，也不保證跨系統互通性。這是一個私有用途空間，適用於標準 UUID 版本不符合所需資料佈局的情況。

UUID v3 與 v5 比較

UUID v3 和 v5 都從命名空間 UUID 和名稱產生確定性識別碼，但它們的雜湊演算法不同：

Toollect UUID 產生器包含 RFC 9562 定義的四個預定義標準命名空間：DNS（6ba7b810-9dad-11d1-80b4-00c04fd430c8）、URL（6ba7b811-9dad-11d1-80b4-00c04fd430c8）、OID（6ba7b812-9dad-11d1-80b4-00c04fd430c8）和 X.500（6ba7b814-9dad-11d1-80b4-00c04fd430c8）。你也可以提供標準 UUID 格式的自訂命名空間，用於非標準命名空間。

使用方法

使用 Toollect UUID 產生器無需設定或註冊。介面分為兩個面板——一個用於 UUID v1/v2/v4/v6/v7/v8（即時產生），一個用於 UUID v3/v5（名稱型產生）。

區塊 1 — 標準 UUID（v1、v2、v4、v6、v7、v8）

1. 從下拉選單選擇 UUID 版本。預設為 v4。
2. 點擊「產生」或按 Enter。新的 UUID 立即出現在輸出欄位中。
3. 依需要切換格式選項：
   • 大寫：將輸出轉換為大寫十六進位數字。
   • 不含連字號：移除連字號，產生精簡的 32 字元字串。
4. 點擊「複製」按鈕複製結果。

版本下拉選單切換會觸發自動重新產生，因此從 v4 切換到 v7 會立即產生新的識別碼。

區塊 2 — 名稱型 UUID（v3、v5）

1. 在名稱型面板的版本下拉選單中選擇 v3 或 v5。
2. 選擇命名空間：選擇預設選項之一（DNS、URL、OID、X.500）或自訂。
3. 若使用自訂命名空間，在文字欄位中輸入有效的 UUID。工具會驗證格式，若 UUID 格式錯誤則顯示錯誤訊息。
4. 在名稱輸入欄位中輸入名稱。UUID 會隨輸入自動重新產生。
5. 切換大寫和不含連字號格式，然後如區塊 1 般複製結果。

名稱型面板在每次輸入變更時都會產生 UUID——此面板沒有獨立產生按鈕。

教學

本教學從開啟工具到複製最終 UUID，逐步引導三個常見情境。

情境 1：為網頁表單產生 UUID v4

1. 在瀏覽器中開啟工具。UUID 產生器介面顯示兩個面板。
2. 在區塊 1 中，確認版本下拉選單設為 v4（預設值）。
3. 點擊「產生」。出現一個 UUID v4，例如 550e8400-e29b-41d4-a716-446655440000。
4. **點擊「複製」**將 UUID 複製到剪貼簿，然後貼到網頁表單或 API 請求中。
5. **切換「大寫」**並再次點擊「產生」，產生 550E8400-E29B-41D4-A716-446655440000。
6. **切換「不含連字號」**產生 550e8400e29b41d4a716446655440000，適用於精簡儲存或 URL 參數。

情境 2：為資料庫主鍵產生時間排序 UUID v7

假設你正在設計一個 PostgreSQL 資料表，需要全域唯一的無序號主鍵，同時希望保持良好的寫入效能。

1. 在區塊 1 版本下拉選單中選擇 v7。輸出欄位立即顯示新的 v7 UUID，例如 018f3a6e-1a2b-7bcd-8a1b-2c3d4e5f6789。
2. 注意前幾個字元——UUID v7 以 Unix 毫秒時間戳記開頭，因此連續產生的值在前幾個群組中會呈現遞增趨勢。
3. 快速連續產生多個 UUID，觀察到這些值是單調遞增的：每個新 UUID 以比前一個更大或相等的開頭。
4. 複製識別碼用於 INSERT 語句：INSERT INTO users (id, name) VALUES ('018f3a6e-1a2b-7bcd-8a1b-2c3d4e5f6789', 'Alice');

情境 3：從資源 URL 產生確定性 UUID v5

想像你有一個內容管理系統，每篇文章由其 URL 標識，需要一個不隨部署變更的穩定 UUID。

1. 在區塊 2 中，將版本設為 v5。
2. 選擇 URL 命名空間。這使用 6ba7b811-9dad-11d1-80b4-00c04fd430c8，基於 URL 的 UUID 標準命名空間。
3. 在名稱欄位中輸入文章 URL，例如 https://example.com/articles/uuid-guide。
4. UUID 自動出現——每次使用 URL 命名空間輸入相同的 URL，都會得到相同的 UUID。
5. 測試確定性：改選 DNS 命名空間，觀察 UUID 變更。切回 URL——原始 UUID 重新出現。

專業技巧

掌握這些進階技巧，充分利用 Toollect UUID 產生器：

• 資料庫主鍵用 v7 而非 v1：UUID v7 從最高有效位元開始按毫秒時間戳記排序，為你提供 B-tree 友善的單調遞增順序，無需處理 MAC 位址或時序管理的複雜性。對於需要時間排序 UUID 的新專案，從 v7 開始。

• 名稱型 UUID 優先選用 v5 而非 v3：除非需要與使用 v3 的系統互通，否則一律使用 UUID v5。SHA-1 提供比 MD5 更高的碰撞安全邊際，效能差異可忽略。工具在名稱型面板中預設為 v5 即基於此原因。

• URL 參數中移除連字號：在 URL 路徑或查詢參數中使用 UUID 時，切換「不含連字號」。無連字號的 UUID 成為 32 字元十六進位字串，不需要 URL 編碼，在路由區段中外觀更簡潔。

• 使用預定義命名空間確保跨系統一致性：DNS、URL、OID 和 X.500 命名空間已在 RFC 9562 中標準化。使用它們可確保任何符合 RFC 的 UUID 產生器對相同的名稱產生相同的 v3 或 v5 UUID。這對於跨系統識別碼一致性至關重要。

• 使用固定 v4 UUID 作為自訂命名空間：為 v3/v5 UUID 建立自訂命名空間時，產生一次 UUID v4，將其儲存在組態中並重複使用。這可確保自訂命名空間內的所有識別碼與任何其他命名空間不同。

• 多次點擊批量產生：對於小批量，快速連續點擊「產生」可產生不同的 UUID。對於大規模產生，請使用下方所述的命令列或程式化方法。

常見 UUID 迷思

幾個廣為流傳的 UUID 說法可能不準確或具誤導性。了解其細微差別有助於做出更好的架構決策。

「UUID 100% 保證唯一。」 沒有任何識別碼系統能提供絕對保證，但正確使用的 UUID 提供極高的抗碰撞性。對於 UUID v4，在十億個產生的 ID 中發生至少一次碰撞的機率約為 10¹⁴ 分之 1。對於時間型版本（v1、v6、v7），跨不同節點的碰撞需要多台機器同時時鐘重置。所有正確實作的 UUID 的實務碰撞率實際上為零。

「UUID v4 永遠是最佳選擇。」 UUID v4 是最通用的，對大多數應用來說沒有問題，但並非所有場景都是最佳選擇。對於資料庫主鍵，v4 的隨機分佈會導致 B-tree 索引的頁面分裂和寫入放大。UUID v7 提供時間排序，可更有效地維護索引。對於必須可從名稱重現的確定性識別碼，v3 或 v5 是唯一正確的選擇。

「UUID 完全是隨機的。」 只有 UUID v4 是完全隨機的（122 位元熵）。UUID v1、v2、v6 和 v7 嵌入時間戳記，使其部分可預測——資訊可能透過識別碼洩漏。UUID v3 和 v5 對給定輸入是確定性的。若不可預測性是必要條件（安全權杖、會話識別碼），請使用搭配 Web Crypto API 的 v4。

「所有 UUID 格式都相同。」 所有 RFC 9562 UUID 共用 36 字元的 8-4-4-4-12 十六進位格式，但內部結構因版本而異。UUID v1 嵌入 MAC 位址和時間戳記位元；UUID v4 純粹是隨機的；UUID v7 結合時間戳記與隨機位元。你可以從第 13 個字元辨識版本（4 = v4、7 = v7 等），從第 17 個字元辨識變體（8、9、a 或 b）。

「UUID 拖慢資料庫效能。」 在較舊的資料庫版本和將 UUID v4 儲存為 ASCII 字串的情況下，此說法部分正確。現代資料庫（PostgreSQL 的 uuid 型別、MySQL 8+ 的 UUID_TO_BIN、SQL Server）將 UUID 儲存為 16 位元組二進位值，並提供原生索引支援。UUID v7 進一步透過時間排序產生減輕索引碎片化。對大多數工作負載而言，與自動遞增整數的效能差異可忽略不計。

替代方案

Toollect UUID 產生器之外還有幾種替代方案，各自適用於不同的工作流程。

對於大多數需要在瀏覽器中即時、私密、多版本 UUID 產生的使用者，Toollect UUID 產生器提供最全面的功能集。

資料隱私

Toollect UUID 產生器在瀏覽器中完全處理你的每個位元組資料。你輸入的任何資料——名稱、命名空間或產生的識別碼——都不會傳輸到任何伺服器、儲存在任何資料庫中或記錄在任何系統中。

所有產生使用 JavaScript 內建的 Web Crypto API（crypto.getRandomValues、crypto.randomUUID、crypto.subtle.digest）。工具頁面不含任何分析腳本、追蹤像素、Cookie 或第三方嵌入。不建立或讀取任何 localStorage 或 sessionStorage 條目。

初始頁面載入後，UUID 產生器可完全離線運作——即使在飛航模式下也能產生識別碼，零網路活動。你可以透過瀏覽器開發者工具的網路分頁驗證，或完全斷開網路連線。

疑難排解

技術規格

Toollect UUID 產生器經過正確性、效能和跨瀏覽器相容性的工程設計。

標準遵循

各版本演算法細節

瀏覽器相容性

隱私與安全

• 零資料傳輸：所有產生發生在瀏覽器記憶體中
• 不使用 Cookie、localStorage 或 sessionStorage
• 工具頁面上無分析或追蹤腳本
• 初始頁面載入後可完全離線運作
• 無需註冊、登入或 API 金鑰
• 透過 Web Crypto API 提供加密安全隨機性

功能特色

• 產生所有 UUID 版本 v1 至 v8，包括時間型（v1、v6、v7）、隨機型（v4）、名稱型（v3、v5）、DCE 安全（v2）與自訂型（v8）
• 使用 Web Crypto API 進行加密安全隨機產生，零網路傳輸
• 切換大寫輸出與移除連字號，產生適合顯示或精簡的 UUID
• 名稱型 UUID 支援內建命名空間（DNS、URL、OID、X.500）與自訂命名空間驗證
• 100% 用戶端處理 — 不上傳任何資料至伺服器，無需註冊或安裝
• 一鍵產生與複製，所有現代瀏覽器與裝置即時可用

常見問題