ULID 生成器頁面概覽
本頁面專為產生 ULID（Universally Unique Lexicographically Sortable Identifier）而設計。你只需設定格式為 ULID，輸入介於 1 至 100 之間的數量，工具便會立即生成一組唯一的、可按時間排序的 26 字元識別碼。每個 ULID 是一個不含連字號、大小寫不敏感的字串，可直接個別點擊複製，或一次過複製整份清單。狀態列會顯示「Ready.」、「Generated.」及「Copied all!」等訊息，對應不同操作階段。
與同一工具內的其他格式（如 UUID v4、NanoID）相比，ULID 的獨特之處在於：它比 UUID 短（26 對 36 字元），只使用 Crockford 的 base32 字母表，因此大小寫不敏感且不含連字號；同時其前 10 個字元編碼了毫秒精度的時間戳，使整個識別碼可以按建立時間進行字典排序。這讓 ULID 在需要可排序、URL 安全且較短識別碼的場景中尤其實用。
本頁面沒有提供「大寫」或「連字號」的切換選項，因為 ULID 本身已大小寫不敏感且無連字號。
ULID 的內部結構與時序排序原理
ULID 的底層是 128 位元資料，分為兩個部分：
- 時間戳（48 位元）：編碼自 Unix 紀元以來的毫秒數，對應前 10 個字元。這 48 位元足以涵蓋約 8,925 年（2^48 毫秒），因此短期內不會溢出。
- 隨機分量（80 位元）：使用瀏覽器提供的強隨機性（
crypto.getRandomValues()）產生，對應後 16 個字元。80 位元隨機空間提供約 2^80 ≈ 1.2 × 10^24 種可能，碰撞概率在實際使用中極低。
時間戳以毫秒為單位，這使得在同一毫秒內產生的多個 ULID 不保證嚴格的時間順序——因為時間戳部分相同，排序將依賴隨機部分，而隨機部分不反映時間先後。這是 ULID 設計中明確接受的權衡：它提供巨觀的時間排序性，而非微觀順序。
編碼方式採用 Crockford 的 base32 字母表（0-9, A-Z，但排除 I、L、O、U 以避免視覺混淆）。這套字母表讓 ULID 字串大小寫不敏感：例如「ABC」與「abc」被視為相同值，這在人工抄寫或輸入時大幅減少錯誤。同時，所有使用的字元均屬 RFC 3986 中的非保留字元，無需百分號編碼即可在 URL 中使用。
與 UUID v4 及 v7 的關鍵比較
| 特性 | ULID | UUID v4 | UUID v7 |
|---|---|---|---|
| 長度（字元） | 26 | 36（含 4 個連字號） | 36（含 4 個連字號） |
| 大小寫敏感 | 不敏感（Crockford base32） | 通常不敏感（十六進制） | 通常不敏感（十六進制） |
| 連字號 | 無 | 4 個 | 4 個 |
| 時間排序性 | 是（毫秒精度） | 無（完全隨機） | 是（毫秒精度） |
| 表示法 | 字母數字（不含 I、L、O、U） | 十六進制（0-9, a-f） | 十六進制（0-9, a-f） |
| URL 安全 | 內建（無需轉義） | 需要連字號保留或不使用連字號 | 需要連字號保留或不使用連字號 |
UUID v7 近期已被標準化（RFC 9562），它也包含時間戳，但表示方式仍為 36 字元的帶連字號十六進制。ULID 則透過 Crockford base32 將長度縮減了約 28%，同時保持相同的 128 位元空間。對於希望減少儲存空間或改善可讀性的系統，ULID 提供了一個更緊湊的選擇。
生成規則與邊際情況
- 數值限制：每次生成數量必須是 1 至 100 的整數；超出範圍時不會執行。
- 重新生成：變更任何選項（格式、數量等）都會觸發重新產生，舊清單會立即被取代。
- 本地生成：所有隨機數均來自瀏覽器的
crypto.getRandomValues()方法，整個過程在用戶端完成，沒有任何資料傳送至伺服器。這確保了隱私，也與依賴伺服器端 API 的生成工具形成對比。 - 同一毫秒內的排序：兩個 ULID 若在同一毫秒建立，其排序由隨機部分決定，無法保證按物理時間先後排列。這在需要嚴格順序的場景（例如分散式交易日誌）中需留意。
- 碰撞概率：假設每毫秒產生 1,000 個 ULID，80 位元隨機空間的碰撞概率約為 (1e3)^2 / (2 * 2^80) ≈ 4 × 10^-15，遠低於實用門檻。但在極高生成速率（例如每秒百萬個）下，仍應考慮使用更長的隨機部分或內建序列號的方案。
適用場景與目標用戶
- Web 與流動應用開發者：需要比 UUID 更短、可直接用於 URL 且能按時間排序的識別碼，減少資料庫索引碎片並簡化除錯。
- 資料庫管理員：設計主鍵時，時間排序的識別碼可以改善 B-tree 索引的插入性能，因為新記錄大致按遞增順序寫入，減少頁面分裂。
- 分散式系統架構師：在多節點環境下，不依賴中央序列器即可產生全域唯一、可排序的 ID，同時保持 128 位元空間的足夠唯一性。
- API 設計者：暴露對外 ID 時，ULID 的大小寫不敏感特性可避免用戶因大小寫不一致而導致的查詢失敗，且無連字號使複製與傳遞更直觀。
- 任何覺得 UUID 過長或結構笨重的人：ULID 提供了一個即插即用的替代方案，在相同位元空間下減少約 28% 的字元數。
此外，由於 ULID 是以字典順序排序，當你將多個 ULID 按字母排列時，它們會大致按照建立時間先後排列（雖然同一毫秒內不保證順序）。這在日誌分析、事件溯源等場景中非常有用：不需要額外的時間戳欄位，僅憑 ID 字串即可判斷事件發生的相對順序。
常見問題 FAQ
問：ULID 是否保證全域唯一？
答：ULID 的隨機部分提供 80 位元（2^80 ≈ 1.2 × 10^24）的空間，加上時間戳的毫秒粒度，在合理生成速率下碰撞概率極低。但它不是像 UUID 那樣的標準——它沒有強制要求使用符合規範的隨機源或唯一的節點標識。在單一瀏覽器內使用 crypto.getRandomValues() 生成的 ULID，對於大多數應用已足夠唯一；但在跨機器的高並發環境，若需要絕對保證，應考慮加入節點 ID 或使用分散式序列碼。
問：為什麼 ULID 大小寫不敏感？
答：因為它採用 Crockford 的 base32 字母表，該字母表明確將 I 與 L、O 與 0、U 與 V 等相似字元合併，並規定大小寫字母等效。例如「A」和「a」解碼為相同的 10（十進制）。這使得人工輸入或朗讀時不易出錯，尤其在電話通知或印刷文件場合。
問：我可以在 URL 中直接使用 ULID 嗎？
答：可以。ULID 只包含 0-9、A-Z（排除 I、L、O、U），這些字元在 RFC 3986 中均屬於「unreserved characters」，無需百分號編碼。因此你可以直接將 ULID 放入 URL 路徑或查詢參數中，不影響 URL 結構。
問：同一毫秒產生的多個 ULID 順序是否保證？
答：不保證。時間戳部分相同時，排序由隨機部分決定，而隨機部分的生成時序不一定反映物理時間先後。若你的應用需要嚴格的同一毫秒內順序，應考慮在 ULID 之前加入遞增序號，或改用其他配有序列號的方案（如 UUID v7 的變體）。
問：為什麼這個頁面沒有大寫或連字號的設定？
答：因為 ULID 本身的大小寫不敏感特性和無連字號格式是其設計的一部分。提供這類切換會混淆用戶——例如，若輸出包含連字號，則不再是標準 ULID。本頁面專注於生成完全符合 ULID 規範的識別碼，因此移除這些不必要的選項。
問：我可以生成超過 100 個 ULID 嗎？
答：本頁面限制每次生成數量為 1 至 100 個。如果你需要更多，可以多次操作並手動合併結果。這是為了避免一次性輸出過多內容影響瀏覽器效能，同時保持介面簡潔。