ULID 生成器

批次生成可作為 UUID 替代方案、按時間順序可排序的 ID「ULID」。

什麼是 ULID 產生

ULID 產生是指批次發行可依時刻排序的全域唯一識別碼「ULID（Universally Unique Lexicographically Sortable Identifier）」。ULID 為26個字元的 Crockford Base32 字串，前10個字元是表示產生時刻的時間戳記部分，其餘16個字元是由密碼學安全亂數構成的隨機部分。與 UUID v4 那樣的完全隨機識別碼不同，其最大特點在於可依產生順序以字串方式排序。

本工具使用 Web Crypto API 的 crypto.getRandomValues() 產生隨機部分，因此使用的是密碼學上安全的亂數源而非虛擬亂數。產生處理全部在瀏覽器內完成，輸入的件數與產生結果不會傳送至伺服器。一次最多可批次產生1,000件，並同時支援大寫（規格上的正規表記）與小寫兩種輸出。

ULID 產生的使用方式

輸入產生件數在「產生件數」中輸入希望一次發行的 ULID 個數，可在1～1000件的範圍內指定。
選擇是否需要小寫顯示若在嵌入 URL 或日誌時希望統一為小寫，請勾選「以小寫輸出」。規格上大寫與小寫均為有效表記。
按下「產生」按鈕按下按鈕後，會以目前時刻作為時間戳記部分，依指定件數批次列出 ULID。
複製結果可逐筆使用「複製」，或使用以換行分隔一併複製全部清單的「全部複製」。

用好本工具的小技巧

ULID 的前 10 個字元是時間戳（生成時刻），其餘 16 個字元為隨機值。除非在同一毫秒內生成，僅按字串排序即可還原生成時刻的先後順序。
如果資料庫主鍵使用完全隨機的 UUID v4，新行的插入位置會是隨機的，容易導致 B-tree 索引碎片化；而 ULID 大致按時間順序排列，插入位置相對連續，因此能緩解這一問題。
ULID 使用 26 個字元的 Crockford Base32 編碼（從 `0`-`9`、`A`-`Z` 中去除容易混淆的 I、L、O、U，共 32 個字元），比 UUID（含連字元共 36 個字元）更短，在不區分大小寫的環境中也能安全使用。
如需與 Nano ID、UUID v4 進行格式對比，請參閱姊妹工具「Nano ID 生成」頁面上的對比表。

ULID 產生派上用場的情境

資料庫主鍵、記錄 ID 的發行

在新資料表主鍵採用 ULID 時，可在開發初期批次準備用於測試虛擬記錄或種子資料的 ID。

事件驅動系統的事件 ID

在訊息佇列或分散式系統中為每個事件賦予唯一 ID 時，依時刻排列的 ULID 更便於按時間順序追蹤日誌。

日誌、追蹤 ID 的範例製作

可作為應用程式日誌平台或追蹤工具的運作確認、展示用資料，立即準備符合實際格式的 ID。

與其他格式 ID 的比較研究

若在 UUID v4、UUID v7 或用於短網址的 Nano ID 之間舉棋不定，可先對比實際外觀與字元數再決定採用。比較時也請一併使用UUID 產生・UUID v7 產生・Nano ID 產生各工具。

ULID 產生的相關用語

ULID: Universally Unique Lexicographically Sortable Identifier 的縮寫。是128位元的唯一識別碼，同時前48位元帶有產生時刻，因此只需以字串排序即可依時間順序排列的規格。
Crockford Base32: 由數字 0～9 與字母 A～Z 中去除外觀易混淆的 I・L・O・U 四個字元後所構成的32個字元的編碼方式。ULID 即以該方式編碼為26個字元。
單調性（monotonicity）: 指值隨時間始終持續增大的性質。ULID 在同一毫秒內產生多個時不保證順序，但使用規格所定的單調產生擴充實作，即可在同一毫秒內也維持單調遞增。
UUID: Universally Unique Identifier 的縮寫。是 RFC 4122 所規定的128位元唯一識別碼規格，使用36個字元（含連字號）的十六進位表記。與 ULID 是彼此獨立的不同規格。
分散式系統中的唯一 ID: 指多台伺服器或行程無須向中央採號器詢問，各自獨立產生互不重複識別碼的機制。ULID 與 UUID 為此用途結合產生時刻與亂數，把碰撞機率降到極小。
時間戳記部分: ULID 前10個字元所對應的部分，是把產生時刻以毫秒為單位編碼為 Crockford Base32 的48位元值。是僅憑字串比較即可得知產生順序這一機制的核心。

常見問題

ULID（Universally Unique Lexicographically Sortable Identifier，通用唯一按字典序排序識別符號）是一種與 UUID 類似、可生成全域性唯一 ID 的規範，其特點在於內含生成時刻的資訊，因此僅按字串排序即可得到按時間順序排列的結果。

最大的區別在於「是否可按生成時間排序」。UUID v4 是完全隨機的 128 位值，無法按生成順序排序；而 ULID 的前 48 位是以毫秒為單位的時間戳，僅通過字串比較就能得知生成順序。此外表示形式也不同：ULID 為 26 個字元的 Base32，UUID 則為 36 個字元（含連字元）的十六進位制數。

如果主鍵使用像 UUID v4 這樣完全隨機的值，新行在索引中的插入位置會是隨機的，容易導致 B-tree 索引碎片化並降低快取效率。由於 ULID 具有按時間順序排列的特性，新行往往會被追加到索引末尾附近，因此據說能緩解這一問題。

前 10 個字元是 48 位的毫秒級時間戳（可表示至西元約 10889 年），其餘 16 個字元是 80 位的隨機值。總計 128 位，與 UUID 的位數相同,但同時內含時間資訊，這正是 ULID 的特點。

閒話 ― 把「時間順序」帶入 ID 世界的 ULID

ULID 規範由 Alizain Feerasta 於 2016 年釋出。當時 UUID 早已是分散式系統中生成唯一 ID 的標準手段，但其「完全隨機因而無法排序」的特性，在資料庫索引效率和日誌的時間序列分析上頗為不便,ULID 正是為解決這一問題而誕生的。

事實上 UUID 也存在包含時間資訊的變體，例如版本 1（MAC 地址+時間戳）以及 2024 年標準化的版本 7（時間戳+隨機值的組合）。但 ULID 是獨立於 UUID 規範（RFC 4122）之外的獨立標準，其特點在於追求更簡單的設計以及基於 Base32 的緊湊表示形式。

如今，幾乎所有主流程式語言都有 ULID 的實現庫，它被廣泛應用於分散式系統的事件 ID、日誌的追蹤 ID、資料庫主鍵等需要保留生成順序的場景。它與同時期出現的 UUID v7 在設計理念上有諸多重合之處,二者作為「可排序的類 UUID 識別符號」這一共同課題的不同解法而並存。

檢視全部趣味知識