UUID 分析與解碼工作台
UUID Decoder & Inspector UUID 分析工具
分析 UUID 的版本、變體、時間戳與結構。支援 v1~v8 全版本檢測、Timestamp 解碼、 Node ID 提取、UUID 比較與格式轉換。不僅是驗證工具,更是學習 UUID 的工作台。
快速樣本:
v1
v1 (DNS)
v4
v4
v7
v7 (時間)
v6
UUID 比較
UUID Byte Map
輸入 UUID 後將顯示位元組結構
格式轉換
--
--
--
--
--
常見問題 (FAQ)
UUID 是什麼?
UUID(Universally Unique Identifier,通用唯一辨識碼)是一個 128 位元的識別碼標準,用於在分散式系統中唯一標識資訊。標準格式為 32 個十六進位字元,以連字號分為五組:
UUID 的核心價值在於不需要中央註冊機構即可產生全域唯一的識別碼,這在資料庫主鍵、分散式追蹤、工作階段識別等場景中極為重要。
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx。UUID 的核心價值在於不需要中央註冊機構即可產生全域唯一的識別碼,這在資料庫主鍵、分散式追蹤、工作階段識別等場景中極為重要。
UUID v1 ~ v8 有什麼差異?
| 版本 | 時間基準 | 隨機性 | 主要用途 |
|---|---|---|---|
| v1 | 100ns 間隔 (1582-10-15) | Clock + Node | 傳統時間型 |
| v3 | — | MD5 Hash | 名稱型 (MD5) |
| v4 | — | 122 bits Random | 最常見的隨機 UUID |
| v5 | — | SHA-1 Hash | 名稱型 (SHA-1) |
| v6 | 100ns 間隔 (排序優化) | Clock + Node | 可排序時間型 |
| v7 | Unix 毫秒 | 74 bits Random | ⭐ 新標準時間型 |
| v8 | 自訂 | 自訂 | 實驗/自訂 |
RFC 4122 與 RFC 9562 的差異?
RFC 4122(2005 年)是原始的 UUID 標準,定義了 v1、v3、v4、v5 四種版本。RFC 9562(2024 年 5 月)是更新版本,新增了 v6、v7、v8,並保留了向後相容性。
主要的變化包括:
• v6 與 v1 相容但欄位重新排序,使其在資料庫中可排序
• v7 使用 Unix 毫秒時間戳,取代 v1 的 1582 年基準,更簡單且更符合現代需求
• v8 為實驗性自訂格式,允許開發者定義自己的欄位佈局
• 建議新的應用使用 UUID v7 以獲得最佳效能與可排序性
主要的變化包括:
• v6 與 v1 相容但欄位重新排序,使其在資料庫中可排序
• v7 使用 Unix 毫秒時間戳,取代 v1 的 1582 年基準,更簡單且更符合現代需求
• v8 為實驗性自訂格式,允許開發者定義自己的欄位佈局
• 建議新的應用使用 UUID v7 以獲得最佳效能與可排序性
為什麼現在推薦使用 UUID v7?
UUID v7 被推薦的主要原因:
• 可排序:高位為時間戳,因此在資料庫中按 UUID 排序即按建立時間排序,大幅提升 B-Tree 索引效能
• 高效能:不需要全域鎖定或節點 ID,產生速度快
• 隱私:不像 v1 會暴露 MAC 地址與精確時間
• 足夠隨機:74 bits 隨機部分提供約 2.4 × 10²² 種組合
• 標準化:已納入 RFC 9562,MySQL 8.0+、PostgreSQL、SQLite 等主流資料庫均支援
對於新建的系統,除非有特定的相容性需求,否則 UUID v7 通常是比 v4 更好的選擇。
• 可排序:高位為時間戳,因此在資料庫中按 UUID 排序即按建立時間排序,大幅提升 B-Tree 索引效能
• 高效能:不需要全域鎖定或節點 ID,產生速度快
• 隱私:不像 v1 會暴露 MAC 地址與精確時間
• 足夠隨機:74 bits 隨機部分提供約 2.4 × 10²² 種組合
• 標準化:已納入 RFC 9562,MySQL 8.0+、PostgreSQL、SQLite 等主流資料庫均支援
對於新建的系統,除非有特定的相容性需求,否則 UUID v7 通常是比 v4 更好的選擇。
UUID 的 Variant 是什麼?
Variant(變體)表示 UUID 的位元組佈局規範,由第 9 個位元組的高位元決定:
• NCS (0xxx):早期 NCS 格式,現已少用
• RFC 4122 (10xx):目前標準格式(最常見)
• Microsoft (110x):Microsoft GUID 相容格式
• Reserved (111x):保留給未來定義
絕大多數現代 UUID 都使用 RFC 4122 Variant,您可以透過此工具快速確認 UUID 使用的 Variant。
• NCS (0xxx):早期 NCS 格式,現已少用
• RFC 4122 (10xx):目前標準格式(最常見)
• Microsoft (110x):Microsoft GUID 相容格式
• Reserved (111x):保留給未來定義
絕大多數現代 UUID 都使用 RFC 4122 Variant,您可以透過此工具快速確認 UUID 使用的 Variant。
UUID 與 GUID 有什麼不同?
技術上幾乎沒有差異。GUID(Globally Unique Identifier)是 Microsoft 對 UUID 標準的實作,用於 Windows COM/OLE 等技術。兩者都遵循 RFC 4122 規範,格式相同(128 位元、32 個十六進位字元)。
唯一的微小差異在於 Microsoft GUID 有時會使用混合的 endian 格式輸出(在連字號分組內的位元組順序不同),但這僅影響顯示,不影響唯一性。您可以放心將 UUID 和 GUID 視為同一回事。
唯一的微小差異在於 Microsoft GUID 有時會使用混合的 endian 格式輸出(在連字號分組內的位元組順序不同),但這僅影響顯示,不影響唯一性。您可以放心將 UUID 和 GUID 視為同一回事。
什麼是 Nil UUID?
Nil UUID(也稱 Zero UUID)是全部位元組皆為 0 的特殊 UUID:
00000000-0000-0000-0000-000000000000。它不代表任何實際的識別碼,常用於表示「無值」或「未設定」的狀態,類似於資料庫中的 NULL 或程式語言中的 nil/null 概念。
UUID 完整指南
UUID 的內部結構
一個 UUID 由 128 位元組成,在標準顯示格式中表示為 32 個十六進位字元,以四個連字號分隔:
time_low
-
time_mid
-
time_hi_and_version
-
clock_seq_hi_and_reserved
clock_seq_low
-
node
以 550e8400-e29b-41d4-a716-446655440000 為例:
550e8400— time_low(4 bytes)e29b— time_mid(2 bytes)41d4— time_hi_and_version(版本 4 標示於高位)a7— clock_seq_hi_and_reserved(Variant + 高位序號)16— clock_seq_low(低位序號)446655440000— node(6 bytes,一般為 MAC 或亂數)
UUID 版本速查表
v1
時間 + MAC
v3
MD5 + Namespace
v4
完全隨機
v5
SHA-1 + Namespace
v6
排序時間型
v7
Unix 時間 + 亂數
v8
自訂格式
Nil
全零