依照行數將文字檔分割成多個檔案，是一種以行為導向的作業，會從上到下讀取來源檔，將內容依序分割成固定行數的連續群組，再把每一組匯出成獨立的 UTF-8 文字檔。輸出的結果是一組可預期的編號片段，每個片段包含你所輸入的分塊行數，但最後一個片段除外，它會容納所有剩餘的行。來源檔中的每一行都會恰好出現在其中一個輸出檔裡，因此不會遺漏，也不會重複。整個作業都在你的瀏覽器中執行，這代表原始檔案會透過標準的 File API 在本機讀取，以 UTF-8 解碼、分組切片，再直接下載到你的電腦，整個過程不涉及任何上傳步驟。如果來源使用 CRLF 行尾（Windows 慣例）、單獨 CR（舊版 Mac）或 LF（Unix 與現代網頁），分割器都能辨識這三種格式，並將 CRLF 視為單一邊界。輸出片段一律使用 LF 行尾寫入，這能在不改變任何一行的可見字元下，將混雜的輸入統一化。你可以掌握影響結果的唯一兩項決策：交給工具處理的檔案，以及你所輸入的整數分塊大小。
以行為基礎的分割實際上是怎麼運作的
以行為基礎的分割會將來源檔視為一個有序的行清單，並在固定間隔處切片。這個工具不會重新平衡各片段、不會依照位元組大小分割、不會依照字數分割，也不會嘗試偵測段落、章節或任何更高層級的結構。每個完整的群組都包含所要求的行數，最後一個群組除外，它只容納剩下的所有內容。由於規則純粹是位置性的，因此同一個來源檔與同一個分塊大小，永遠會產生相同的行數、相同的片段數，以及相同的檔名——沒有隨機性，也沒有隱藏狀態。
每一行的字元內容都會依照解碼後的樣貌完整保留：縮排、行尾空白、標點符號以及 Unicode 文字都會原封不動地通過。工具唯一改寫的部分是行之間的換行字元，將混雜的行尾統一替換為 LF，使輸出片段保持一致。這是分割器能提供的最簡單契約，同時也符合大多數純文字、記錄檔與 Markdown 檔案的撰寫方式。
如何依照行數將文字檔分割成多個檔案
- 在瀏覽器中開啟 Text File Splitter。
- 選擇一個本機的 TXT、CSV、MD 或 LOG 檔案，且大小不得超過 10 MiB。
- 在「每片段行數」欄位中輸入一個介於 1 到 100,000 之間的整數。
- 執行分割，並檢查顯示的總行數與片段數。
- 點擊每個下載按鈕，將編號後的分塊儲存到你的電腦。
挑選符合你目標的分塊大小
分塊大小是唯一會改變輸出形狀的旋鈕。每片段行數較小會產生許多小檔案；每片段行數較大會產生少數大檔案。針對你特定檔案的精確數字會由工具本身提供：執行分割後，它會回報總行數與產生的片段數。利用這兩個數字來判斷你所選的分塊大小是否能產生合理的輸出數量——例如，一個 20,000 行的檔案若以 200 行分塊分割會產生 100 個片段，而同一個檔案若以 2,000 行分塊分割則只會產生 10 個片段。
| 目標 | 建議的分塊大小 | 選擇此範圍的原因 |
|---|---|---|
| 快速瀏覽小型筆記檔 | 100–500 行 | 維持低片段數，讓每個分塊都易於捲動 |
| 分享大型伺服器記錄檔 | 10,000–100,000 行 | 最大化每檔行數，並將下載次數減到最少 |
| 將批次資料餵入腳本 | 1,000–10,000 行 | 在片段數與每片段大小之間取得平衡 |
| 產生許多小型樣本 | 1–50 行 | 適合逐段檢視資料 |
為了更具體地說明，考慮一個 250 行的檔案搭配 100 的分塊大小。使用公式 片段數 = floor(總行數 ÷ 分塊大小) + 1（若存在餘數），你會得到 floor(250 ÷ 100) + 1 = 2 + 1 = 3 個片段。第一個片段包含第 1 到第 100 行，第二個片段包含第 101 到第 200 行，第三個片段包含第 201 到第 250 行——兩個各 100 行的完整片段，以及一個包含 50 行的最終片段。相同的輸入與相同的分塊大小永遠會產生相同的這三個片段，並具有相同的行數，因為位置性的分割是確定性的。
如果你真正的目標是剛好切成兩等份，請參閱這篇專題指南：依照行數將文字檔切成兩半。
行尾、結尾換行，以及哪些內容會保持原樣
分割器會將 CRLF、單獨的 CR 與 LF 視為行邊界，並將 CRLF 視為單一邊界而非兩個邊界。在每個輸出片段內部，行與行之間以 LF 連接，因此原本混用 CRLF 與 LF 的檔案，在所有片段中都會呈現一致的結果。這種統一化只影響行之間不可見的換行字元；它不會觸及行內任何可見字元。
來源檔最末端的一個結尾行邊界會計為額外開啟一個邏輯行。根據文件說明的規則，一個只包含單一字元 "a" 後接 LF 的檔案，會被視為擁有兩個邏輯行；對這種檔案使用分塊大小 1 進行分割時，會產生一個包含 "a" 的片段，以及另一個空白的片段。這是有意為之：它能避免工具悄悄丟棄結尾邊界，否則將會改變行數，並可能在對比前後行數總和時造成使用者困惑。
空檔案會被拒絕，因為沒有可供分割的行——當沒有內容可分配時，這項作業無法產生有意義的片段。
檔名、下載與管理大量輸出片段
輸出片段使用確定性的命名規則。原始檔案的主檔名會保留下來，每個分塊會加上字面字串 "-part-"，後接一個三位數零填補的序號，以及 .txt 副檔名。一個名為 notes.txt、擁有 250 行、搭配分塊大小 100 的檔案，會產生 notes-part-001.txt、notes-part-002.txt 與 notes-part-003.txt。無論來源是 .csv、.md 或 .log，輸出都一律使用 .txt 副檔名——這些分塊都是純粹的 UTF-8 文字，因此原本的 .csv 副檔名並不會被保留作為「每個分塊本身仍是有效 CSV」的宣告。
每次下載都是透過點擊該片段專屬的下載按鈕來觸發。工具會在點擊時建立一個暫時性的物件 URL、啟動一次下載，並立即撤銷該 URL，因此頁面中不會保留任何長期存在的 blob 物件。如果你變更了來源檔或分塊大小，先前的結果會被清除，如此一來，舊組態所產生的檔名與數量就不會被誤認為是新的結果。
由於片段是一次一個下載，當片段數很高時，瀏覽器可能會跳出允許多檔下載的授權提示。這是瀏覽器的正常行為，而非工具的限制；接受該提示後，所有分塊就會依序抵達目的地資料夾。工具並不會產生 ZIP 壓縮檔，因為這會需要引入一個額外但不必要的打包相依元件。
何時以行為基礎的分割不是合適的工具
位置性的行分割適合用於每一行都是獨立單位的檔案——純文字筆記、伺服器記錄檔、字幕式的列、簡單的清單匯出，以及簡短的 Markdown 片段。對於單一記錄合法地橫跨多行的格式，它就不是合適的選擇。
| 檔案類型 | 以行為基礎的分割是否安全？ | 原因 |
|---|---|---|
| 純 TXT 筆記 | 是 | 每一行各自獨立 |
| 伺服器記錄檔（每行一個事件） | 是 | 邊界穩定且可預期 |
| 短篇小節的 Markdown 散文 | 通常可以 | 大多數小節都能容納在單一分塊大小內 |
| 含有引號多行欄位的 CSV | 否 | 引號欄位內可以合法包含換行，在該邊界分割會破壞記錄 |
| JSON 或 XML 文件 | 否 | 物件與元素經常橫跨多行 |
| 原始碼檔案 | 視情況而定 | 函式與類別可能橫跨多行；以固定間隔分割可能把函式切成兩半 |
如果結構正確性很重要——例如 CSV 匯出、JSON、XML 或程式原始碼——請使用能理解記錄或符號邊界的格式感知解析器，只在它們之間切分。MDN 針對 Blob 與 File.text API 的文件說明了瀏覽器如何在本機解碼檔案位元組，這正是所有作業都能在電腦上執行的基礎：Blob 與 File.text。
最後，請將原始檔案視為唯一真實來源。在所有需要的分塊都下載並驗證完畢之前，請將其保留在磁碟上，因為這項作業永遠不會修改來源檔——它只會讀取。相同的解碼輸入與相同的分塊大小，永遠會產生相同的字串、相同的行數總和、相同的片段數，以及相同的零填補檔名，沒有伺服器儲存、沒有帳號，也沒有保留任何處理紀錄。
如果你正在權衡各種選項，為文字加入行號——完整解析 一文對此有詳細說明。