UUID生成器｜批次生成v4，支援無連字元/大寫格式
在瀏覽器中批次生成任意數量的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 產生
UUID（Universally Unique Identifier）是用於資料庫主鍵、API 請求 ID 等場合，以在全球範圍內不重複為目的的128位元識別碼。其特點在於無須由中央伺服器管理連號，各終端與伺服器只要各自獨立發行即可，在實用上不會發生衝突。
本工具使用 Web Crypto API 在瀏覽器內產生 UUID v4（完全隨機）。產生處理不會傳送至伺服器，可依指定件數一次產生，並可一鍵轉換為標準格式、無連字號、大寫、含大括號、URN 形式後複製。
UUID 產生的使用方式
- 指定產生件數 輸入所需的個數。若要為測試資料或種子資料一次產生，可指定較多的件數。
- 選擇顯示格式 除標準（小寫、連字號分隔）之外，還可從無連字號、大寫、含大括號、URN 形式中選擇契合用途的格式。
- 產生並複製 按下「產生」後結果會以清單顯示。可用「全部複製」或各列的「複製」按鈕貼上到剪貼簿。
用好本工具的小技巧
- 生成的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 產生派上用場的情境
資料庫主鍵設計
對於不希望使用連號、不希望被推測出產生來源的資料表，可將無須擔心重複的 UUID v4 用作主鍵。
API 的請求 ID、追蹤 ID
為便於日誌排查與除錯而為每個請求賦予唯一 ID 時，可一次產生所需的件數。
測試用資料、種子資料的製作
向開發環境注入初始資料時，可依件數一次產生不重複的 ID 序列，直接複製使用。
檔名、臨時權杖的產生
可將「無連字號」形式的 UUID 用作上傳檔案的臨時名稱，或用作不易被推測的臨時權杖。
用語集
- UUID v4
- 由密碼學虛擬亂數產生、不含產生來源資訊的 UUID。實作簡單且在隱私方面安全，因此使用最為廣泛。
- GUID
- 微軟在自家實作中使用的 UUID 別名。指與 UUID 相容的128位元識別碼，多以含大括號的形式表記。
- Web Crypto API
- 瀏覽器標準內建的加密相關 JavaScript API 群。本工具使用該 API 僅在瀏覽器內產生 UUID v4，不會傳送至伺服器。
- URN 形式
- 加上
urn:uuid:前綴的 UUID 表記形式。在 XML、RDF 等要求 URN（統一資源名稱）的規範中，將 UUID 作為識別碼嵌入時使用。 - UUID v7
- 2024年由 RFC 9562 標準化、開頭帶有 Unix 時間戳記的 UUID。因可依產生順序排序，在要求資料庫插入效率的新開發中，作為 v4 的替代方案正逐漸普及。
常見問題
{xxxxxxxx-xxxx-...}是Windows COM/登錄檔中常見的GUID寫法。
閒話 ― 為什麼要用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時間戳，在保持隨機性的同時確保了插入區域性性。