Nano ID 生成工具

在瀏覽器中批次生成 URL 安全的簡短唯一 ID。可自由指定字元集(預設、字母數字、小寫、大寫、數字、十六進位制)和長度,非常適合需要比 UUID 更短的 ID 的場景。

ID 格式對比

格式 長度 字元集大小 能否按生成順序排序 說明
Nano ID 預設21個字元(可指定1〜64個字元) 64個字元 不能(完全隨機) 僅由 URL 安全字元組成的短隨機 ID,可自由更改字元集和長度。
UUID v4 36個字元(含4個連字元) 16個字元(十六進位制) 不能(完全隨機) 由 RFC 9562 標準化的128位識別符號,以連字元分隔的十六進位制表示法為標準格式。
ULID 26個字元 32個字元(Base32) 能(前10個字元為時間戳) 開頭帶有毫秒級時間戳,因此可以按字串順序排列生成順序。

Nano ID 是什麼

Nano ID 是僅以 URL 安全字元構成短隨機 ID 的機制。預設由64種字元(A-Za-z0-9_-)組合21個字元而成,比 UUID 更短,同時又能確保實用上足夠的隨機性。本工具可自由指定字元種類(預設、英數、小寫、大寫、數字、16進位)與長度、產生筆數,一次批量建立 ID。

產生處理全部在瀏覽器內完成,並使用 Web Crypto API 的密碼學隨機數,因此完全不會傳送至 toolbase.cc 的伺服器。輸入表單無須處理機密資訊,產生的 ID 可直接複製,用於 URL 的 slug、測試資料、檔案名稱等。

Nano ID 的使用方式

  1. 選擇字元種類 由預設(URL 安全64字元)、英數、僅小寫、僅大寫、僅數字、16進位中,選擇符合用途的字元種類。
  2. 設定長度 指定所產生 ID 的字元數。愈短則碰撞機率愈高,請留意與用途相符的平衡。
  3. 指定產生筆數 輸入一次想建立的 ID 數量。需要多筆(如批量建立測試資料)時可在此一併指定。
  4. 按下產生按鈕 按下「產生」後,符合所指定條件的 ID 便會即時在瀏覽器內建立並列表顯示。
  5. 複製 個別 ID 可用「複製」按鈕;若想整批使用,則可用「全部複製」一次複製。

用好本工具的小技巧

  • Nano ID 使用基於 Web Crypto API 的密碼學安全隨機數生成,且全部在瀏覽器內處理,不會發送到 toolbase.cc 的伺服器。
  • 預設的64字元字母表(A-Za-z0-9_-)不含符號或空格,可以直接安全地用作URL 路徑或檔名
  • 將字元集限定為"僅數字"或"十六進位制",可以生成符合現有系統 ID 格式(例如訂單編號僅為數字)的 ID。
  • 長度越短,碰撞機率越高。發行量大的系統建議保持預設的21個字元左右,少量測試資料用8〜10個字元左右也可能足夠。
  • 增加生成數量後使用"全部複製",便於批次建立測試資料或種子資料。

Nano ID 的活用場景

產生 URL 的 slug

作為短網址或分享連結路徑部分所用的唯一 ID,可直接使用不含符號的 URL 安全字串。

投入測試・虛擬資料

作為投入開發中資料庫的樣本記錄主鍵或識別碼,可一次批量產生所需筆數。

發行工作階段 ID 或請求 ID

作為追蹤日誌或識別 API 請求所用的臨時 ID,可備妥簡短易用的字串。

為避免碰撞的檔名編號

想為上傳檔案的儲存名稱加上隨機 ID,以防同名檔案覆寫時便可活用。

發行簡易 API 金鑰或參照碼

並非正式環境的認證資訊,而是可輕鬆用於內部工具或驗證環境所用短參照碼的編號。

用語集

Nano ID
指僅以 URL 安全字元種類構成短隨機 ID 的產生方式。預設以21字元、64種字元確保高隨機性。
UUID
指由 RFC 標準化的128位元識別碼。以連字號分隔的36字元16進位表記為標準形式而廣泛使用。
ULID
指開頭帶有毫秒級時間戳的26字元 ID。可依產生順序作為字串排序,此點與 Nano ID、UUID 不同。
Web Crypto API
指瀏覽器標準配備的密碼處理用 API。可產生難以預測的隨機數,為 ID 安全性的依據。
密碼學隨機數
指經設計使下一個值無法以統計方式預測的隨機數。可降低 ID 被猜測或冒用的風險。
碰撞機率
指不同的產生偶然造出相同 ID 的機率。字元數與字元種類愈多,碰撞機率愈低。
生日問題
指群體人數愈多、愈容易出現同一生日者的現象,用於估算 ID 碰撞機率時的近似計算。

常見問題

如果想直接將短 ID 用於 URL 或檔名,Nano ID 更合適。如果需要 RFC 標準化的格式,或者重視與其他系統的互操作性,UUID(尤其是 v4)是更穩妥的選擇。

在預設的21個字元、64種字元的設定下,具有相當於126位的隨機性,實際使用中的碰撞機率幾乎可以忽略。計算得出,碰撞機率達到50%所需的生成數量約為1.09×10¹⁹個。

可以,但和 UUID v4 一樣是完全隨機的,因此插入 B-Tree 索引的效率不如 AUTO_INCREMENT。如果需要按插入順序排序,建議考慮使用開頭帶時間戳的 ULID 等方案。

是的。即使長度相同,字元集大小(字母表大小)越小,隨機性越低(抵禦碰撞的能力也越弱)。若要用僅數字(10種字元)達到與64種字元字母表相同的安全性,需要更長的字元數。
工具君

閒話 ― 為什麼 Nano ID 能比 UUID 更短

Nano ID 是 PostCSS 的開發者 Andrey Sitnik 於2017年釋出的 JavaScript ID 生成庫。它沒有依賴項,程式碼量僅有幾百位元組,卻使用密碼學安全的隨機數,這種設計獲得了廣泛認可,如今在 npm 上每週下載量達數千萬次,成為常用庫之一。

ID 的長度取決於所用字元集的大小。UUID 僅使用十六進位制(16種字元)來表示128位,因此需要36個字元;而 Nano ID 使用64種字元,僅用21個字元就能表示相當程度的隨機性(預設設定下為126位)。這是因為每個字元所攜帶的資訊量(log₂64=6位)大於十六進位制(log₂16=4位),這正是縮短長度的原因。

預設設定(21個字元、64種字元)所具有的126位隨機性,與 UUID v4 的122位幾乎相當。根據生日問題的近似公式計算,碰撞機率達到50%所需的生成數量約為1.09×10¹⁹個,實際使用中幾乎無需擔心。