文字轉 slug API 替代工具是一種以瀏覽器為基礎的工具，使用與 API 端點相同的 Unicode 規則將標題轉換為 URL 風格的識別碼，但不會將輸入透過網路傳送、不需要 API 金鑰，也沒有每次請求的計費。Slug API 替代方案會在本地執行所有步驟：NFKD 正規化、移除組合標記、轉為小寫、字元過濾、分隔符號收合、長度截斷，以及最終的 UTF-8 下載。由於轉換在瀏覽器自身的 Unicode 資料下是確定性的，因此相同的標題在每次造訪時都會產生相同的 slug，而這個結果在貼到 CMS 草稿、點連結或檔名前都很容易進行稽核。
大多數託管的 slug 產生器以 HTTP 端點或 NPM 函式庫的形式提供（其中包括 slug-wizard、slug-from-text、APIVerve Slugify 端點、AISENSE、DoSlug 和 post-slug），它們接收 JSON 酬載並回傳 slug。它們能整齊地融入伺服器管線，但需要一次來回、需要帳號或金鑰，並且必須做出信任決策——是否要將尚未發佈的標題傳送給第三方。以瀏覽器為基礎的替代方案則將同樣的管線放進當前分頁，並把標題保留在頁面中，這對於編輯草稿、客戶工作，以及任何不應離開裝置的標題來說都很重要。
「API 替代方案」對 Slug 產生器而言代表什麼
實際上，「API 替代方案」是三件事共同運作的簡稱。第一，工具必須產生與 slug API 相同類型的輸出：一個小寫、以分隔符號連接、可安全放入 URL 路徑的識別碼。第二，工具必須在沒有網路請求的情況下執行，因此標題絕不會送到遠端伺服器。第三，轉換規則必須是可見的，而不是藏在呼叫端無法檢視的伺服器端音譯表中。
第三點正是許多託管 slug API 彼此悄悄分歧之處。有些 API 為斯堪地那維亞字母（ø → o、å → a、æ → ae）、德文鋭音符（ß → ss），以及 & 號或其他會被捨棄的符號內建硬式編碼對應。其他則完全依賴覽器風格的正規化，並保留這些字母不動。結果是兩個 slug API 可能從相同的標題回傳不同的字串，而編輯團隊常常只能猜測他們的 CMS 預期哪一種行為。與回傳黑箱字串的方案相比，公開說明規則的 API 替代方案更容易理解。
瀏覽器 Slug 工具如何取代網路呼叫
之所以能取代，是因為底層規則已經標準化。NFKD 正規化由 Unicode 標準附錄 #15 所定義，而每個現代 JavaScript 引擎都提供 slug 函式庫所使用的同一個 String.normalize 方法。工具會先套用該正規化，接著移除組合標記、將結果轉為小寫，並依 Unicode 屬性過濾字元。沒有隱藏的音譯表；預覽中顯示的 slug 就是瀏覽器所計算出來的 slug。
Text To Slug 工具遵循該合約。轉換在本地執行，接受的輸入上限為 100,000 個 UTF-16 程式碼單元，格式錯誤的代理對會在正規化前被拒絕，因此預覽不會與下載所用的 UTF-8 Blob 編碼器悄悄產生分歧。同一個瀏覽器中的同一個標題，因此每次都會產生相同的 slug——這正是多數團隊真正需要 slug API 提供的特性。
在不呼叫 API 的情況下將標題轉換為 Slug
流程與 HTTP 端點公開的相同，只是以表單欄位呈現。以下步驟對應 slug API 替代方案經過驗證的操作流程。
- 在輸入欄位中輸入要轉換的標題或片語。
- 選擇連字號或底線作為分隔符號，將最大長度設定為 1 到 200 之間任意 Unicode 程式碼點，並決定是否保留非拉丁字母與數字。
- 建立 slug 並檢查預覽，其中會顯示確切的字元與最終長度。
- 將 slug 下載為 UTF-8 純文字檔，或從預覽中複製，再貼到需要的 CMS 草稿、錨點或檔名中。
編輯任何欄位都會清除先前的結果，因此預覽永遠不會顯示已不再符合目前選項的字元。如果某個選擇產生空字串（例如在不包含拉丁字母或數字的文字上使用 ASCII 模式），工具會回傳明確的錯誤，而非空的 slug。
無 API 的 Slug 工具中 ASCII 模式與 Unicode 模式的比較
最關鍵的選擇是只保留 ASCII 字母與數字，還是允許完整的 Unicode 字母與數字集合。這兩種模式不可互換，正確的選擇取決於 CMS、路由器、分析工具，以及網站的編輯政策。
| 面向 | ASCII 模式 | Unicode 模式 |
|---|---|---|
| NFKD 後保留的字元 | 僅 a–z 與 0–9 | 依瀏覽器屬性保留 Unicode 字母與數字 |
| 組合標記（字母上方的腔調） | 移除 | 移除 |
| 如 é、ü、ñ 等拉丁腔調字元 | 還原為基本字母：「Crème brûlée」變成「creme-brulee」 | 以相同方式還原為基本字母 |
| 如中文、阿拉伯文、斯拉夫文、希臘文等文字 | 移除；僅保留數字 | 保留 |
| 標點與符號 | 收合為單一連續分隔符號 | 收合為單一連續分隔符號 |
| 在較舊工具中的可攜性 | 最高 | 較低；部分 URL 會對非 ASCII 進行百分比編碼 |
| Slug 中的語言識別性 | 喪失 | 保留 |
對於可攜的 URL 區段、舊版路由器，以及任何會將 slug 複製貼上到 Unicode 感知路由之前的工具，ASCII 模式是較安全的預設。當 slug 旨在保留原始文字、當 CMS 與分析堆疊皆支援 UTF-8，以及當編輯團隊希望「北京歡迎你」保持為「北京歡迎你」而不是消失時，Unicode 模式才是正確的選擇。
略過 Slug API 的限制與權衡
略過 API 確實有其代價，而 slug API 替代方案對此坦誠以對。
這個工具不進行語言音譯。它不會將中文轉為拼音、不會將斯拉夫文轉為拉丁文、不會將德文鋭音符轉為 ss，也不會將 & 號轉為「and」。這些對應需要語言上的選擇與參考表，可能會讓編輯感到意外。凡是 Unicode 正規化規則無法還原的部分，就只會依所選模式被捨棄或保留，不會有其他處理。
這個工具不強制唯一性。兩個不同的標題可能正規化為相同的 slug，而最大長度截斷會提高碰撞風險，因為 slug 是依程式碼點切斷，而非依完整的最後一個單字切斷。目的端的 CMS、資料庫或檔案系統負責檢查碰撞，並在需要時附加其自身的穩定識別碼。
這個工具不會檢查保留路由、不分大小寫的碰撞、既有的網站清單、副檔名或網域前置字元。輸出僅僅是預覽中顯示的 slug 區段——沒有前置斜線、沒有結尾副檔名，也沒有百分比編碼。如果目的端系統需要這些，就需要在貼上 slug 之後自行加上。
一個實際的範例可以讓截斷規則更具體。取標題「10 Tips for Better Sleep Hygiene」，含空格共 32 個字元。在 ASCII 模式、連字號分隔符號、最大長度 25 的情況下，轉換路徑如下：
- NFKD 正規化：字串已為組合形式，因此不會進行分解。
- 組合標記：沒有可移除的項目。
- 轉為小寫：「10 tips for better sleep hygiene」。
- ASCII 過濾與分隔符號收合：每個空格變成一個連字號，得到「10-tips-for-better-sleep-hygiene」，共 32 個程式碼點。
- 切片至 25 個程式碼點的上限：「10-tips-for-better-sleep-」（25 個程式碼點，結尾落在分隔符號上）。
- 移除結尾的分隔符號：「10-tips-for-better-sleep」，共 24 個程式碼點。
最終值短於 25 個程式碼點的上限，因為結尾的連字號已被移除。工具不會嘗試保留完整的最後一個單字，因為這麼做可能產生比所宣告上限更長或更短許多的字串。接收 slug 的 CMS 應在截斷後的形式與既有文章發生碰撞時，自行附加穩定識別碼。
託管 Slug API 何時仍有其意義
瀏覽器工具並非所有工作流程的正解。伺服器端的 slug 產生屬於 HTTP 處理程式、構建步驟，或已有網路連線的內容遷移腳本，而這些情境依然能受益於 slug-wizard 這類函式庫或託管端點。當工作在瀏覽器中進行時——編輯草稿、為長篇文章規劃錨點、為一批本地檔案產生檔名，或為不希望將標題送往遠端服務的筆記鍵產生 slug——API 替代方案才真正發揮價值。針對這些任務，slug API 替代方案能產生與端點相同的、以分隔符號連接的小寫輸出，且規則對編輯而言是可讀的。
如果您正在權衡選項，Skip Scripts With a Batch Text File Creator Alternative 對此有詳細說明。
如果您正在權衡選項，Strikethrough Text API Alternative for Plain-Text Fields 對此有詳細說明。