開發者工具 / 039
UUID 產生器
一次產生多組 UUID，支援 v4 與 v7；v7 可從識別碼中讀出時間資訊，並具有依時間排序的特性。
版本 · 122 位純隨機，最通用
結果（0 組）
亂數用瀏覽器內建的 crypto.getRandomValues() 產生， 不是 Math.random()——UUID 常被當成識別碼甚至權杖使用， 用可預測的亂數會變成安全問題。
為什麼做這個
UUID v4 適合一般隨機識別碼；v7 則把時間資訊放進前段，在需要大致依建立時間排序的資料情境中較方便。這個工具提供兩種格式並顯示 v7 對應時間。
這個工具怎麼用
選好版本與數量就會立即產生。可以切換大小寫與是否保留連字號——有些資料庫欄位或 API 規格要求 32 字元的無連字號格式，那就把連字號關掉。
v4 是 122 位純隨機，除了 6 位固定給版本與變體之外全部是亂數。它最通用、碰撞機率低到可以忽略（要產生兆兆級數量才有實際風險），拿來當一般識別碼沒有問題。
UUID v7 的前段包含毫秒時間資訊，因此在標準字串排序下通常會大致依產生時間排列。這種特性在部分資料庫索引情境較友善，但實際效能仍會受到資料庫、索引設計與寫入模式影響。右側欄位會把 UUID 中的時間資訊轉回可讀日期。
亂數用的是瀏覽器內建的 `crypto.getRandomValues()`，不是 `Math.random()`。UUID 常被當成識別碼甚至權杖使用，如果亂數可預測，攻擊者就有機會猜出別人的識別碼。這個差別在安全性上是關鍵的。
UUID 的標準寫法是 32 個十六進位字元，以連字號分成 8-4-4-4-12 五段。版本號藏在第三段的第一個字元：v4 長得像 `xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx`，v7 則是第三段以 7 開頭；第四段的第一個字元（`y`）只會是 8、9、a、b，用來標示變體。看到一個 UUID 時，只要看這兩個位置就能判斷它大致是哪一類。
v4 有 122 個位元是亂數，可能的組合約 5.3×10³⁶ 種。依生日悖論估算，要產生約 2.7×10¹⁸ 個 v4 UUID 才會有 50% 的機率出現至少一組重複，一般系統遠遠不會碰到。真正會造成重複的往往不是機率，而是亂數來源有問題或複製貼上了同一個值，所以要確認使用的是密碼學等級的亂數。
常見問題
v4 跟 v7 該用哪個？
拿來當資料庫主鍵用 v7，其他情況 v4 就夠。v7 的優勢是索引友善（字典序＝時間序），代價是會洩漏產生時間——如果那個時間屬於敏感資訊（例如帳號建立時間不想被推算），就用 v4。
UUID 會重複嗎？
實務上不會。v4 有 122 位隨機，要產生數兆個才會有值得擔心的碰撞機率。v7 的隨機位數較少（74 位），但同一毫秒內才有碰撞可能，同樣不需要擔心。真正的風險反而是用了不安全的亂數來源——那會讓 UUID 變得可預測。
為什麼 v7 適合當資料庫主鍵？
因為它是時間排序的。索引是排序結構，插入隨機值會讓新資料散落在整個索引裡，造成大量分頁分裂與快取失效；插入遞增值則集中在尾端，行為接近自增主鍵。所以 v7 能同時得到「索引效能好」與「不需中央協調就能產生 ID」兩個好處。
為什麼不用 Math.random()？
因為它不是密碼學安全的亂數來源，輸出是可預測的。UUID 經常被當成識別碼甚至一次性的存取權杖，可預測的話攻擊者就能猜到別人的 ID。這個工具用 `crypto.getRandomValues()`，那是專為加密用途設計的亂數來源。
UUID 跟 GUID 是同一個東西嗎？
是。GUID 是微軟生態的叫法，格式與規格相同。唯一要注意的是微軟的工具常輸出大寫並用大括號包住（`{ABC...}`），這個工具可以切換大小寫，大括號需要自己加。
怎麼從字串看出是 v4 還是 v7？
看第三段（第 15 個字元）：4 開頭是 v4，7 開頭是 v7。v7 的前 48 位元是毫秒時間戳，所以同一時間附近產生的 v7 開頭會相近、大致可依時間排序，v4 則完全隨機。