開發者工具 · UUID 產生器
手動讀取 UUID：版本和變體位所在的位置
· 工作原理
uuid 密碼學 瀏覽器 API
每個 UUID 中的兩個十六進位字元告訴您哪個版本產生了它以及它遵循哪種變體佈局。學會一眼閱讀它們並知道它們不能告訴你什麼。
這個ID是哪個系統產生的？ — 版本半位元組可以回答的日誌取證問題
UUID 字串有 36 字元：三十二個十六進位數字和 8-4-4-4-12 位置處的四個連字號。每個 UUID 中的兩個字元（出現在 14 和 19 位置）編碼元資料：版本欄位告訴您哪個演演算法產生了 ID，變體欄位告訴您它遵循哪種標準佈局。不使用工具讀取這兩個字元是日誌取證技能：您在資料庫轉儲或錯誤訊息中發現 UUID ，並立即知道它是 v1 時間戳記（洩漏建立時間）、v4 隨機值（從 CSPRNG 產生）還是其他值。版本號佔用 UUID 的位元 48–51，對應到第三組的第一個十六進位字元。
五組中的 128 位元佈局 — 8-4-4-4-12 如何對應到位元組以及為什麼這些群組是歷史性的，而不是功能性的
對於字串 xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx，位置 14 處的字元是版本。 RFC 9562 定義版本 1 到 8：v1 基於公曆時間並洩漏建立時間； v4 是隨機的； v7 是基於 Unix 時間且可排序的。版本 0、9 及更高版本已保留或未使用。如果您看到 v1 UUID，您就知道時間和硬體位址已混合在一起；如果您看到 v4，則 ID 是帶有版本位集的隨機位元組；如果您看到 v7，它會按建立時間排序。版本不可選；每個正確形成的 UUID 都有一個。變體欄位佔用 UUID 的位元 64–65，也就是八位元組 8 的兩個最高有效位元。
版本半位元組 — 第三組的第一個字符，1 到 8 的意義，以及 0 或 9 表示什麼
在文字表示 xxxxxxxx-xxxx-xxxx-Nxxx-xxxxxxxxxxxx 中，第四組的第一個字元（位置 19）對變體進行編碼。對於 RFC 9562 變體（現代使用的標準），該字元必須是 8、9、a 或 b——二進位 1000、1001、1010 和 1011 的十六進位表示。任何其他字元（0–7、c–f）表示不同的變體：0–7 是 NCS 向後相容性； c–d 是具有小端位元組順序的 Microsoft 舊版 GUID； e–f 保留。當您閱讀位置 19 並看到 8、9、a 或 b 時，您正在查看 RFC 9562 UUID。任何其他值都意味著位元組遵循不同的解釋。 128 位元佈局分為八位元組 0-15，但文字格式將它們按組分隔，以提高可讀性，而不是為了功能。
變體欄位 — 為什麼第四組的第一個字元是 8、9、RFC UUID 的 a 或 b，以及 c/d（Microsoft 舊版）或 0–7 (NCS) 訊號
這五組代表歷史欄位邊界：前三個欄位包含 v1 UUID 中的時間戳記和版本，第四個欄位包含時脈序列和變體，第五個欄位包含節點識別碼。版本 4 和更高的 UUID 版本不使用這些欄位名稱，但相同的位元位置仍然攜帶版本和變體。讀取 v4 UUID 表示接受大多數 128 位元是隨機負載，但其中兩個（文字中的 14 和 19 位置）是由標準固定的。這些固定位元證明 ID 是 v4 和 RFC 變體。 nil UUID 是 00000000-0000-0000-0000-000000000000，全部為零，而且完全沒有版本。最大 UUID 為 ffffffff-ffff-ffff-ffff-ffffffffffff，全部為 f 字符，並也是保留的且無版本控制。
工作範例 - 逐個字元解碼三個樣本標識符，包括 v4 和 v7
每個其他格式正確的 UUID 在第三組中都有一個版本，在第四組中則有一個變體。使用三個範例 ID 進行測試：123e4567-e89b-12d3-a456-426614174000（v1，變體 RFC，因為位置 19 是 a）；9b2e4f1a-4f3e-4c1a-8a7d-1b2c 是8）； 018f0c2e-1b5a-7c3d-9e4f-5a6b7c8d9e0f（v7，變體 RFC，因為位置 19 是 9）。 ToolAcre 檢查器會確認您的讀數。格式檢查無法告訴您 ID 是唯一的、存在於資料庫中還是安全產生的。版本 v1 使用時間和硬體作為輸入，因此來自不同電腦的相同 v1 UUID 意味著時鐘偏差或同步問題。 v4 版本是隨機的，因此重複的 v4 UUID 意味著要么破壞隨機性，要么發生天文數字上不太可能發生的衝突（大約每 2. 7 萬億個具有良好隨機性的 UUID 就會發生一次）。
Nil 和 Max — 兩個全零和全 F 值，完全不攜帶版本
版本 0 或 9 表示該字串根本不是有效的 UUID。閱讀版本和變體是理解 ID 是什麼的第一步；檢查它是否存在或唯一是第二步和第三步，由資料庫和業務邏輯完成。了解位元位置有助於調試資料遷移。從舊系統匯入 UUID 時，某些工具會匯出與 RFC 9562 標準不符的變體欄位。 c 或 d 的變體欄位指示採用小端位元組順序的 Microsoft GUID。這些 GUID 是 Microsoft 系統內的有效標識符，但在沒有位元組順序轉換的情況下不能與 RFC 9562 UUID 互通。讀取位置 19 會立即告訴您哪個系統產生了 ID。如果您看到 8、9、a 或 b，則您擁有 RFC 標準 UUID。
格式檢查無法告訴您的資訊 — ID 存在於您的資料庫中、它是安全產生的或它是唯一的
如果您看到 c 或 d，則您有一個 Microsoft GUID。如果您看到任何其他字符，則標識符格式錯誤或來自模糊系統。 ToolAcre 產生器總是會產生位置 19 作為 8、9、a 或 b 之一的 RFC 9562 UUID。三位版本欄位編碼七個可能的值（1-7；版本 0 和 8 有特殊意義）。版本 1 是公曆時間戳，版本 3 是基於 MD5 的命名空間，版本 4 是隨機的，版本 5 是基於 SHA-1 的命名空間，版本 6 是基於 Unix 時間戳（建議），版本 7 是基於 Unix 時間戳的可排序（在 RFC 9562 中標準化），版本 8 保留用於定義時間戳格式。讀取位置 14 字元會立即告訴您使用了哪種演演算法。如果您正在偵錯 UUID 衝突或意外排序，版本號碼是您的第一個線索。 ToolAcre 專門從加密產生 v4 UUID。
重點：兩個字符，大量上下文 - 使用 ToolAcre 格式正確的檢查來確認字串解析，然後自己讀取版本半字節
取得隨機值；它產生的每個 UUID 在位置 14 處都有一個 4。手動解析 UUID 結構對於除錯無法使用工具的複雜系統來說是一項有用的技能。在生產事件中，您可能需要從資料庫轉儲、錯誤日誌或快取中讀取 UUID，而無需執行特殊工具。您尋找位置 14 來識別版本（它是否有洩漏時間？它是隨機的嗎？它是可排序的嗎？）。您會尋找位置 19 來識別變體（它是 RFC 標準嗎？它是 Microsoft GUID？它是保留的嗎？）。這兩個字元（總共 36 個）攜帶元資料。剩餘的 34 字元是有效負載：時間戳記或隨機位元組或其他特定於演演算法的資料。了解有效負載代表什麼有助於您了解 ID 在系統中的角色。