開發者工具·UUID產生器
crypto.getRandomValues 如何將 16 個隨機位元組轉換為 v4 UUID
· 工作原理
uuid 密碼學 瀏覽器 API
版本 4 UUID 是來自加密安全產生器的 16 bytes，並覆蓋了六個位元。這篇文章將位元組從 Web Crypto 呼叫逐步介紹到熟悉的 36 個字元的字串。
伺服器應答之前需要的 ID——為什麼客戶端會產生以離線優先的形式、樂觀的 UI 和批次匯入的形式出現
離線表單在伺服器回應之前可能需要標識符，而樂觀的 UI 可能會同時建立多個物件。 UUIDv4 設計為獨立生成，無需中央計數器。它不是用戶身份的證明，也不是可以安全地代替身份驗證的秘密。如果您的資料庫需要按建立時間排序的值，則隨機 v4 ID 不會排序；這是一個單獨的模式決策，而不是削弱其隨機性的原因。
crypto.getRandomValues 實際上做了什麼——從作業系統的熵源填充類型化數組，而不是從 JavaScript 公式
crypto.getRandomValues 使用來自瀏覽器平台的加密安全隨機產生器的 16 bytes 填充 Uint8Array。它不會從 Date.now() 或 Math.random() 派生值。作業系統和瀏覽器實現了底層熵來源，因此 JavaScript 程式碼接收位元組而不是實現隨機數公式本身。如果不存在安全來源，ToolAcre 將拒絕產生識別碼。
覆蓋位元組 6 和位元組 8 — 版本半位元組如何變為 4，變體位如何變為 10xx，以及為什麼僅丟失 6 位
RFC 9562 描述了版本半位元組和變體欄位。從十六個隨機位元組開始，將位元組 6 的高四位元設為二進位 0100（版本 4），並將位元組 8 的高兩位位元設為 10（標準變體）。實現使用 (byte6 & 0x0f) | 0x40 和（byte8 和 0x3f）| 0x80。 6 位被覆蓋，在 UUIDv4 方案下留下 122 個隨機位元。這些常量位元不會使剩餘位元組的隨機性降低。
從位元組到 8-4-4-4-12 — 十六進位編碼、小寫輸出和連字號放置（依照標準定義）
需要時將每個位元組編碼為兩個帶有前導零的十六進位字元。在 4、6、8 和 10 bytes 之後插入破折號，產生熟悉的 8-4-4-4-12 十六進位字元組。有效的 v4 字串在其第三組的開頭有一個 4，在其第四組的開頭有 8、9、a 或 b 之一。格式化不會增加熵；它僅使底層 128 位元值可與需要 UUID 文字形式的工具進行互通。
工作範例 - 透過屏蔽和格式化追蹤一個 16 位元組緩衝區到其最終的 UUID 字串
追蹤說明性位元組 00 11 22 33 44 55 F6 77 38 99 AA BB CC DD EE FF。在位元組 6 處屏蔽 F6 產生 46；位元組 8 處的遮罩 38 產生 B8。經過小寫十六進位格式化和破折號後，結果為 00112233-4455-4677-b899-aabbccddeeff。這是一個故意固定的教學範例，而不是在生產中重複使用的標識符。為每個真實對象產生一個新的對象，並自行比較版本和變體位置。
crypto.randomUUID() 作為一呼叫捷徑 - 新方法可以為您做什麼以及它不可用的地方
在安全性來源上，crypto.randomUUID() 在一次呼叫中執行 v4 產生和格式化。 ToolAcre 在可用的情況下使用它，否則使用上面的明確位元操作回退到 getRandomValues。瀏覽器可用性因上下文而異：randomUUID 僅限於安全上下文，而 getRandomValues 可能仍存在於 HTTP LAN 頁面上。兩個分支都不會退回到 Math.random 只是為了保持按鈕明顯運作。
這不包括基於時間（v1，v7）和基於名稱（v3，v5）的版本，它們需要與隨機位元組不同的輸入
此機制不描述基於時間的 v1 或 v7 識別碼、基於名稱的 v3/v5 識別碼或實驗性 v8 佈局。隨機 UUID 的碰撞機率非常低，並且具有良好的隨機性，但並不是數學上絕對不可能發生碰撞。在不獨立考慮保密性、生命週期和授權的情況下，v4 UUID 本身不應用作存取控制檢查或密碼重設令牌。
重點：安全隨機性是整個工作 — ToolAcre UUID 產生器從同一瀏覽器 CSPRNG 中提取，因此您複製的內容就是您的程式碼將產生的內容
安全隨機性就是工作。 ToolAcre UUID 產生器使用瀏覽器的 CSPRNG，強制執行版本和變體位，並為複製值提供格式良好的檢查。將產生的結果與位元組佈局範例進行比較，然後僅將新的、唯一的輸出用於應用程式實際分配的角色。