文字轉換為 slug 的範例會說明標題如何在明確的 ASCII 或 Unicode 規則下，轉變為小寫的 URL 形式識別碼，輸出長度上限為 1–200 個 Unicode 碼點。Text To Slug 工具會先套用 Unicode NFKD 正規化，移除組合記號，將結果轉為小寫，再依您所選的模式篩選字元。在 ASCII 模式中，只有 a–z 與 0–9 會保留；在 Unicode 模式中，Unicode 字母與數字會保留，因此中文、阿拉伯文、西里爾文與希臘文等文字可以保持完整。空格、標點、符號及其他不允許的字元連續區段會合併為單一連字號或底線，且邊界的分隔符號會移除。一個常見的範例是「Crème brûlée」，在 ASCII 模式中會變成「creme-brulee」，因為 NFKD 會將帶重音的字母分解；這是正規化，而非特定語言的音譯。此工具最多接受 100,000 個 UTF-16 程式碼單位的輸入，並可在您下載為 UTF-8 純文字前預覽實際產生的值。所有處理都在您的瀏覽器本機進行，因此標題與產生的 slug 不會被上傳。
文字轉換為 Slug 的基本範例
先從「Crème brûlée」開始。使用 ASCII 模式並選擇連字號時，預覽結果為 creme-brulee。NFKD 會將帶重音的母音分解為基本字母與組合記號；工具接著移除這些記號、將字母轉為小寫，並為空格保留一個連字號。此轉換以瀏覽器的 Unicode 正規化資料為基礎，而非手寫的法語字典。
模式的選擇可能會影響是否還有任何實用的 slug 能保留。在 Unicode 模式中，標題「中文標題」會保留為 中文標題，因為瀏覽器會將這些字元分類為 Unicode 字母。在 ASCII 模式中，這些字元不符合資格，因此轉換後的文字會是空的，工具也會回傳明確錯誤，而不是空白 slug。
分隔符號的處理同樣可預測。每一段連續的空格、標點、符號或不合格字元，都會變成一個所選的分隔符號。現有的連字號與底線會算作邊界字元，因此像「draft-title_final」這種混合輸入，在選擇底線時會變成「draft_title_final」。開頭與結尾的分隔符號會被移除。
選擇適當的字元模式
所選模式會決定正規化後還能保留哪些內容。它控制的是字元是否符合資格，而非偵測語言或選擇音譯系統。
| 決策 | ASCII 模式 | Unicode 模式 |
|---|---|---|
| 合格字元 | 小寫 a–z 與數字 0–9 | Unicode 字母與數字 |
| 帶重音的拉丁字母 | NFKD 會移除組合記號，因此許多字元會縮減為基本 ASCII | 組合記號會被移除，其餘 Unicode 字母仍符合資格 |
| 中文、阿拉伯文、西里爾文與希臘文 | 作為不合格字元移除 | 可以保留，不必使用近似的拉丁拼寫 |
| 標點與符號 | 合併為所選的分隔符號 | 合併為所選的分隔符號 |
| 音譯 | 無 | 無 |
| 沒有合格的輸出 | 回傳明確錯誤 | 回傳明確錯誤 |
ASCII 模式在需要受限制字元集的舊工具中具有較高的可攜性。Unicode 模式則能為現代系統保留語言特性。搜尋引擎可以處理 Unicode URL，但 URL 在不同系統之間複製時，瀏覽器可能會顯示百分號編碼的形式。請依據實際的 CMS、路由器、分析工具與編輯政策來選擇，不要假設某種模式一定比較好。
透過四個清楚的步驟建立 Slug
- 輸入要轉換的非空白標題或詞句。輸入最多可包含 100,000 個 UTF-16 程式碼單位。
- 選擇連字號或底線作為分隔符號，將最大長度設為 1 到 200 個 Unicode 碼點之間的整數，並決定是否保留非拉丁的 Unicode 字母與數字。
- 建立 slug。預覽會顯示產生的值及其長度。
- 在預覽中檢查確切的字元與長度，然後將結果下載為 UTF-8 純文字 TXT 檔案。
編輯輸入內容或選項時，先前的結果會被清除，因此變更後必須重新建立 slug。沒有任何標題或輸出會被上傳，轉換過程也不會使用歷史紀錄、帳戶、字典或網路服務。在接受相同的輸入、選項與瀏覽器 Unicode 實作時，結果具有確定性。下載時，工具會建立暫時的 UTF-8 Blob URL，並在瀏覽器開始傳輸後立即撤銷。
NFKD 如何在不進行音譯的情況下處理重音符號
操作順序可以解釋大多數令人意外的範例。MDN 的 String.normalize 文件 會說明 Unicode 正規化形式，而 Unicode Standard Annex #15 則定義其底層正規化行為。Text To Slug 會先使用 NFKD，再進行篩選。第一個步驟會分解 Unicode 有定義分解形式的字元，接著移除組合記號，然後轉換為小寫。只有在這些步驟完成後，ASCII 模式才會保留 a–z 與 0–9，而 Unicode 模式則會保留瀏覽器分類為 Unicode 字母或數字的字元。
此設計刻意不會進行音譯。工具不會將中文轉為拼音、西里爾文轉為拉丁字母、ß 轉為 ss，也不會將 & 轉成「and」這個詞。& 是符號，因此會成為分隔符號區段的一部分。在 Unicode 模式中，中文、阿拉伯文、西里爾文與希臘文字母可以保留，而標點與符號仍會變成分隔符號。在兩種模式下，組合記號都依相同規則移除。這能提供透明的字元處理，而不會使用可能在語言選擇上令編輯人員感到意外的隱藏字典。
設定確切的最大長度
輸入與輸出上限測量的是不同的內容。來源最多可包含 100,000 個 UTF-16 程式碼單位，但產生的 slug 最大長度是 1 到 200 個 Unicode 碼點之間的整數。最大值會套用於完成正規化、篩選、分隔符號合併與邊界修剪後的最終值。計算時會計算碼點，而非原始儲存單位；截斷功能也設計成不會將 UTF-16 代理項配對從中間切開。
截斷不會試著保留最後一個完整單字。它會保留允許的內容，直到達到所選上限；如果保留的內容以分隔符號結尾，該分隔符號就會被移除。回到較早的單字邊界，可能會產生遠短於所述最大值的內容，因此工具會優先採用確切上限。這讓結果可預測，但也表示 slug 可能在單字中途結束。兩個不同的標題可能會正規化成相同的值，而上限越短，發生碰撞的風險就越高。
有兩種無效情況會明確回報。如果篩選後沒有留下任何內容，預覽會回傳錯誤，而不是空白 slug。如果貼上的資料包含格式錯誤的 UTF-16，且有孤立的代理項，輸入就會在正規化前被拒絕，避免預覽與 UTF-8 編碼器因替換字元而默默產生不一致。一般在瀏覽器中輸入或貼上的文字通常格式正確，但這項驗證能讓轉換契約保持明確。
在實際內容工作流程中使用 Slug
產生的 slug 可作為大型發布系統中的一段識別碼。適用的情況包括草稿 URL 路徑、檔案名稱、錨點、類似 CSS 的識別碼、筆記鍵值與 CMS 規劃。在每種情況下，都應在預覽中於其將要使用的情境裡檢查該值，並在之後套用目的地系統本身的限制。
輸出內容只有預覽中顯示的 slug 區段。它不會加入網域、路徑斜線、副檔名或百分號編碼，也不會預留 URL 或保證唯一性。工具不會檢查保留的路由、檔案系統名稱、資料庫限制、不分大小寫的碰撞，或現有網站的 URL 清單。您的 CMS、路由器或檔案系統必須強制執行這些條件，例如先檢查候選值，再附加穩定的識別碼。
請依實際的 CMS、路由器、分析工具與編輯政策來選擇字元模式。ASCII 模式在舊工具中具有較高的可攜性，而 Unicode 模式能保留語言特性。搜尋引擎可以處理 Unicode URL，但在 URL 於不同系統之間複製時，瀏覽器可能會顯示百分號編碼的形式。沒有任何一種模式在所有情況下都比較好。當預覽內容符合預定的區段後，請下載 UTF-8 TXT 結果，並讓目的地系統處理路由與唯一性。