跳至主要內容
Lizely

ULID 產生器

從加密隨機性產生單調的 ULID 批次，並解碼內嵌的毫秒時間戳。

隱私權：你的檔案不會離開裝置，所有處理均在瀏覽器本機完成。

使用方式

  1. 1.選擇「產生」，設定數量從 1 到 100，並產生一個單調批次。
  2. 2.複製完整的識別碼，並儲存在大小寫保留的欄位中，並設定唯一約束。
  3. 3.選擇「解碼」，貼上一個標準的 ULID，並讀取其毫秒與 UTC 時間戳。

關於ULID 產生器

ULID 產生器會產生符合標準的普遍唯一詞序可排序識別碼，並解碼其內嵌的時間戳。一個 ULID 由 26 個 Crockford Base32 字元組成：前 10 個字元編碼 Unix 毫秒時間戳，後 16 個字元則編碼 80 位元的隨機性。可點選一次從 1 到 100 的值產生，或切換至「解碼」功能，讀取已有標準字串中的時間戳與 ISO UTC 時間。

產生過程使用瀏覽器的加密隨機來源取得初始 80 位元值。每個批次中的 ID 會使用相同的捕捉毫秒值，並在隨機區域遞增一，含進位，因此產生的字串在正常 ASCII 詞序中嚴格遞增。若 80 位元欄位會溢位，產生將失敗，不會迴圈。此設計實現批次內的單調行為，且不儲存識別碼或跨點選的隱藏狀態。

時間戳必須符合 ULID 48 位元的無符號範圍，從零到 281474976710655 毫秒。因此最大標準字串以 7 開頭；任何以 26 字元的 Base32 值開頭且大於 8 的值，包含超過 128 位元，將被拒絕。字元集合排除 I、L、O、U 以減少混淆。解碼為不區分大小寫，但僅接受標準字元集合經標準化後的字元。

時間欄位讓 ULID 可用於有序索引與日誌關聯，但也會暴露大約的產生時間。若該元資料敏感，請勿使用 ULID。詞序排序假設使用標準的 26 字元表示法，以及通常的位元組或 ASCII 相容的排序方式。若進行大小寫轉換、地區化排序、截斷、填充或儲存在容量不足的欄位中，將會破壞預期的順序。請測試資料庫的確切排序規則與資料表結構。

隨機性可降低碰撞機率，但無法提供絕對的唯一性保證。穩固的資料庫應建立唯一約束並以原子方式處理衝突。本工具僅驗證批次構造與單調溢位，無法與其他標籤、裝置、服務或先前產生的值協調。請勿將「檢查後插入」作為最終的唯一性控制機制。

識別碼不是密碼、API 金鑰、承載令牌、授權規則或加密金鑰。顯示的時間戳與隨機字尾無法保護記錄免於列舉或洩露，若缺乏適當的存取控制。應使用目標平臺的專用機制產生憑證，並儲存在秘密管理器中。避免在與個人或機密資料相關聯的情況下記錄 ULID。

所有產生、解碼、格式化與複製操作皆在瀏覽器中完成。不會上傳任何識別碼或時間戳。頁面僅在點選「產生」按鈕時使用 Date.now，伺服器端渲染期間不會使用，因此初始頁面內容為確定性。顯示的 ISO 時間為 UTC；當地日曆顯示可能因時區而異，但毫秒值保持不變。

八個外部測試案例固定了零值、Base32 邊界、一秒、參考解碼時間範例以及最大時間戳。額外測試確認三項元素的決定性單調批次、字元集大小、不合法的 130 位元輸入以及隨機溢位。為確保可靠使用，請保留完整大寫字串，儲存在大小寫保留的 26 字元欄位中，強制唯一性，並將解碼時間視為元資料，而非認證真實。

方法與來源

每次點選會捕捉一個整數毫秒，將其編碼為 10 個 Crockford Base32 字元，取得 80 個加密隨機位元，對批次中的該欄位遞增，拒絕 80 位元溢位，僅解碼在 128 位元限制內的標準 26 字元值。

常見問題

ULID 保證永遠不會碰撞嗎？
沒有任何隨機識別碼有絕對保證。即使擁有大型 80 位元的隨機欄位，仍應使用資料庫的唯一約束，並以原子方式處理衝突。
為何有人能從我的 ULID 中讀取時間？
前 48 位元刻意編碼 Unix 毫秒，以支援詞序時間排序。若需要隱藏大約的產生時間，請勿使用 ULID。
ULID 可作為存取令牌嗎？
不可以。識別碼不會取代身份驗證或授權，且時間戳是公開的元資料。請使用專用憑證系統來處理機密。

相關工具

開發者工具 使用指南

查看全部