產生識別碼
產生版本 1、3、4、5、6、7 的 UUID 或 ULID，可逐一產生或一次最多一千個；也可以分析任何識別碼，了解其版本、變體以及其中包含的時間。所有計算都在你的瀏覽器中使用系統的加密亂數產生器完成。
122 位元隨機數。只需要唯一識別碼時最常用的選擇。
格式
結果
分析 UUID 或 ULID
支援連字號、大括號、urn:uuid: 前綴或 26 個字元的 ULID
類型
版本 7：可排序的 Unix 時間
變體
RFC 9562（原 RFC 4122）
建立時間
2022年2月22日 下午4:22:22 2022-02-22T19:22:22.000Z · 1645557742000 ms
標準形式017f22e2-79b0-7cc3-98c4-dc0c0c07398f
大寫017F22E2-79B0-7CC3-98C4-DC0C0C07398F
帶大括號的 GUID{017F22E2-79B0-7CC3-98C4-DC0C0C07398F}
URNurn:uuid:017f22e2-79b0-7cc3-98c4-dc0c0c07398f
作為 ULID01FWHE4YDGFK1SHH6W1G60EECF
十六進位017f22e279b07cc398c4dc0c0c07398f
十進位整數1989357241971137676463954034883508623
Base64AX8i4nmwfMOYxNwMDAc5jw==

運作方式

UUID 是一個 128 位元的數字，寫成分為五組（8-4-4-4-12）的 32 個十六進位數字。它不需詢問任何人該值是否已被使用就能識別一筆記錄：兩台伺服器、兩個行動應用程式或兩個行程可以同時產生識別碼，無需協調也不會衝突。其格式由 RFC 9562 定義，該標準於 2024 年取代 RFC 4122，並新增版本 6、7 與 8。

第三組開頭的數字表示版本，每個版本排列位元的方式都不同。版本 4 是純隨機數。版本 7 以毫秒級時間開頭，因此識別碼依建立順序排列。版本 3 與 5 沒有任何隨機成分：它們由命名空間和名稱的雜湊產生，所以結果總是相同。版本 1 與 6 包含精度為 100 奈秒的時間以及一個節點，這個節點在歷史上是電腦的 MAC 位址。

分析器則反向運作：讀取版本與變體，從 v1、v6、v7 UUID 以及 ULID 中還原時間，並將同一個值顯示為 GUID、URN、十六進位、整數或 Base64。所有計算都在你的瀏覽器中完成，不會有任何識別碼傳送到伺服器。

範例

v5 · DNS · www.example.com2ed6657d-e927-568b-95e1-2665a8aea6a2這是 RFC 9562 的測試向量。任何正確實作版本 5 的函式庫，對於 DNS 命名空間中的這個名稱都必須回傳完全相同的值。
017F22E2-79B0-7CC3-98C4-DC0C0C07398F2022-02-22T19:22:22.000Zv7 UUID 的前 12 位是十六進位的 Unix 毫秒數：0x017F22E279B0 即 1645557742000。
C232AB00-9414-11EC-B3C8-9F6BDECED8461EC9414C-232A-6B00-B3C8-9F6BDECED846同一時刻分別表示為版本 1 與版本 6。版本 6 將時間位元依從高到低重新排列，使文字依時間順序排序；時鐘序列與節點不變。
01ARZ3NDEKTSV4RRFFQ69G5FAV01563e3a-b5d3-d676-4c61-efb99302bd5bULID 與 UUID 同樣占用 128 位元，因此可以存入 uuid 欄位。但它沒有版本和變體：以 UUID 讀取時，這些數字只是隨機部分的一部分。

使用情境

  • 在用戶端或多個服務中同時產生主鍵，無需等待資料庫分配自動遞增值。
  • 產生冪等鍵，避免重試的付款或訂單被處理兩次。
  • 為每個請求加上關聯 ID，以便在多個微服務的日誌中追蹤它。
  • 用 v5 從自然鍵（電子郵件、URL、SKU）衍生穩定的識別碼，讓兩個系統無需共用資料表也能得到相同的值。
  • 當 v7 UUID 或 ULID 出現在日誌或錯誤報告中時，據此得知記錄的建立時間。
  • 一次用數百個有效識別碼填入測試資料。

常見問題

主鍵用 v4 還是 v7？

除非你有理由隱藏建立時間，否則用 v7。B 樹索引依順序儲存鍵，而 v4 會落在索引的任意位置：每次插入都會觸及不同的頁面，導致頁面分割，快取效率也更低。v7 則總是加到末尾，就像自動遞增值一樣。注意 SQL Server：uniqueidentifier 類型從最後六個位元組開始比較排序，所以在那裡 v7 也不是循序的。

兩個 v4 UUID 會重複嗎？

理論上會，實際上不會。v4 有 122 個隨機位元，要讓至少出現一次重複的機率達到 50 %，大約需要產生 2.7 × 10¹⁸ 個，也就是每秒十億個、持續 85 年以上。前提是使用加密亂數產生器：現實中回報的重複都來自初始化不當的種子，而不是數學本身。

UUID 和 GUID 是同一回事嗎？

是的，GUID 是 Microsoft 使用的名稱，文字完全相同；在 Windows 中通常以大寫並加上大括號顯示。差別在於二進位形式：.NET 的 Guid.ToByteArray 以小端序儲存前三組，所以如果你在其他語言中讀取這些原始位元組，會看到開頭的數字是反的。

可以把 UUID 當作秘密權杖嗎？

正確產生的 v4 含有 122 個不可預測的位元，足以用作難以猜測的連結；但 RFC 9562 明確指出 UUID 並非為憑證設計：許多函式庫並不保證使用加密亂數產生器，而版本 1、6、7 會暴露建立時間。對於工作階段權杖或密碼重設權杖，最好產生專用的隨機位元組。

ULID 還是 UUID v7？

兩者攜帶的資訊幾乎相同：48 位元毫秒時間，其餘為隨機數。ULID 以 26 個字元書寫，沒有連字號和易混淆字母，放在 URL 裡更方便。v7 是標準 UUID，因此無需轉換即可放入 PostgreSQL 的 uuid 欄位並通過任何驗證器。如果你從零開始且資料庫支援 uuid 類型，選 v7。

為什麼我的 v1 UUID 的節點不是我的 MAC？

因為暴露網路卡的 MAC 可以追蹤每個識別碼是由哪台機器產生的，1999 年 Melissa 病毒的作者就是這樣被查出來的。RFC 9562 建議使用設定了多播位元的隨機節點，本工具正是這麼做的；當 v1 UUID 包含真實 MAC 時，分析器會提醒你。

另請參閱