Nano ID 產生器的替代方案，是指任何能在不將 nanoid 套件加入專案建置的情況下，產生 21 字元、URL 安全且來自 64 個符號字母表的識別碼工具。Lizely 所推出的 Nano ID 產生器正是此類替代方案之一：這是一個僅在瀏覽器中執行的工具，其隨機性來自 window.crypto.getRandomValues，採用官方的 64 個符號字母表（大寫 A–Z、小寫 a–z、數字 0–9、底線、連字號），並接受 1 至 128 字元的任意長度，以及 1 至 100 的任意批次大小。預設的 21 字元輸出對應上游 Nano ID API，且由於字母表正好包含 64 個唯一符號，每個字元帶有 6 位元的隨機性，21 個字元 × 每字元 6 位元 = 單次產生即具備 126 位元的熵。由於字母表避開了斜線、加號、等號與空白字元，因此產生的字串可直接放入網址，無需使用百分號編碼。正是這種對字母表的忠實還原、密碼學等級的隨機來源，以及零安裝的運作方式，使得瀏覽器端的替代方案實用而不只是裝飾。
瀏覽器工具何時能取代函式庫
官方 Nano ID 專案體積小、無相依性，且經過實戰考驗。將它加入正式環境的程式碼基底，幾乎不會是錯誤的選擇。但在以下反覆出現的情境中，加入一個相依套件所需的成本，反而比任務本身還高：
- 繪製結構草圖。在尚未產生任何真實資料前，繪製實體關係圖或遷移腳本時，需要數十個逼真的主鍵佔位符。
- 重現錯誤。同事寄來一段含有未知 ID 的請求追蹤記錄，而你希望取得同樣格式的值，以便餵入測試固定資料（fixture）。
- 教學或展示。展示網頁框架如何處理唯一的資源路徑時，聽眾需要即時看到識別碼產生的過程，而且不能有建置步驟。
- 稽核隨機性品質。在受控環境中，確認 Web Crypto 位元組加上拒絕抽樣（rejection sampling）所產生的符號並無可量測的偏差——而且不必先自己撰寫產生器程式碼。
在上述每一種情境下，瀏覽器端的替代方案都能簡化設定流程：開啟一個分頁、選擇長度、產生批次，然後以換行分隔的文字格式複製結果。你取得的字串與在 Node 或 Deno 中，以相同長度呼叫 nanoid() 所產生的格式完全一致——相同的字母表、相同的長度、相同的拒絕抽樣規則——因此日後以此為基礎建置的原型，無須再修改格式。
本工具提供哪些功能
此工具公開的行為經過刻意限縮，而這種專注正是選擇聚焦型替代方案，而非包山包海頁面的重點：
- 長度範圍：1 至 128 字元，會在產生前進行驗證。預設的 21 字元與上游 API 一致。
- 批次大小：每次產生 1 至 100 個 ID，可單次填入小型固定資料或較大的測試資料表。
- 字母表：64 個符號的 Nano ID 字母表——A–Z、a–z、0–9、_、-。絕不會出現其他字元，這也是輸出永遠不需要 URL 跳脫的原因。
- 隨機來源：window.crypto.getRandomValues，這是 W3C Web Cryptography API中專為密碼學強度設計的基礎介面。不會使用 Math.random、時間戳記、計數器或瀏覽器指紋。
- 符號選取：在計算出的位元遮罩上進行拒絕抽樣，採用與 Nano ID 函式庫相同的方法，因此無論位元組值是否落在字母表索引範圍之外，64 個符號中每一個出現的機率都相同。
- 批次去重：若同一批次中兩個值發生碰撞，工具會回報錯誤，而不是默默傳回重複項目。
- 僅在本機處理：產生與複製作業都在當前分頁中完成。不會將任何識別碼、數量、長度、剪貼簿內容或隨機位元組傳輸到伺服器。
產生一批 Nano ID
五個步驟即可完成整個工作流程，每個步驟對應著替代方案從你的程式碼中減化掉的一項決定：
- 選擇長度。從 1 至 128 之間挑選任意整數。使用 21 可對應上游預設值；唯有在經過實測、確定要以較短的網址換取碰撞空間時，才縮短長度。
- 選擇數量。每批次挑選 1 至 100 個 ID。較大的批次適合用於固定資料；較小的批次則更容易貼入單一欄位。
- 產生並檢視批次。觸發產生動作。工具會從 window.crypto.getRandomValues 取得隨機位元組，針對 64 個符號的字母表執行拒絕抽樣，對產生的批次進行唯一性檢查，並將結果以每行一個識別碼的方式顯示。
- 複製並貼上。將換行分隔的輸出複製到你的編輯器、固定資料檔、SQL 種子資料或請求主體中。
- 在儲存層強制唯一性。在目標欄位加上唯一約束（unique constraint），讓資料庫以原子方式拒絕任何罕見的衝突，而不是先檢查再插入。
Nano ID 與其他識別碼格式的比較
選擇 Nano ID 產生器替代方案，同時也是在思考哪種識別碼格式更適合整個系統。下表整理了各格式規格中定義的屬性，讓權衡一目了然。如需更深入的研究，官方儲存庫仍是唯一權威來源。
| 屬性 | Nano ID（預設） | UUID v4 | ULID |
|---|---|---|---|
| 預設長度 | 21 字元 | 36 字元（含連字號） | 26 字元 |
| 不需跳脫即可用於 URL | 是（64 個符號的字母表） | 是（使用連字號，無保留字元） | 是（Crockford base32） |
| 可依建立時間排序 | 否 | 否 | 是 |
| 內含建立時間 | 否 | 否 | 是（48 位元毫秒時間戳記前綴） |
| 典型的隨機來源 | 密碼學等級（本工具採用 Web Crypto） | 密碼學等級（依 RFC 4122） | 密碼學等級（依 ULID 規格） |
| 會洩露時間順序或業務意義 | 否 | 否 | 是 |
若系統需要字典序排序、離線擷取時間戳記，或嚴格的 RFC 4122 相容性，那麼不管產生器多好，Nano ID 都不是合適的形狀。在需要標準相容性時，UUID v4 是正確的選擇；在需要可排序的建立時間時，ULID 是正確的選擇；而在需要簡潔、可直接用於 URL、不透漏時間資訊的識別碼時，Nano ID 是正確的選擇。Lizely 的工具僅填補了該表中 Nano ID 那一列。
隨機來源如何保持公正
從字母表中挑選隨機字元時，常見的捷徑是取一個隨機位元組後，對字母表長度取模。當字母表大小無法整除位元組範圍時，這種捷徑會產生偏差；而對於一個大小無法整除 256 的字母表，天真地取模運算會引入偏差。本工具並未採取這種捷徑，而是遵循 Nano ID 的作法：計算一個能涵蓋字母表索引範圍的位元遮罩（64 個符號對應六個位元）、讀取隨機位元組、捨棄任何落在遮罩範圍之外的位元組，並持續抽取直到達到要求的長度。
在這個 64 個符號之中，每個字元都真正均勻分布，每個字元的熵正好是六個位元——這是一個單一且可預測的值，乘以所選長度即可估計識別碼的空間。在這個簡化的模型中，21 個字元提供 126 位元的熵；每減少一個字元，可用空間便縮小為原來的 1/64。請將這些數字視為規劃階段的估算，而非碰撞的保證，並在發行量、儲存生命週期或外部威脅程度改變時，重新檢視所選的長度。
基於瀏覽器的替代方案不適用的情境
瀏覽器工具的價值在於它是一個聚焦的替代方案，而非萬用替代品。以下三個界線在實務上至關重要：
- 跨工作階段協調。批次唯一性檢查僅涵蓋單次產生所抽出的值。在其他分頁、裝置、處理程序、部署或更早的工作階段中所產生的識別碼，並不會被去重。跨越這些界線時，唯一可靠的仲裁者只有資料庫的唯一約束。
- 高價值的秘密資訊。本工具是為不透明的識別碼而設計，並非用於密碼、API 金鑰、復原碼、簽章金鑰，或任何生命週期長於資料列建立的其他用途。針對這些用途，請使用目標平台專屬的秘密產生器與管理工具；長相隨機的字串並不等同於受到控管的憑證。
- 頁面周邊的可信界線。瀏覽器擴充功能、被入侵的腳本以及被入侵的裝置，仍能觀察到分頁中的資料。產生過程確實在本機進行，但「本機」僅代表沒有上傳到伺服器，並不代表分頁中執行的任何程式都看不到它。
若想更深入了解安全性概況與隨機性保證，指南 使用線上 Nano ID 產生器是否安全？更詳細地說明了相同的信任模型。
總結
當任務生命週期短暫、格式必須對應上游 Nano ID 字母表，且不希望為了產生一個識別碼而更動建置流程時，Nano ID 產生器的替代方案是合理的選擇。Lizely 的工具在瀏覽器中直接提供了這些能力：受限的長度範圍（1–128）、受限的批次大小（1–100）、忠實還原的 64 個符號字母表、拒絕抽樣、批次去重，以及 Web Crypto 作為隨機來源——而且完全沒有額外的相依性。在正式環境的識別碼使用上，請保留 21 字元的預設值，除非有實測結果支持例外；將識別碼儲存在保留大小寫與兩種標點符號的欄位中；加上唯一約束；並僅針對失敗的建立交易進行重試。這個替代方案的價值，在於做得少，並把那一小塊職責做好。