本工具提供一個便捷的介面，用於產生多種主流格式的唯一識別碼（Unique Identifier），包括 UUID v4、UUID v7、ULID 及 NanoID。使用者可根據系統架構的需求，自由選擇格式、調整產生數量，並針對特定格式自訂外觀或結構。
唯一識別碼格式的技術差異
不同的識別碼格式在結構、隨機性及排序能力上各有側重，適用於不同的應用場景：
- UUID v4：提供 122 位元的隨機安全性，並以標準的 36 字元格式（包含連字號）呈現。其生成結果完全隨機，不具備任何時間順序。
- UUID v7：同樣採用 36 字元的標準格式，但其結構開頭包含一個毫秒級的時間戳記。這使得 UUID v7 具備時間可排序性，能有效提升資料庫索引的寫入效能。
- ULID：長度為 26 個字元，不區分大小寫。與 UUID v7 類似，ULID 開頭亦包含時間戳記，支援按建立時間排序，但採用了更緊湊的文字編碼格式。
- NanoID：預設長度為 21 個字元，不具備時間順序，其特點在於輕量且允許使用者完全自訂長度與所使用的字元集。
參數配置與產生規則
本工具支援在 1 至 100 之間（包含 1 和 100）指定每次產生的識別碼數量。當調整任何配置選項時，系統皆會即時重新產生新的識別碼。
針對不同的格式，工具提供以下專屬的自訂選項：
| 格式 | 可配置選項 | 預設值與限制 |
|---|---|---|
| UUID v4 / v7 | 大寫、包含連字號 | 預設為小寫、帶連字號的 36 字元格式 |
| ULID | 無額外外觀選項 | 26 字元，不區分大小寫 |
| NanoID | 長度、字元集 | 長度範圍 2 至 36（預設 21）；字元集須包含至少 2 個不同的字元 |
在產生 NanoID 時，若將字元集欄位修改為僅剩單一字元，將觸發驗證錯誤，此時系統會顯示錯誤訊息「字元集至少需要 2 個不同的字元。」，同時清空產生結果，將識別碼計數歸零，並停用全部複製功能。
時間排序與碰撞阻力
在資料庫設計中，選擇識別碼格式往往需要在「排序性」與「隨機性（抗碰撞能力）」之間取得平衡。
UUID v4 與 NanoID（於預設長度下）擁有極高的隨機位元數，能提供極強的抗碰撞保護，適合用於需要完全不可預測、無規律的安全性場景。然而，這類完全隨機的 ID 若作為資料庫主鍵，在寫入聚簇索引時會導致頻繁的頁面分裂，影響寫入效能。
UUID v7 與 ULID 則引入了時間戳記，解決了資料庫索引的排序問題。這兩種格式在毫秒級別上是大致可排序的，但若在同一毫秒內產生多個 ID，它們並不能保證絕對的先後順序。此外，由於部分位元被分配給時間戳記，其隨機位元數（約為 80 位元）會低於純隨機格式，因此不建議將其用作高安全要求的加密金鑰。
本地端處理與隱私保護
本工具的識別碼產生流程完全在用戶端的瀏覽器中執行。系統利用瀏覽器內建的強隨機數產生器（Cryptographically Secure Pseudorandom Number Generator）來確保識別碼的隨機強度與安全性。在整個操作過程中，所有輸入的自訂字元集及產生的識別碼均不會傳送到 BroBroGo 伺服器，確保資料處理的隱私性。
常見問題
UUID v4、UUID v7、ULID 和 NanoID 有何分別？
UUID v4 是 122 位元純隨機數，採用大家熟悉的 36 碼格式，但順序完全隨機，對數據庫索引不太友善。UUID v7 保留同樣的格式，但開頭帶有毫秒級時間戳記，產生順序大致依建立時間排列，很適合當主鍵。ULID 用同樣的時間優先概念，編碼成更短、不分大小寫的 26 碼字串。NanoID 完全捨棄排序，換來更短、可自由自訂長度與字元集的 ID。
這些 ID 夠隨機、猜不出來嗎？
夠。每個 ID 都用瀏覽器內的加密強度隨機來源產生，而不是可預測的隨機數。UUID v4 和 NanoID 預設字元集的隨機性都遠超過 100 位元。UUID v7 和 ULID 會拿大約 48 位元的隨機性換成開頭的時間戳記，所以這兩種格式適合當作可排序的 ID，不適合當成金鑰使用。
NanoID 的長度和字元集可以自訂嗎？
可以。切換到 NanoID 模式後，這裡會出現長度滑桿（預設 21 碼，和官方函式庫一致）和可編輯的字元集欄位。縮短長度或收窄字元集都會降低抗碰撞能力，字元集越窄就越該把長度調高一些。