UUID v7 生成器
在瀏覽器中批次生成 RFC 9562 標準的 UUID v7 ——前 48 位內嵌毫秒級時間戳，使 ID 可按生成順序排序。支援標準、大寫、無連字元、帶花括號、URN 等多種格式，且可直接存入現有的 UUID 型別列。
UUID v7、UUID v4 與 ULID 的比較
| 形式 | 長度 | 是否可按生成順序排序 | 與現有 UUID 型別列的相容性 | 說明 |
|---|---|---|---|---|
| UUID v7 | 36 個字元（含 4 個連字元） | 是（前 48 位為毫秒級時間戳） | 有（保持標準 UUID 型別、十六進位制表示） | 由 RFC 9562 標準化。由 Unix 時間戳與隨機值組成，兼顧按時間順序排序與既有 UUID 資產的相容性。本工具生成的正是此格式。 |
| UUID v4 | 36 個字元（含 4 個連字元） | 否（完全隨機） | 有（標準 UUID 型別） | 由 RFC 9562 標準化的完全隨機 128 位識別符號，不包含生成來源資訊，是目前應用最廣泛的形式。 |
| ULID | 26 個字元 | 是（前 10 個字元為時間戳） | 無（使用 Base32，需額外的列型別轉換） | 獨立於 UUID 標準（RFC 4122/9562）之外的 Crockford Base32 規範。比 UUID v7 更短，但無法直接存入原生 UUID 型別列。 |
什麼是 UUID v7
UUID v7 是2024年5月由 IETF 在 RFC 9562 中標準化的、可依時刻排序的新型 UUID（Universally Unique Identifier）。此前廣泛使用的 UUID v4，其128位元全部為完全隨機值，因而沒有線索可循產生順序；而 UUID v7 在前48位元帶有毫秒級的 Unix 時間戳記，只需作為字串排序即可依產生順序排列。其餘位元由隨機值填滿，因此即便在同一毫秒內產生多個，唯一性仍得以保持。
本工具使用 Web Crypto API 在瀏覽器內產生 UUID v7，並以標準、大寫、無連字號、大括號、URN 形式中的任一種批次輸出。該表記與既有的面向 UUID v4 的資料庫欄位完全相容，無須變更欄位型別即可直接儲存，這正是其特點。若想確認產生的值是否依時間戳記排列，可用姊妹工具UUID v7 解碼工具取出其中嵌入的時刻加以核對。
UUID v7 的產生步驟
- 指定產生件數 在「產生件數」中輸入一次所需的 UUID v7 個數。若想批次製作測試資料，可指定多筆。
- 選擇顯示形式 按儲存目標資料庫或系統的規格，從標準、大寫、無連字號、大括號、URN 形式中選擇。
- 按下「產生」按鈕 會由瀏覽器內的 Web Crypto API 即時產生，並在結果欄中列出。不會向伺服器傳送。
- 複製結果 可逐筆使用「複製」按鈕，若要整體使用則用「全部複製」按鈕取入剪貼簿。
用好本工具的小技巧
- 生成的 UUID v7 全部在瀏覽器內通過 JavaScript（Web Crypto API）處理，不會發送到 toolbase.cc 的伺服器。
- UUID v7 的前 48 位是毫秒級 Unix 時間戳，因此只需按字串排序即可還原生成時刻的先後順序。
- 可直接存入現有存放 UUID v4 的資料庫列（如 CHAR(36) 或 PostgreSQL 的 uuid 型別），遷移時無需改動應用層的型別定義。
- 「無連字元」格式便於用作 URL 路徑段或檔名；「帶花括號」格式則與 Windows COM/登錄檔中使用的 GUID 表示法一致。
- 如果在 UUID v7 與 ULID（Crockford Base32、26 個字元）之間猶豫不決：現有系統已假定使用 UUID 型別列時選 UUID v7，追求更短字串時選 ULID。
UUID v7 派上用場的情境
資料庫主鍵設計
相比 UUID v4，插入位置更易呈時間順序，可在抑制 B-tree 索引碎片化的同時，繼續沿用既有的 UUID 型別欄位。
分散式系統中的 ID 採號
多台伺服器與微服務無須倚賴中央的序列發行者，即可各自獨立產生唯一且依時刻排列的 ID。
日誌、事件的識別碼
將 UUID v7 用於存取日誌或事件歷程的 ID，僅憑 ID 的大小即可掌握大致的發生順序，無須另設專門的時間戳記欄位。
測試資料、虛擬記錄的批次製作
在開發、驗證環境中投入大量虛擬記錄時，批次產生並複製後，即可直接用於 SQL 的 INSERT 敘述或 API 的測試酬載。
想確認產生結果的內容時
若想核實產生的 UUID v7 是否真的嵌入了正確的時間戳記，可用UUID v7 解碼工具；若需要隨機產生的 UUID v4，則可用UUID 產生工具因應。
UUID v7 的相關用語
- UUID v7
- 在 RFC 9562 中標準化的、前48位元帶有毫秒級 Unix 時間戳記的 UUID 版本。既可依時刻排序，又保持了與既有 UUID 型別欄位的相容性。
- 依時間戳記排序的 ID
- 指值本身含有產生時刻的資訊，只需作為字串或數值排序即可依發生順序排列的識別碼。UUID v7、ULID、Snowflake ID 等均屬此類。
- 與 UUID v4 的差異
- UUID v4 的128位元全部為完全隨機，不含產生順序的資訊；而 UUID v7 的前48位元為時間戳記，故可得知產生順序。表記形式（36個字元、十六進位）本身兩者相同。
- 單調性（monotonicity）
- 指值依產生順序單調遞增的性質。UUID v7 在同一毫秒內產生多個時，視實作而定可能僅由隨機部分的大小左右順序，因此嚴格的單調性並非規格上的必備要件，而取決於實作。
- 索引區域性
- 指在資料庫的 B-tree 索引中，新插入的值聚集於既有資料附近（多為末尾）的性質。UUID v7 的值依時間戳記排列，區域性高，較之完全隨機的 UUID v4 更易改善插入時的頁分裂與快取效率。
- RFC 9562
- 2024年5月由 IETF 公開的、規定 UUID 規格的標準文件。它取代了此前的 RFC 4122，並新增了可依時刻排序的 v6、v7 以及可處理自訂欄位的 v8。
常見問題
閒話 ― UUID v7 如何把「時間」帶回 UUID 家族
UUID v7 於 2024 年 5 月作為 IETF RFC 9562 標準化，這是自 2005 年最初的 RFC 4122 釋出約二十年以來 UUID 規範的首次重大修訂。此次修訂新增了可排序的 v6、v7 變體，以及支援自定義欄位的 v8，其背景正是 UUID v4 完全隨機的特性長期以來被指出不利於資料庫索引效率這一問題。
UUID v7 的設計與本站的姊妹工具 ULID 非常相似：兩者都將毫秒級時間戳置於前部，其餘部分以隨機值填充。決定性的區別在於表示形式——ULID 採用獨立於 UUID 標準之外的 26 位字元 Crockford Base32 格式，而 UUID v7 則延續了自 RFC 4122 以來的 36 位字元十六進位制表示。正因如此，UUID v7 能夠直接沿用既有的 UUID 型別列、庫以及 API 規範而無需任何改動。
事實上，UUID v7 釋出後不久便迅速獲得主流資料庫與語言執行時的支援。PostgreSQL 自 18 版本起內建了 uuidv7() 函式，其他主流語言與 ORM 中支援 v7 生成的庫也在快速增加。「可按時間順序排序」的便利性與「不破壞既有 UUID 資產」的相容效能夠兼得，正是 UUID v7 與 ULID 一同被迅速採納的原因。