UUID v7 時間戳解碼

只需貼上UUID v7字串,即可提取其前48位中嵌入的毫秒級時間戳並還原為UTC日期時間。可檢測非v7版本及variant異常,是姊妹工具「UUID v7生成」的逆向工具。

UUID v7的位元佈局

位元範圍 欄位 說明
0-47 unix_ts_ms 自Unix紀元起的毫秒數,以大端序儲存。本工具提取的值。
48-51 version UUID的版本號。v7固定為0111(十六進位制為7)。
52-63 rand_a 12位隨機值。部分實現用它來保持同一毫秒內的順序。
64-65 variant 表示RFC 4122/9562變體的固定值10。十六進位制表示時開頭為8/9/a/b。
66-127 rand_b 62位隨機值,用於避免衝突的熵源。

什麼是 UUID v7 時間戳記提取

UUID v7 是2024年由 RFC 9562 標準化的新版本,前 48 位元內嵌了以毫秒為單位的 Unix 時間戳記,也就是「產生時刻」。因此排序後會按產生順序排列,用作資料庫主鍵時索引也不易碎片化。本工具只需貼上 UUID 字串,就會取出前 48 位元並還原為 UTC 日期時間。

同時也會判定版本(version)與 variant。即使輸入非 v7 的 UUID 也照樣計算時間戳記,並附上「這不是 v7」的警告。像 v4 那樣的隨機 UUID 會得到無意義的日期,但這對於理解各版本 UUID 究竟包含什麼資訊很有幫助。工具還會顯示位元配置表,可確認前 48 位元之後放的是什麼。所有處理都在瀏覽器內完成。

從 UUID 取出時間戳記的步驟

  1. 貼上 UUID 以 8-4-4-4-12 的連字號分隔 36 字元格式輸入。大小寫不拘。
  2. 確認版本與 variant 若為 v7 則不會出現警告;非 v7 時會顯示「不是 v7」的警告。
  3. 閱讀還原的日期時間 會以 Unix 毫秒、ISO 8601(UTC)、你所用裝置的本地時間三種形式顯示。
  4. 看位元配置表了解結構 可確認前 48 位元的時間戳記之後,版本、variant、亂數分別落在哪些位元。

用好本工具的小技巧

  • 解碼處理完全在瀏覽器內的JavaScript中完成,輸入的UUID不會發送到toolbase.cc伺服器。
  • 如果資料庫主鍵使用UUID v7,即使沒有專門的created_at欄位,只需貼上主鍵即可還原該記錄的建立時間。
  • 輸入非v7版本的UUID(如v4)會觸發警告,但仍會顯示從前48位機械提取的參考值,可用於瞭解不同格式之間的差異。
  • 如需生成UUID,可使用姊妹工具「UUID v7生成」,它生成的UUID可直接用本工具反向解碼。
  • 將日誌檔案或API響應中的UUID v7逐個貼上到此處,有助於在除錯外部系統時估算事件發生的大致時間。

這些場景下會用到

從日誌中的 UUID 推出發生時刻

即使日誌沒有時間欄位,只要主鍵是 v7 就能還原產生時刻,在排查故障、追溯前後關係時很有效。

確認主鍵是否按產生順序

依序放入多筆記錄的 UUID,即可確認實作是否真的產生時間有序的值。

評估是否採用 v7

實際放入值看看能取出什麼,就能明白「時間可被外部讀取」這項性質的意義。若該時間屬於敏感資訊,這就成了缺點。

辨別 UUID 的版本

收到的 UUID 是 v4 還是 v7,肉眼難以分辨,本工具可立即判定。

UUID 的相關術語

UUID v7
RFC 9562 標準化的版本,前 48 位元帶有 Unix 毫秒時間戳記。可按時間排序是與 v4 最大的差異。
version(版本)
位於第 13 個十六進位位置的數字,表示 UUID 的產生方式。v7 時此處為 7。
variant
與版本不同,表示 UUID 內部配置的值。遵循 RFC 9562 的 UUID 其第 17 位為 8、9、a、b 之一。
Unix 毫秒
自 1970 年 1 月 1 日 00:00:00 UTC 起經過的毫秒數。48 位元足以表示到西元 10889 年。
與 UUID v4 的差異
v4 幾乎整體都是亂數,完全不帶產生時刻的資訊。 因此排序不會得到產生順序,但相對地時間也無法被外部讀取。

常見問題

UUID v7在RFC 9562中被標準化,其128位中的前48位以大端序固定嵌入毫秒級Unix時間戳。因此只需將前12位十六進位制數字轉換為數值並按毫秒解釋,即可還原生成時間。

由於UUID v4是完全隨機的,從中提取出的"時間戳"是與實際建立時間無關的無意義數值。本工具會檢查版本位並顯示警告,但仍會展示從前48位機械提取的結果供參考。

根據UUID v7規範,精度為毫秒級。如果在同一毫秒內生成了多個UUID v7,其前48位將完全相同,無法還原它們的生成順序,區分工作完全交由rand_a和rand_b的隨機值負責。

符合RFC 4122/9562的UUID要求第4組開頭的十六進位制數字必須為8、9、a或b之一。若為其他值(0-7或c-f),可能意味著採用了自定義ID生成邏輯或位元損壞,因此會顯示警告。
工具君

閒話 ― 讓UUID內建一塊"時鐘"

UUID v7的劃時代之處在於,識別符號本身永久保留了生成時間這一資訊。在舊版UUID v4中,要知道記錄的建立時間必須依賴單獨的created_at欄位,而若主鍵使用UUID v7,則僅憑ID字串本身即可機械地還原生成時間。本工具正是作為姊妹工具"UUID v7生成"的逆向流程提供這一還原功能。

這一特性在故障排查和資料遷移場景中尤為有用。例如舊日誌中留存的訂單ID,或從外部系統接收到的事件ID若為UUID v7格式,無需查閱專門的時間戳欄位即可立即確認該記錄大致的建立時間。這對缺失created_at欄位的舊系統排查,以及解析其他公司發行的UUID v7同樣適用。

不過也需注意幾點:UUID v7的時間戳完全依賴生成端的系統時鐘,若生成伺服器的時鐘不準,提取結果也會隨之偏差。此外,本工具對UUID v4等其他版本同樣會機械地提取出"疑似時間戳",這僅僅是對位元位置的解讀,並不保證該值具有實際意義,使用時請留意這一點。