Text to Slug 批次轉換搭配 Text To Slug 每次轉換可接受最多 100,000 個 UTF-16 字碼單元，全部在瀏覽器中執行，並可讓你將完全相同的結果以 UTF-8 純文字下載，標題從不外傳到任何伺服器。轉換器一次處理一個輸入產生一個 slug，因此批次工作流程意味著貼上一大塊標題區塊、逐筆處理一長串標題，或以相同選項連續執行多次單筆轉換。在瀏覽器的 Unicode 實作下，每次轉換都是確定性的，因此相同的標題與相同的設定永遠會產生相同的 slug，這在你要把數十篇 CMS 草稿轉成 URL 段落時格外重要。
「批次」對 slug 轉換器而言代表什麼
大多數搜尋批次 slug 工具的讀者，期待的是一個多行欄位，每行變成自己的 slug，再以整塊複製。Text To Slug 工具遵循更嚴格的合約：一個輸入欄位、一個輸出 slug，並刻意把輸入上限拉得很大，讓你可以貼上大量文字而無需先分割。該上限為 100,000 個 UTF-16 字碼單元，足以容納非常長的標題、摘要段落，或是你通常會先切割再產生 slug 的 CSV 風格區塊。
實務上的批次工作流程有三種樣貌。第一種是單一大型標題或段落，你希望將其壓縮成單一識別碼。第二種是一長串標題，你逐筆送進工具，再把每筆結果複製到你的 CMS、試算表或檔案名稱清單。第三種是跨多個標題重複使用相同設定，以維持轉換一致性。由於處理在本機端進行，每筆標題的成本基本上就是打字速度，而不是上傳時間或 API 配額。
Text To Slug 如何處理大型輸入
工具在正規化開始前，會拒絕空輸入、格式錯誤的 Unicode，以及任何超過 100,000 個 UTF-16 字碼單元的字串。刻意拒絕含有孤立代理項（surrogate）的格式錯誤 UTF-16，如此預覽與 UTF-8 下載才不會因替代字元而悄悄不一致。在瀏覽器中輸入或貼上的普通文字都是格式良好的，但當你從不常見的來源貼上時，這個驗證能讓轉換合約保持明確。
輸入通過驗證後，轉換器會套用 Unicode NFKD 正規化，這是一種將相容字元（例如連字與附音符號字母）分解為基本組成元件的形式。接著移除組合記號（combining marks），並把剩下的字母轉為小寫。正是這單一次的正規化流程，讓「Crème brûlée」在 ASCII 模式下變成「creme brulee」，而且不需要任何手寫的音譯字典。此行為來自瀏覽器內建的 Unicode 資料，文件記載於 MDN String.normalize 參考頁面 以及 Unicode 標準附錄 #15（關於正規化形式）。
用幾次點擊轉換多個標題
- 在輸入欄位中輸入要轉換的標題或片語。你可以貼上單一長標題，或是你正在處理清單中的第一個項目。
- 選擇分隔符號：連字號或底線。標題中既有的連字號、底線、空格或標點，都會被正規化為你所選的字元，因此混合分隔符號會收斂成單一樣式。
- 將最大長度設定為 1 到 200 之間的整數。此限制以產生之 slug 的 Unicode 字碼點（code points）為計算單位，而非輸入字串。
- 決定是否保留非拉丁字母與數字。ASCII 模式請保持關閉；Unicode 模式則開啟。
- 產生 slug，並在預覽中檢查確切字元與回報的長度。預覽的值與將下載的內容完全相同。
- 將結果以 UTF-8 純文字下載。下載使用的是暫時性的 Blob URL，瀏覽器在傳輸開始後立刻撤銷。
- 對下一個標題重複同樣流程。編輯任何欄位都會清除先前的結果，因此每次迭代都從當下的輸入與選項重新開始。
混合語言清單的 ASCII 模式與 Unicode 模式
如果你的批次清單混合了英文、帶附音符號的拉丁字母，以及非拉丁文字，模式選擇會改變哪些字元得以保留。兩種模式遵循明確規則，而非猜測式音譯，這正是這個工具的重點：既不載入語言字典，也不替你做語言選擇。請參考下方比較表，挑選與你目標系統相符的模式。
| 面向 | ASCII 模式 | Unicode 模式 |
|---|---|---|
| NFKD 後保留的字母 | 僅限小寫 a-z | 瀏覽器歸類為字母的全部 Unicode 字母 |
| 保留的數字 | 0-9 | 所有 Unicode 數字 |
| 帶附音符號的拉丁字母，例如「Crème brûlée」 | 化簡為「creme-brulee」 | 透過 NFKD 化簡為「creme-brulee」，移除變音符號 |
| 中文、阿拉伯文、斯拉夫文、希臘文 | 移除；前後連續區段成為分隔符號 | 移除組合記號後原樣保留 |
| 標點與符號 | 變成單一分隔符號，然後合併 | 變成單一分隔符號，然後合併 |
| 空結果處理 | 回傳明確錯誤，而非空 slug | 回傳明確錯誤，而非空 slug |
這個工具刻意不進行語言音譯。它不會把中文字轉為拼音、不會把斯拉夫文轉為拉丁字母，也不會把德文銳音 s（ß）轉為 ss，因為這些對映需要語言判斷與參考表，而且可能出乎意料。ASCII 模式在較舊的工具與電子郵件用戶端間的可攜性較佳；Unicode 模式則為能處理非拉丁 URL 的 CMS 與分析工具保留語言識別性。
最大長度、代理對與截斷
最大長度計算的是產生值中的 Unicode 字碼點，而不是位元組，也不是 UTF-16 字碼單元。截斷發生在轉換之後，這代表輸入可以是上限 100,000 字碼單元以內的任何大小，而輸出則受你所設定的限制所約束。如果保留部分的末端是分隔符號，該結尾分隔符號會被去除，因此 slug 絕不會以連字號或底線收尾。工具不會嘗試保留最後一個完整單字，因為這麼做可能使最終長度超出你設定的上限，或遠低於該上限。
代理對（surrogate pair）會被明確處理。輸入中以 UTF-16 代理對編碼的字元，在輸出中仍算為一個 Unicode 字碼點，且截斷絕不會把一個代理對切成兩半。含有孤立代理項的格式錯誤輸入，會在正規化之前就被拒絕，這能避免預覽與 UTF-8 Blob 編碼器因替代字元而產生不同的字串。
分隔符號、邊界與禁用字元
每一段連續的空格、標點、符號與禁用字元，會變成至多一個分隔符號。前後端的首尾分隔符號會被移除，因此以標點開頭或結尾的標題，不會產生以分隔符號開頭或結尾的 slug。輸入中既有的連字號與底線被視為一般的邊界字元，這代表像「Draft - v2_final」這樣的標題在選擇連字號時，會變成「draft-v2-final」，而不是把混合分隔符號帶進輸出中。
在 ASCII 模式下，無法分解為 ASCII 基本字母的字母，會連同其周圍的分隔符號區段一併移除。這就是為什麼像是希臘文或天城文（Devanagari）等文字，在 ASCII 模式下可能產生空結果並觸發明確錯誤：標題中的每個字元都落在保留集合之外，而工具拒絕回傳空 slug。請改用 Unicode 模式以保留這些字元，或預先篩選清單，僅保留在正規化後至少含有一個 ASCII 字母或數字的標題。
下載與重複使用批次結果
下載步驟會在你點擊當下建立一個暫時的 UTF-8 Blob URL，並在瀏覽器開始傳輸後立即撤銷。下載的檔案內容與預覽中顯示的 slug 完全一致，不含網域、不含前置斜線、不含副檔名，也不含百分比編碼。這讓檔案易於貼進 CMS 欄位、試算表欄、檔案重新命名腳本，或文件中的錨點清單。
若要批次重複使用，最乾淨的做法是在工具旁邊保持一個持續開啟的文字檔：貼上每個標題、產生、下載，再把 slug 複製到檔案中。由於處理在本機端且具確定性，你之後可以用不同設定重新執行任何標題，結果仍可重現。如果你正在處理相關的批次文字任務，「為文字檔每一行批次加上前綴」指南涵蓋了反向情境：把一份清單轉成準備好的欄位，且無需上傳。
這個工具不會檢查的事項
slug 不會保留 URL，也不保證唯一性。兩個不同的標題可能會被正規化為相同的值，而截斷會提高碰撞風險，因為上限越短，重疊的空間就越大。工具不會檢查保留路由、檔案系統命名、資料庫限制、不分大小寫的碰撞，或既有網站的 URL 清單。你的目標系統（無論是 CMS 路由器、靜態網站產生器，或資料庫唯一索引）應負責強制唯一性，或附加其自身的穩定識別碼。
工具同樣不會加上網域、路徑斜線、副檔名或百分比編碼。搜尋引擎能處理 Unicode URL，但瀏覽器與系統間的複製貼上流程可能會顯示百分比編碼的形式，這正是當可攜性跨較舊工具至關重要時偏好 ASCII 模式的理由。請依據實際的 CMS、路由器、分析設定與編輯政策來選擇模式，而非假設某一種模式在所有情境下都更好。編輯任何欄位都會清除舊的結果，且沒有任何標題、輸出、歷史、帳號、字典或網路服務參與這次轉換，這就是為什麼在瀏覽器的 Unicode 實作下，相同的輸入與選項會產生確定性的值。