雜湊、ID與隨機數

UUID 含時間嗎？比較 v4 與 v7

使用工具

選擇 v4 或 v7 要先明確 ID 的用途。兩者文字長度相同，但隨機為主的 v4 與前綴含時刻的 v7 排序後資訊不同。可少量產生並解析已知範例；這不直接決定資料庫效能或驗證安全。

定位版本的範例

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx  (v4)
xxxxxxxx-xxxx-7xxx-yxxx-xxxxxxxxxxxx  (v7)

UUID 為一百二十八位元，常寫三十二位十六進位加連字號，第三組首位標版本。圖中 x、y 是佔位，不是有效輸入。長度與標點相符也不等於完整格式有效。

將一個產生 UUID 貼回輸入欄，會按 UUID 解析而非件數產生。檢查 version、variant；它是單值解析，不是多行批次驗證。先確認產生與解析版本一致。

產生五個 v4，用行整理排序。v4 沒有此用途的產生時刻欄位，字典序不還原產生順序，偶然相同也非讀出時刻。需要時序時應考慮獨立建立時間或排序欄位。

隨機 ID 不同於明顯序號，但不能讓僅憑 ID 即可存取的設計自動安全。公開識別與權限檢查應分離，少量樣例不重複也不證明絕對唯一。

解析 RFC 9562 的 v7 範例

017f22e2-79b0-7cc3-98c4-dc0c0c07398f
1645557742000 ms
2022-02-22T19:22:22.000Z

解析可見版本 7、Unix 毫秒 1645557742000 與 UTC。v7 前四十八位元為 Unix 毫秒，不同時刻的標準表示排序會反映該時刻部分，與 v4 無此欄位不同。

可讀時刻不證明產生者或時鐘正確。該例就是公開固定值，可被複製或構造。解析時刻只是參考，公開 ID 還需考慮暴露時間是否合適。

同毫秒排序取決於餘位產生與狀態管理。SheepDev 使用已安裝 uuid 函式庫，但不保證跨裝置、程序、重新啟動的全球統一順序。時鐘差異也使關鍵事件順序不能只靠 ID。

資料庫 UUID 型別或自訂二進位配置的比較規則也需核對。行排序正確不證明索引或查詢相同，應以受控小資料檢查儲存、比較器與實際查詢。

時間順序可輔助儲存設計，但效能受索引、量、寫入模式與查詢影響。工具不連 DB 或測效能。先寫需要時刻型還是隨機識別；若以效能為由，應測試實際工作負載。

記錄版本、格式結果、v7 參考時刻與產生或解析操作。格式有效不等於可信，應用唯一性與權限檢查需獨立保持，區分小實驗與營運保證。