當您使用 Text File Splitter 將文字檔案內容分割成編號 TXT 區塊時，每次執行都會從本機的一個 TXT、CSV、MD 或 LOG 檔案開始。請選擇大小不超過 10 MiB 的檔案，輸入介於 1 到 100,000 之間的整數上限，並依序分割內容。每個完整區塊都包含所指定的邏輯行數，而最後一個區塊則包含其餘的行。工具不會自動將檔案平均分成兩半，也不會重新平衡最後一組。檔案讀取、分割與下載皆在瀏覽器本機進行，原始檔案絕不會遭到變更。
瞭解一行如何計算
接受的輸入為一個 TXT、CSV、MD 或 LOG 檔案，大小最多 10 MiB。空白檔案會被拒絕，因為其中沒有可分割的實質內容。副檔名檢查可辨識符合條件的檔案類型，但無法證明 CSV 或 Markdown 語法是否有效，也不會驗證來源編碼。瀏覽器會在本機讀取所選檔案，並將其位元組解碼為 UTF-8。如果檔案使用其他編碼，或二進位內容帶有容易混淆的文字副檔名，解碼後的文字可能包含替換字元。
行尾符號會決定邏輯行數。Text File Splitter 將 CRLF、單獨的 CR 和 LF 視為行界線。CRLF 序列會算作一個界線，而非兩個。產生的區塊會以 LF 連接各行，因此在輸出的各個部分中，混合的來源行尾符號都會變得一致。除了分隔符號的正規化之外，每個解碼後行的字元內容都會保留，包括縮排、行尾空格、標點符號及 Unicode 文字。
結尾的行界線也會啟動最後一個邏輯行。例如，包含「a」且後接 LF 的檔案具有兩個邏輯行：「a」和一個空白的結尾行。保留該界線可避免來源的最終換行被無聲捨棄。區塊大小為一行時，這兩個邏輯行可能產生非空白的第一個部分和空白的最後一個部分。
| 詳細資訊 | 定義的 Text File Splitter 行為 |
|---|---|
| 接受的輸入 | 一個 TXT、CSV、MD 或 LOG 檔案 |
| 最大檔案大小 | 10 MiB |
| 有效區塊大小 | 介於 1 到 100,000 之間的整數 |
| 行界線 | CRLF、單獨的 CR 和 LF；CRLF 算作一個界線 |
| 結尾界線 | 建立最後一個空白邏輯行 |
| 行內容 | 解碼後會保留縮排、行尾空格、標點符號和 Unicode |
| 輸出分隔符號 | LF，不論來源使用混合行尾符號與否 |
| 輸出檔案 | 副檔名為 TXT 的編號 UTF-8 文字檔案 |
選擇兩個部分的區塊大小
Text File Splitter 會從第一行開始，依序將邏輯行分組。它不會重新分配各行以平衡最後一組。若要產生恰好兩個部分，請使用已驗證的邏輯行總數 T，以及小於 T 且不小於 T 的一半的區塊大小 K。換句話說，T 必須大於 K，且不得大於 K 的兩倍。第一個部分便會包含 K 行，第二個部分則包含其餘的行。
若要讓兩個部分盡可能平均，請將 T 除以二後向上取整，並且只有在該值不超過 100,000 時才將其輸入為 K。這會在第一個部分放入 K 行，在第二個部分放入 T 減 K 行。如果 T 是奇數，第一個部分會比第二個部分多一行。此種平衡來自所選的區塊大小；工具本身不會重新平衡各組。如果 T 大於 200,000，沒有任何允許的區塊大小能產生恰好兩個部分。
例如，如果已驗證的總數為 10 個邏輯行，而您輸入 5，檔案就會被分成兩個部分。第一個部分包含五行，第二個部分包含其餘五行。如果總數只有一個邏輯行，沒有任何允許的區塊大小能建立兩個部分。
如果您還不知道總數，請先以任何有效的行數執行初步分割，並讀取顯示的邏輯行總數。您不需要下載初步產生的各個部分。將行數調整為目標值，再次分割，並確認結果包含兩個部分。變更行數會清除先前的結果，避免其檔名和計數與新設定混淆。
分割檔案並檢查結果
- 選擇來源檔案。 開啟 Text File Splitter，並選擇一個非空白的 TXT、CSV、MD 或 LOG 檔案。確認其大小不超過 10 MiB。副檔名不同的檔案並非接受的輸入。
- 輸入每個部分的行數。 使用介於 1 到 100,000 之間的整數。若要產生恰好兩個部分，請選擇符合已驗證邏輯行總數與區塊大小之間關係的值。在產生任何區塊之前，小數、零、負值及超過 100,000 的值都會被拒絕，因此無效設定不會留下部分結果。
- 分割並驗證。 開始分割，然後檢查顯示的行數總計和部分數。如果結果未包含恰好兩個部分，請變更行數並再次執行分割。變更所選檔案或行數都會清除先前的結果，避免舊檔名和計數與新設定混淆。
- 下載編號區塊。 請分別下載每個產生的部分。由於沒有 ZIP 壓縮檔，當要求下載多個檔案時，瀏覽器可能會詢問權限。
瞭解每個下載部分包含哪些內容
原始基本檔名會保留，並在後面接上「part」及三位數字序列，例如 notes-part-001.txt 和 notes-part-002.txt。產生的副檔名一律為 TXT，因為每個輸出都是純 UTF-8 文字 Blob。來源 CSV 或 Markdown 檔案不會產生帶有那些原始副檔名的區塊，也不應自動將編號 TXT 檔案視為各自有效的 CSV 或 Markdown 文件。
瀏覽器的解碼步驟遵循 MDN 的 File.text 文件所述行為，將檔案位元組讀取為 UTF-8。可下載的輸出會建立為 Blob。每個下載按鈕在點擊時都會建立暫時的物件 URL、觸發一次檔案下載，並立即撤銷該 URL。顯示結果時不會建立長期存在的物件 URL。
檔案讀取、分割與下載皆在瀏覽器本機進行。來源位元組不會上傳至 Lizely，而工具也未提供伺服器儲存空間、帳戶或保留的處理紀錄。相同的解碼輸入和行數一律會產生相同的字串、行數總計、部分數及補零後的檔名。
為較大的分割作業規劃個別下載
每個部分都有自己的下載按鈕，且每個產生的區塊都必須分別下載。當要求下載多個部分時，瀏覽器可能會顯示重複下載權限提示。請利用三位數的部分序列追蹤預期順序，再將已下載檔案數量與顯示的部分數比較。當檔案包含結尾界線時，這項檢查尤其重要，因為文件化的計數規則可能產生空白的最後一個部分。
依檔案結構選擇方法
這是一項刻意採用簡單逐行處理的作業。Text File Splitter 不會重新平衡區塊、不會依位元組大小分割、不會依單詞分割、不會偵測段落，也不會剖析記錄。當引號欄位包含換行時，它也無法讓 CSV 記錄保持完整。JSON、XML、原始碼和 Markdown 建構同樣可能跨越多行，因此從行界線切分可能會破壞有效的結構。
| 使用案例 | 預期結果或注意事項 |
|---|---|
| 純文字清單、記錄檔、類似字幕的列、簡單匯出或文字語料庫 | 非常適合可預期的逐行批次處理 |
| 引號欄位包含換行的 CSV | 邏輯記錄可能會被分割；當記錄完整性很重要時，請使用格式感知的 CSV 剖析器 |
| JSON、XML、原始碼或多行 Markdown 結構 | 界線可能會破壞語法；在依賴每個區塊都能獨立使用之前，請使用格式感知的剖析器 |
| 非 UTF-8 或帶有文字副檔名的二進位內容 | 解碼後可能會出現替換字元；請轉換或重新編碼來源，並檢查結果 |
保護原始檔案並驗證目的地
在所有必要的區塊皆已下載並檢查完畢之前，請保留來源檔案。原始檔案絕不會遭到修改，但其行界線會依分割工具文件化的計數規則解讀，而輸出分隔符號則會正規化為 LF。請在即將使用這些區塊的應用程式中檢查具代表性的區塊，尤其是第一個、中間部分和最後一個部分。
請特別留意結尾空白行、Unicode 字元、縮排及行尾空格。空白的最後一個部分可能是結尾界線規則所產生的有效結果。如果目的地要求分割後的內容為有效的 CSV、XML、JSON 或 Markdown，請使用適當的剖析器或轉換器驗證每個輸出，而不要只依賴來源副檔名。