Nano ID Generator 是一款瀏覽器式工具,能以 1 到 100 字串為一批,每串長度介於 1 到 128 字元之間,產生密碼學等級的隨機、URL 友善識別碼,所有運算皆在本機透過 Web Crypto API 與 Nano ID 官方的 64 符號字母表完成。

當你開啟 Nano ID Generator 並點擊 Generate 時,頁面會呼叫 window.crypto.getRandomValues,以拒絕抽樣法(rejection sampling)抽取符號,並顯示一個以換行符分隔的唯一清單——不會上傳任何資料。預設輸出長度為 21 字元,符合 Nano ID 專案的標準 API。此預設值所提供的隨機空間足以應付一般應用程式識別碼,同時長度也夠短,可直接放進 URL 路徑、資料庫索引鍵欄位或檔名中。

本文將逐步說明如何使用此工具、各項控制的意義、如何安全地儲存輸出結果,以及其適用範圍的界線。

how to use nano id generator
How to Use the Nano ID Generator for App Identifiers

什麼是 Nano ID,以及它為何適用於 URL

Nano ID 是從 64 符號字母表中抽取的固定長度字串:大寫字母 A–Z、小寫字母 a–z、數字 0–9、底線與連字號。這個字母表刻意避開斜線、加號、等號、空白字元,以及其他在 URL 中常需要百分比編碼(percent-encoding)的字元。你可以將 Nano ID 直接貼進路徑段、查詢參數、標頭或片段中而無需跳脫,多數網頁框架、日誌管線與 CSV 匯出作業都能完整保留該值。

由於字母表剛好有 64 個符號,每個字元可容納 6 個位元(因為 2^6 = 64)。因此 21 字元的 ID 可編碼 21 × 6 = 126 個位元的密碼學隨機性。這個數值與 Nano ID 參考實作的預設一致,且與 UUID v4 的隨機部分(122 位元)相當,但使用的字元更少且字母表對 URL 安全。

Nano ID 是隨機的。它不會編碼建立時間、地區、分區、記錄類型或任何商業意義。如果你需要時序排序、離線解碼結構,或標準化的 UUID 表示法,Nano ID 就不適用——應改用 ULID、UUID 或 Snowflake。

工具內部:Web Crypto 與拒絕抽樣法

偏誤(bias)是任何從零打造的隨機字串產生器最隱而不現的失敗模式。如果你取一個隨機位元組並計算 byte mod alphabet.length,當數值範圍無法被字母表大小整除時,字母表頂端的符號出現頻率會略高於底端的符號。

Nano ID Generator 採用官方函式庫的拒絕抽樣法:它建立一個位元遮罩(bit mask),抽取隨機位元組,忽略任何落在字母表索引範圍之外的值,並持續抽取直到達到所要求的長度為止。由於字母表有 64 個項目,且遮罩大小恰好合適,因此「是否落在字母表內」的測試是精確的,最終產生的符號分布也是均勻的。隨機性來自 window.crypto.getRandomValues,這是 W3C Web Cryptography 規格 中定義的 Web Crypto API 基元,用於產生密碼學強度的位元組。

頁面絕不會呼叫 Math.random,也不會從時間戳、計數器、瀏覽器指紋或決定性種子衍生數值。它同樣不會將任何識別碼、長度、數量或剪貼簿內容傳送到伺服器。產生過程完全在用戶端進行,這代表一旦擴充功能或裝置本身遭到入侵,仍可能觀察到頁面資料——這與伺服器端的信任問題是兩回事。

如何使用 Nano ID Generator

  1. 在目前的分頁中開啟此工具,並決定介於 1 到 128 字元的長度。除非有具體需求佐證,否則請保留欄位為 21。
  2. 設定數量介於 1 到 100 之間。此工具產生的是批次而非串流,請依實際需求調整請求大小,不要每次都拉滿最大值。
  3. 點擊 Generate。頁面會透過 Web Crypto 抽取密碼學等級的隨機位元組,針對 64 符號字母表套用拒絕抽樣法,並將每個 ID 組裝至所要求的長度。
  4. 檢查輸出結果是否有重複。若在同一批次中出現機率極低的碰撞,工具會顯示錯誤,而非默默回傳重複的 ID。
  5. 複製以換行符分隔的清單,並貼到你的編輯器、終端機或種子檔案中。
  6. 將每個值連同唯一性約束(unique constraint)寫入資料庫,讓持久化儲存——而非瀏覽器——成為唯一性的最終把關者。

整個流程都在當前使用中的分頁內完成。若重新載入頁面,先前的輸出將會消失;如果你需要保留 ID,請在重新載入前先將它們貼到檔案中。

為你的識別碼選擇安全的長度

長度決定了識別碼的隨機空間。由於字母表有 64 個符號,每增加一個字元,空間就會乘以 64,每個字元恰好貢獻 6 個位元。從 10 個字元增加到 21 個字元會大幅擴大候選空間,這也是為何預設 21 字元被廣泛認為對一般應用程式來說足夠安全。

縮短 ID 很少是無代價的。10 字元的 ID 適用於低流量的內部參考;對於外部公開、可能被攻擊者列舉的資源識別碼來說,則是不佳的選擇。超過 21 字元的長度僅在你有特定威脅模型時才有幫助——例如,那些可能會被大規模快取、記錄或爬取的 URL 中所使用的識別碼。

此工具並不保證任何所選長度都能避免碰撞,因為原則上沒有任何固定長度的隨機識別碼能保證完全不碰撞。請依據預期發行量、可接受的風險、重試行為、儲存生命週期以及敵對曝險程度來做決定。

將輸出與你的資料庫搭配使用

瀏覽器只能在單一批次內保證唯一性。它無法與其他分頁、其他裝置、其他程序或更早的工作階段中所產生的 ID 協調,因此必須由資料庫來補上這個缺口。為此衍生出三項實用原則。

首先,將 ID 儲存在能保留大小寫以及兩種標點符號的欄位中。預設的 UTF-8 定序規則(collation)對 A–Z、a–z、0–9、底線和連字號不需額外處理,但區分大小寫不敏感的定序會在不知情的情況下將不同的 ID 合併,進而破壞唯一性。

其次,為該欄位加上唯一性約束。不要依賴應用層「先檢查再插入」的邏輯,因為在檢查與插入之間若有兩個請求同時抵達,就會發生存取競爭(race condition)。應讓持久化儲存機制直接拒絕第二次寫入。

第三,當發生約束衝突時,僅重試失敗的那筆建立交易。重新產生整批並要求使用者挑選另一列是多此一舉且容易令人困惑——用一個新的 ID 重跑一次即可解決衝突。

格式預設長度隨機位元數字母表是否編碼結構
Nano ID21 字元12664 個 URL 安全符號
UUID v4 (RFC 4122)36 字元 (32 個十六進位 + 4 個連字號)122十六進位加連字號版本與變體位元
ULID26 字元80 隨機 + 48 時間戳Crockford base32是,毫秒級時間戳前綴

對大多數資料庫索引鍵的使用情境而言,Nano ID 較短的長度在儲存空間與索引大小上佔優;當你需要單調遞增、依時間排序的識別碼時,ULID 勝出;當需要與已採用 RFC 4122 格式的系統互通時,UUID v4 勝出。

你應當正視的隨機識別碼限制

隨機識別碼並非憑證(credentials)。Nano ID Generator 適用於主鍵、請求 ID、分享權杖與短期的資源定位器;它並不適用於密碼、API 金鑰、復原碼、簽章材料,或任何生命週期必須包含輪替、撤銷與存取稽核的機密資料。針對這些用途,請使用目標平台專屬的憑證產生器與安全儲存機制,且切勿將機密資料貼進瀏覽器工具——即便是私人的瀏覽器工具亦然。

隨機識別碼也不是存取控制。包含難以猜測的 Nano ID 的 URL,仍必須由伺服器端的認證與授權機制加以把關;猜測 ID 的難度並不能取代權限檢查。Nano ID 官方儲存庫記載了該演算法;本站的 配套指南則更深入地說明了在本機產生的流程。

在上線前,請測試每一個會處理此 ID 的路由、日誌處理器、分析管線、CSV 匯出與資料庫定序。有為數不少的系統預設會自動修剪空白、摺疊大小寫或去除標點符號。唯有當儲存堆疊能保留正確的長度與字母表時,正確的長度與字母表才真正有意義。