UUID / GUID 產生器

UUID 跟 GUID 是同一個東西嗎？

是。同一個 128 位元的值，兩個名字。GUID 是微軟的叫法，Windows 生態（登錄檔、COM、.NET、SQL Server）習慣印成大寫並用大括號包起來：{6BA7B810-9DAD-11D1-80B4-00C04FD430C8}；其他地方則寫成小寫加連字號。這只是呈現方式的差別，不是不同的識別碼——所以上面的格式選項只會改變顯示，不會改變值本身。

規範是 RFC 9562，2024 年 5 月發布，取代了 RFC 4122。舊的版本全部保留，另外新增 v6、v7、v8，所以你手上既有的 UUID 不會因此失效。

該用哪一個版本？

v7 是這裡面最值得知道的一個

v4 是均勻隨機的，也就是說連續寫入的資料會散落在索引的各個角落。對 B-tree 來說，這把「往後面接」變成「整個索引到處亂寫」：頁面分裂、快取裝不下熱區，資料表越大寫入越慢。這正是「不要用 UUID 當主鍵」這個說法的來源，而且這個說法是有道理的。

v7 把毫秒級的 Unix 時間戳放在最前面的 48 個位元，所以後產生的一定比較大。寫入會像自增整數一樣落在索引尾端，後面的隨機位元則維持不可猜測、也能在多台機器上同時產生而不衝突。把一串 v7 UUID 當純文字排序，結果就是按產生時間排序——光這一點常常就夠用了。

代價要講清楚：v7 會讓看到它的人知道它是什麼時候產生的，精確到毫秒。訂單編號無所謂，但如果是密碼重設連結或邀請碼，那可能就不能接受——那種情況請用 v4。

有一個細節是多數線上產生器沒處理的：當你一次要 100 組，它們幾乎都落在同一兩毫秒內。這裡把版本位元後面的 12 個位元當成計數器使用（RFC 明文允許的作法），所以整批是嚴格遞增的，而不是在每一毫秒內亂序。

v5：需要「算得出來」的那種情況

v5 完全不隨機。它是「命名空間 UUID + 名稱」的 SHA-1，再蓋上版本與 variant 位元。相同的命名空間與名稱，在任何機器、任何語言、任何時候都會得到同一個 UUID——當兩個系統必須對同一件事給出同樣的 id，卻又不能互相通訊時，這正是你要的東西。把網址轉成穩定的內容 id 是最典型的用法。

下拉選單裡的四個命名空間（DNS、URL、OID、X.500）是規範定義的。如果你的 id 不屬於其中任何一種，就自己產生一個 v4 UUID 當作你專案專屬的命名空間，貼進「自訂 UUID」欄位——這就是規範預期的用法。

兩個提醒。第一，這個對應關係不是秘密：任何人都能從同樣的名稱算出同樣的 UUID，所以 v5 的值不能當作權限憑證。第二，SHA-1 的碰撞弱點在這裡不構成問題（沒有簽章可以偽造），但這也是為什麼 v5 存在卻不是預設值。至於 v3，它是同一套作法改用 MD5——這裡沒有提供，因為瀏覽器的 Web Crypto 根本沒有實作 MD5，為了提供一個嚴格來說更差的版本而自己塞一份 MD5 進來並不划算。

真的不會重複嗎？

沒有「保證」，只有「機率上小到可以不管」。v4 有 122 個隨機位元，要讓「出現一次重複」的機率達到一半，你大約得產生 2.7 × 10¹⁸ 個——換算成每秒產生十億個、不停地跑，大約要跑 85 年。

真正的風險從來不是這個數學上限，而是亂數來源本身很爛。用 Math.random當種子、或跑在熵池壞掉的裝置上的產生器，可能很快就重複。這個頁面的每一個隨機位元都取自crypto.getRandomValues——瀏覽器對作業系統 CSPRNG 的介面——而且在它不可用時直接拒絕產生任何東西。

存進資料庫

一個 UUID 是 16 個位元組。寫成字串是 36 個字元，加大括號 38 個，去掉連字號 32 個。用 CHAR(36) 存不只多花一倍以上的空間，還讓每一次索引比較都變成字串比較。多數資料庫都有原生型別（PostgreSQL 的 uuid、MySQL 的 BINARY(16)、SQL Server 的uniqueidentifier）可以直接存位元組。順帶一提，MySQL 的UUID_TO_BIN(x, 1) 會把 v1 的時間欄位對調以便排序——如果你用 v7，完全不需要這個技巧。

常見問題

UUID 可以拿來當安全性 token 嗎？

由加密亂數產生的 v4 有 122 位元的熵，確實足以不可猜測。但 v1 與 v7 有很大一部分是時間戳，本質上可預測；而且不少函式庫產出的「v4」其實來自非加密的 PRNG。如果這個值必須不可猜測，請刻意去產生一個 token，而不是隨手抓一個 UUID 來賭。

為什麼 v1 裡面沒有我的 MAC 位址？

因為瀏覽器讀不到，也不應該讀得到。規範對這種情況有明確規定：拿不到硬體位址時，改用隨機的節點 id 並把 multicast 位元設為 1，這裡就是這麼做的。而 v1 原本的設計會把機器的 MAC 位址寫進它產生的每一個識別碼裡——這正是 v1 後來不受歡迎的原因。

你們會記錄產生的 UUID，或是在伺服器上產生嗎？

都不會。產生器就是已經下載到你瀏覽器裡的 JavaScript——把網路斷掉再按「重新產生」，它照樣能用。也不會儲存任何東西，重新整理畫面上的結果就沒了。

可以一次產生超過 100 組嗎？

按鈕上沒有這個選項。如果你需要成千上萬個，請在需要它的地方產生：每個語言都有 UUID 函式庫，現在的瀏覽器與執行環境也內建 crypto.randomUUID()，一行就給你一個 v4。

可以用大寫嗎？

讀可以，寫不建議。RFC 9562 要求產生器輸出小寫、解析器必須兩種都接受——所以這裡的大寫選項是為了貼進吃 Windows 風格的工具，不是拿來當儲存格式的。