真正隨機UUID產生器 - 線上批次產生v4與v7 UUID
產生v4(完全隨機)或v7(依時間排序)的通用唯一識別碼,可逐個產生,也可在瀏覽器中批次產生最多1,000個。
選擇UUID版本和所需數量,然後按下產生按鈕。你可以切換為大寫,或在複製前移除連字號。
真正隨機UUID產生器 - 線上批次產生v4與v7 UUID
產生v4(完全隨機)或v7(依時間排序)的通用唯一識別碼,可逐個產生,也可在瀏覽器中批次產生最多1,000個。
從RANDOM.ORG取得128位元大氣雜訊熵,為本機PRNG設定種子,供批次中每個UUID提供隨機位元。若無法連線random.org,則改用本機CSPRNG。
版本4完全隨機:128位元中有122位元直接來自安全隨機來源。
關於UUID產生器
UUID(通用唯一識別碼,在Windows平台也稱為GUID)是128位元值,以32個十六進位數字寫成五組、組間以連字號分隔,格式為xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx,其中M代表版本,N代表變體。由於值域極其龐大,兩個正確產生的UUID在實際上幾乎不會衝突,因此它們是資料庫主索引鍵、API請求ID、檔名、分散式追蹤、訊息去重,以及任何需要獨立系統協調產生識別碼情境的預設選擇。
此UUID產生器完全在瀏覽器中執行。每個識別碼都使用Web Crypto API提供的密碼學安全隨機來源crypto.getRandomValues()產生,而不是可預測的Math.random()。你產生的內容不會傳送至伺服器、記錄或儲存:關閉分頁後,識別碼只存在於你貼上的位置。因此,即使識別碼最終用於正式系統,也能安全使用此工具。
支援的兩個版本都由RFC 9562定義(該標準於2024年取代原RFC 4122)。版本4是經典的完全隨機UUID:除了六個固定版本和變體位元外,其餘122位元都是隨機值。版本7是現代的依時間排序方案:前48位元儲存Unix毫秒時間戳,後面是隨機位元。因為時間戳在開頭,後建立的v7識別碼按字典序會排在先前識別碼之後。這讓資料庫索引更友善,因此v7現在是PostgreSQL、MySQL及多數其他儲存中新主索引鍵的建議預設值。若不希望識別碼洩露建立時間,請選擇v4。
批次選項一次最多產生1,000個識別碼,每行一個,可直接貼到種子腳本、試算表或測試固定資料。格式切換可將輸出改為大寫(規格允許兩種大小寫,但建議輸出小寫),或移除連字號以配合儲存純32位元數字的系統。必須誠實說明:唯一性是機率性的,並非登記保證——沒有產生器能保證識別碼從未在別處使用;UUID是識別碼而非秘密,絕不要將其作為密碼或存取權杖。
可選的真隨機模式會將產生器連接到物理隨機來源。選取後,工具透過RANDOM.ORG的公開HTTP介面取得由大氣無線電雜訊產生的八個16位元整數——瀏覽器直接與random.org通訊,中間沒有我們的伺服器——並將其組合為sfc32偽隨機產生器的單一128位元種子。批次中的每個UUID接著從該種子產生器取得隨機位元,因此整批可追溯到物理隨機性而非演算法狀態;v7模式的48位元時間戳仍來自你的時鐘,版本和變體位元也相同。取捨是種子確實隨機,但播種後產生多個識別碼是確定性的,種子整數會經網路傳送——對識別碼完全沒問題,這也是本機CSPRNG仍為預設且同樣可靠的原因。若random.org無法連線或超過每IP配額,工具會自動改用crypto.getRandomValues()並顯示提示,結果下方的來源標籤也會說明實際產生路徑。
UUID產生器範例
典型設定及其產生結果。
| 設定 | 輸出 | 備註 |
|---|---|---|
| v4,數量1,預設格式 | 一個36字元、格式為xxxxxxxx-xxxx-4xxx-Nxxx-xxxxxxxxxxxx的識別碼 | 第三組一定以4(版本數字)開頭;N是8、9、a或b之一(變體)。 |
| v7,數量1 | 依時間排序、第三組以版本數字7開頭的識別碼 | 前12個十六進位數字編碼Unix毫秒時間戳,因此較晚的ID會排在較早的ID之後。 |
| v4,數量100,移除連字號 | 100行,每行32個不含連字號的十六進位數字 | 適合儲存精簡格式的系統,例如某些舊式結構和URL短網址。 |
| v7,數量1000,大寫 | 1,000個大寫識別碼,每行一個 | 批次模式每次最多1,000個;需要更多時再次執行。大小寫等價。 |
如何產生UUID
- 選擇版本:v4用於完全隨機識別碼,v7用於依建立時間排序的識別碼。
- 在數量欄輸入所需數量——範圍為1到1000。
- 可選勾選大寫或移除連字號,以變更輸出格式。
- 按下產生按鈕,再用剪貼簿按鈕複製全部內容,或從輸出框選取各行。
UUID產生器常見問題
UUID v4和UUID v7有什麼差別?
除版本和變體位元外,v4完全隨機。v7把48位元Unix毫秒時間戳放在隨機位元前,因此識別碼依建立時間排序。插入區域性重要的資料庫索引鍵使用v7;不應讓ID推測建立時間時使用v4。
兩個UUID可能衝突嗎?
理論上可以,實務上不會。v4有122個隨機位元,要產生約2.7 quintillion個識別碼才有50%機率出現一次重複。任何真實工作負載的衝突風險都遠低於硬體故障。
這個產生器具備密碼學安全性嗎?
隨機位元來自作業系統播種的crypto.getRandomValues() CSPRNG,因此識別碼不可預測。不過UUID是識別碼而非秘密,不要拿來當密碼、工作階段權杖或API金鑰。
UUID會傳送到伺服器或儲存在哪裡嗎?
不會。產生在瀏覽器中使用Web Crypto API完成。任何內容都不會傳輸、記錄或持久化;重新整理頁面就會捨棄全部內容。
大寫UUID有效嗎?可以移除連字號嗎?
RFC 9562規定輸出應為小寫,但解析器必須接受兩種大小寫,因此大寫在實務上到處有效。連字號只是呈現方式;許多資料庫儲存不含連字號的32位元格式,但要求標準36字元布局的工具會希望保留連字號。
v7 UUID會洩露資訊嗎?
只會洩露精確到毫秒的建立時間,其餘位元都是隨機的。如果你的用途不能暴露記錄建立時間,請改用v4。