UUID生成器
在瀏覽器中批次生成UUID v4（隨機）識別符號。支援標準、大寫、無連字元、大括號、URN等多種顯示格式。
UUID版本一覽
| 版本 | 生成方式 | 說明 |
|---|---|---|
| UUID v1 | 時間戳 + MAC地址 | 基於生成時間和網絡卡MAC地址生成。由於可能暴露生成裝置資訊而存在隱私隱患，目前新系統很少採用。 |
| UUID v3 | 名稱空間 + MD5雜湊 | 對名稱空間和名稱字串進行MD5雜湊後生成。具有確定性——相同輸入始終得到相同UUID。由於MD5存在碰撞弱點，新用途推薦使用v5。 |
| UUID v4 | 完全隨機 | 基於密碼學安全的隨機數生成。不包含來源資訊，隱私性好且實現簡單，是目前使用最廣泛的版本。本工具生成的即為此格式。 |
| UUID v5 | 名稱空間 + SHA-1雜湊 | 與v3同樣採用名稱空間方式，但使用SHA-1。適用於需要確定性生成（相同資料始終得到相同ID）的場景。 |
| UUID v6 | 重排時間戳 + 隨機數 | 2024年由RFC 9562標準化。重新排列了v1的時間戳欄位，使位元組序的字典順序與時間順序一致，從而提升資料庫索引效率。 |
| UUID v7 | Unix時間戳 + 隨機數 | 2024年由RFC 9562標準化。開頭為毫秒精度的Unix時間戳，因此可按生成順序排序。在新專案中作為v4的替代方案正被越來越多地採用。 |
使用提示
- 生成的UUID完全在瀏覽器內通過Web Crypto API處理，不會發送到toolbase.cc的伺服器。
- 當需要唯一性但不想使用連續、可猜測的ID時（如資料庫主鍵、API請求ID等），UUID v4是廣泛使用的選擇。
- UUID v4的128位中有122位是隨機的，因此發生碰撞的機率極低（即使生成10億個，碰撞機率達到約50%也需要約2.7×10¹⁸個）。
- "無連字元"格式便於用作URL路徑段或檔名。"帶大括號"格式與Windows COM/登錄檔中使用的GUID表示法相同。
- 增加生成數量後使用"複製全部"，可以方便地批次建立測試資料或種子資料。
常見問題
理論上並非絕對不可能，但由於UUID v4擁有122位隨機性，實際使用中這種機率可以忽略不計。即使每秒生成10億個UUID並持續100年，發生一次碰撞的機率也僅約為50%。
是的，基本上是同一個概念。GUID（全域性唯一識別符號）是微軟對自身實現的稱呼，與UUID的128位格式相容。帶大括號的格式
{xxxxxxxx-xxxx-...}是Windows COM/登錄檔中常見的GUID寫法。由於UUID v4是隨機的，相比連續整數（AUTO_INCREMENT），索引體積往往更大，插入效能可能下降。如果需要按插入順序排序，可以考慮包含時間資訊的UUID v7，或採用ULID作為替代方案。
如果只需要唯一性，UUID v4最簡單且安全。如果需要相同輸入始終得到相同ID，可選v5；如果新專案重視生成順序或資料庫插入效率，v7是有力選擇。v1、v3目前已很少被新專案採用。
閒話 ― 為什麼要用128位
UUID（通用唯一識別符號）由Apollo Computer公司在1980年代為分散式系統而設計，後來由OSF（開放軟體基金會）作為DCE（分散式計算環境）的一部分進行標準化。目前的規範見於IETF RFC 4122（2005年），2024年又釋出了擴充套件版RFC 9562。
128位看似過多，但這個長度是為了保證多臺伺服器、裝置完全不互相通訊、各自獨立發行ID時，在實際使用中也不會發生碰撞。若採用中央ID發行伺服器統一管理連號，該伺服器會成為單點故障，且每次發行都需要一次通訊開銷。UUID用足夠長的隨機性把碰撞機率降到可忽略的水平，從而徹底消除了這種協調成本。
但UUID v4正因為是隨機的，插入資料庫的B-Tree類索引時會導致插入位置分散，頻繁引發頁分裂，從而影響效能。為解決這個問題而設計出的可按時間順序排序的UUID v7，通過在開頭攜帶Unix時間戳，在保持隨機性的同時確保了插入區域性性。