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 程式碼單位的字串。帶有孤立代理項的格式錯誤 UTF-16 會被刻意拒絕，如此預覽和 UTF-8 下載絕不會因替換字元而靜默不一致。在瀏覽器中輸入或貼上的普通文字格式正確，但驗證機制能在你從特殊來源貼上時，讓轉換契約保持明確。
輸入通過驗證後，轉換器會套用 Unicode NFKD 正規化，這是一種將相容字元(如連字和附加音標字母)分解為其基本組成部分的格式。接著會移除組合標記，並將剩餘字母轉為小寫。正是這單一的正規化過程，讓 "Crème brûlée" 在 ASCII 模式下變成 "creme brulee"，無需任何手寫的音譯字典。此行為源自瀏覽器內建的 Unicode 資料，記載於 MDN String.normalize 參考頁面 和 Unicode 標準附錄 #15 正規化形式。
幾次點擊即可轉換多個標題
- 在輸入欄位中輸入要轉換的標題或詞組。你可以貼上單一長標題，或你正在處理的清單中的第一個項目。
- 選擇分隔符號:連字號或底線。標題中任何現有的連字號、底線、空格或標點都會正規化為你所選的字元，因此混合分隔符號會合併為單一風格。
- 將最大長度設定為 1 到 200 之間的整數。限制是以產生之 slug 的 Unicode 程式碼點計算，非輸入字串。
- 決定是否保留非拉丁 Unicode 字母和數字。關閉此選項為 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 |
本工具刻意不進行語言音譯。它不會將中文字轉為拼音、西里爾文轉為拉丁文，或德文 sharp s 轉為 ss，因為這些對應需要語言判斷和參考表，可能產生意外結果。ASCII 模式在較舊的工具和電子郵件用戶端中可攜性更高;Unicode 模式則為能處理非拉丁 URL 的 CMS 和分析工具保留語言識別性。
最大長度、代理對與截斷
最大長度計算的是產生值中的 Unicode 程式碼點，不是位元組，也不是 UTF-16 程式碼單位。截斷發生在轉換之後，這表示輸入可達 100,000 程式碼單位上限，而輸出則受你設定的限制約束。若保留部分結尾為分隔符號，該結尾分隔符號會被移除，因此 slug 絕不以連字號或底線作結。工具不會嘗試保留最後一個完整單字，因為這麼做可能使最終長度超出設定上限，或遠低於上限。
代理對會被明確處理。輸入中以 UTF-16 代理對編碼的字元，在輸出中仍算一個 Unicode 程式碼點，截斷時絕不會將配對切半。帶有孤立代理項的格式錯誤輸入會在正規化前被拒絕，這可避免預覽與 UTF-8 Blob 編碼器因替換字元而產生不同的字串。
分隔符號、邊界與禁用字元
每個連續的空格、標點、符號和禁用字元區段，至多變成一個分隔符號。開頭和結尾的分隔符號會被移除，因此以標點開頭或結尾的標題，不會產生以分隔符號開頭或結尾的 slug。輸入中現有的連字號和底線會被視為任何其他邊界字元，這表示像 "Draft - v2_final" 這樣的標題，在選擇連字號後會變成 "draft-v2-final"，而不會在輸出中帶有混合分隔符號。
在 ASCII 模式中，無法分解為 ASCII 基本字母的字母會在周圍的分隔符號區段中一併移除。這就是為什麼希臘文或天城文等文字在 ASCII 模式下可能產生空結果，並觸發明確錯誤:標題中的每個字元都落在保留集之外，工具拒絕回傳空 slug。請切換至 Unicode 模式以保留這些字元，或預先篩選清單，只保留正規化後至少含一個 ASCII 字母或數字的標題。
下載與重複使用大量結果
下載步驟在你點擊當下建立臨時 UTF-8 Blob URL，並在瀏覽器開始傳輸後立即撤銷。下載的檔案包含預覽中顯示的精確 slug，沒有網域、沒有前置斜線、沒有副檔名，也沒有百分比編碼。這使得該檔案易於貼入 CMS 欄位、試算表欄、檔名重新命名指令碼，或文件中的錨點清單。
對於大量重複使用，最簡潔的模式是在工具旁開啟一個持續運用的文字檔:貼上每個標題、產生、下載，然後將 slug 複製到檔案中。由於處理在本機進行且具確定性，你之後可以用不同設定重新執行任何標題，結果仍可重現。如果你正在處理相關的大量文字任務，為文字檔每一行加上前綴的大量處理指南 涵蓋了反向操作:將清單轉為準備好的欄位，而無需上傳。
本工具不會檢查的事項
slug 不會保留 URL 也不保證唯一性。兩個不同的標題可能正規化為相同的值，而截斷會增加衝突風險，因為較短的上限會留下更多重疊空間。本工具不會檢查保留路由、檔案系統名稱、資料庫約束、不分大小寫的衝突，或現有站台的 URL 清單。你的目標系統(無論是 CMS 路由器、靜態網站產生器，或資料庫唯一索引)應負責強制唯一性，或附加自身的穩定識別項。
本工具也不會加入網域、路徑斜線、副檔名，或百分比編碼。搜尋引擎能處理 Unicode URL，但瀏覽器與系統間的複製貼上流程可能會顯示百分比編碼形式，這正是為什麼在重視跨舊版工具可攜性時，應偏好 ASCII 模式的理由。請依據實際的 CMS、路由器、分析設定和編輯政策選擇模式，而不是假設某一種模式全面較優。編輯任何欄位都會清除舊結果，且沒有任何標題、輸出、歷史、帳號、字典或網路服務參與轉換過程，這就是為什麼相同的輸入和選項，在瀏覽器的 Unicode 實作下會產生確定性的值。
如需更深入了解，請參閱 跳過 API:在本機一次建立多個文字檔。