RevealTheme logo

UUID產生工具

產生UUID v4(通用唯一識別碼,隨機版)。每次點擊都會產生一個新的。

如何使用本工具

  1. 1

    Click the Generate UUID button to produce a fresh random v4 UUID.

  2. 2

    Read the 36-character identifier shown in the canonical 8-4-4-4-12 format below the button.

  3. 3

    Click Copy to put the UUID on your clipboard for pasting into code, a database, or a config file.

  4. 4

    Click Generate UUID again whenever you need another one — every click replaces the value with a brand-new random UUID.

什麼是UUID,軟體為什麼要使用它?

UUID(Universally Unique Identifier,在微軟的語境中有時稱為GUID)是一個128位元的值,用於在無需系統間協調的情況下標識實體。UUID的核心理念在於:兩個互不知曉、執行在兩台不同機器上的不同程式,可以各自產生UUID,並滿懷信心地認定它們絕不會發生衝突。這一特性使分散式系統設計成為可能:你可以讓任意服務在本地鑄造識別碼而無需中央計數器,可以在不重新編號資料列的情況下合併資料庫,還可以在伺服器尚未看到請求之前就在用戶端預先產生識別碼。UUID有五個由RFC 4122定義的規範版本:v1(基於時間+MAC位址,會洩漏建立時間和機器身分)、v3(命名空間+名稱的MD5雜湊)、v4(隨機,最常用)、v5(命名空間+名稱的SHA-1雜湊)。RFC 9562又新增了v6(按時間排序,類似v1但不洩漏MAC)和v7(Unix時間戳記+隨機,專為資料庫主鍵設計,因為它按時間先後排序)。本工具透過crypto.randomUUID()產生UUID v4,它使用來自瀏覽器底層作業系統的、具備密碼學強度的隨機性,這與TLS金鑰的來源是同一個。其輸出與Python的uuid.uuid4()、Node的crypto.randomUUID()以及Go的google/uuid.NewRandom()逐位元組完全一致。

常見使用場景

  • 資料庫主鍵:當你需要合併資料庫或在用戶端產生識別碼時,用它取代自動遞增整數。

  • Cookie中的工作階段識別碼:長度足夠,使得透過暴力猜測出一個有效的工作階段ID在計算上不可行。

  • API請求的冪等性鍵:可安全地重試請求;伺服器會按UUID去重。

  • 上傳檔案的識別碼:以UUID命名上傳的檔案,可避免路徑衝突,並且不暴露原始檔案名稱。

  • 分散式追蹤識別碼:每個請求都會獲得一個UUID,並在各服務之間傳播,用於關聯記錄。

  • 測試資料識別碼:為測試資料提供可預測的隨機性,無需在各測試案例之間協調識別碼。

常見問題

v4是什麼意思?
版本4:它由122位元隨機性加上6位元固定的版本/變體位元產生。其他版本:v1基於時間戳記+MAC(不要使用;它會洩漏機器身分和時間),v3/v5是命名空間+名稱的確定性雜湊(適用於穩定的衍生識別碼),v7是帶時間戳記前綴的隨機版(非常適合資料庫,因為它按時間先後排序)。對於大多數場景,v4是正確的預設選擇。
UUID到底有多唯一?
UUID v4擁有122位元有效隨機性:即5.3×10^36個可能的值。你需要產生約2.71×10^18個UUID,才會達到50%的衝突機率。作為參照,即便你每秒產生十億個UUID,也需要85年才能達到這個臨界點。在使用良好的隨機數產生器時,實際中不會發生衝突。
資料庫主鍵應該用v4還是v7?
v7更適合資料庫。UUID v4是隨機的,這意味著新的資料列會隨機分散到B-tree索引各處,導致索引膨脹,並在大規模下造成插入緩慢。v7將時間戳記置於前部,因此新的UUID總是排在舊的之後,從而保持順序插入的模式。PostgreSQL、MySQL和SQL Server都能從v7中獲益。如果你的函式庫尚不支援v7,ULID是一個具有相同特性的流行替代方案。
使用crypto.randomUUID()安全嗎?
安全。它由WHATWG規範定義,並在所有現代瀏覽器中透過作業系統的密碼學隨機數產生器實作(與TLS金鑰的來源相同)。其輸出不可預測,並均勻分布在整個UUID v4空間中。
UUID和GUID有什麼區別?
它們在功能上完全相同:GUID是微軟對同一概念的稱呼。位元組格式在某些微軟API中有所不同(.NET的Guid.ToByteArray()在前三個欄位中使用混合位元組序),因此當互通性很重要時,要留意位元組序。規範的字串格式(8-4-4-4-12)是一致的。
我可以縮短UUID以用於URL嗎?
可以:將這128位元編碼為Base62或Base64,而不使用規範的十六進位格式。Base62會得到22個字元;Base64帶填充時為22個字元,其URL安全變體也為22個字元。某些函式庫還使用「短UUID」格式。底層的位元不會改變;只是顯示用的編碼有所不同。
為什麼我的UUID開頭幾個字元和另一個相同?
這是巧合:UUID v4是隨機的。總共有36個十六進位字元,而其中只有22個是隨機的十六進位字元(4個保留給版本/變體,4個是連字號),因此當你產生大量UUID時,出現一些前綴重合在所難免。即便前綴相同,完整的UUID仍然是唯一的。

相關工具