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