一個在瀏覽器中執行的行數計算器，會在您貼上文字區塊的那一刻計算其中的每一行，回報總行數、空行、非空行，以及最長行的長度，而且不會將任何資料傳送到伺服器。只有在事先明確邊界規則時，計算行數才不會有歧義：換行字元（LF）、歸位字元加換行字元組合（CRLF），以及單獨的歸位字元（CR）都各產生一個行邊界，CRLF 視為單一邊界而非兩個，結尾的換行字元會產生一個最終的空行。完全空的輸入是唯一定義為零行的情況。一旦出現任何內容，計數至少為一。同一份輸入中可以混用不同的行結尾符號，這點在文字於 Unix、Windows、傳統 Mac、終端機和剪貼簿環境之間傳遞時很重要。這些規則正是區分可靠的行數統計與每次來源檔案易手就會失準的猜測之間的關鍵。
「行數計算器」工具在單一的瀏覽器作業中套用這些規則。您只需貼上，四項統計數字立即更新，計算過程從不呼叫遠端服務，因此原始碼、記錄檔、散文、清單、設定檔和字幕都能在同個頁面上以隱私方式進行檢查。
行數計算器實際上衡量的是什麼
線上行數計算器做的不只是針對每個換行字元分割文字。一個可靠的計算器會回報四項獨立的統計數字，共同描述文字的樣貌：
- 總行數 — 根據既定邊界分割後所產生的每一行計數，包括由結尾換行字元所產生的空白段落。
- 非空行數 — 經前後 Unicode 空白字元修剪後，至少包含一個字元的行。
- 空行或僅含空白字元的行 — 字元完全由空格、Tab 或其他可被 JavaScript trim 移除之空白字元組成的行。
- 最長行（字碼點） — 以 Unicode 字碼點而非 UTF-16 字碼單位、位元組或可見欄位數計量的最長行。
由於總行數永遠等於非空行數加上空行數，這四個數字構成了一個內建的交叉檢查機制。如果總數與其他兩者之和不相符，表示工具本身有錯誤；如果相符，讀者就免費獲得了一項健全性檢查。
如何在線上計算文字行數
- 在瀏覽器中開啟行數計算器工具。
- 從來源處複製您要計算的文字——無論是編輯器、聊天視窗、記錄檔、程式碼存放庫，或任何純文字欄位。
- 直接貼到編輯器中；沒有上傳步驟，也沒有提交按鈕。
- 輸入完成後，立即讀取編輯器下方的四項統計數字：總行數、非空行數、空行或僅含空白字元的行數，以及以字碼點計量的最長行。
- 將這些數字與您的編輯器或命令列工具所回報的數字進行比對，特別留意結尾換行字元的處理方式與 Unicode 規則。
- 完成後，按下「清除」以清空輸入內容，並讓所有統計數字歸零。
統計數字會隨每次按鍵而更新，因此編輯器中的部分內容也已經可以被計算。不需要任何帳號，不會透過網路傳送任何檔案，而且編輯器絕不會顯示看起來可能完整的局部預覽。
為什麼邊界規則會改變總數
造成兩組行數統計出現差異的最主要原因，是最後一個邊界的處理規則。不同的編輯器將行描述為換行字元、邏輯記錄或視覺列，某些會隱藏結尾的空段落，其他則會將其顯示出來。一個隱藏此選擇的計算器，無法與暴露此選擇的計算器達成一致。
本工具所使用的邊界規則明確且易於針對常見輸入進行驗證：
| 原始輸入 | 總行數 | 非空行數 | 空行數 | 備註 |
|---|---|---|---|---|
| （空） | 0 | 0 | 0 | 定義為零行的情況 |
| alpha | 1 | 1 | 0 | 無結尾邊界 |
| alpha + LF | 2 | 1 | 1 | 結尾邊界產生一個空行 |
| 僅有一個 CRLF | 2 | 0 | 2 | 分隔符號的兩側各有一個空段落 |
| alpha + CRLF + beta | 2 | 2 | 0 | CRLF 是一個邊界，而非兩個 |
| alpha + CR + beta（傳統 Mac） | 2 | 2 | 0 | 單獨的 CR 也是一個邊界 |
兩個連續的結尾換行字元邊界會產生兩個結尾空白段落，而不會將其合併。這符合文字實際包含的內容，並避免根據最後一行是否恰好為空而進行隱性變更。實作上會先以 CRLF 分割，再處理單獨的 CR 或 LF，因此 Windows 的邊界絕不會被重複計算。
空行、非空行與最長行：說明
區分空行與非空行不同於判斷該行是否為空。其規則是：使用 Unicode 空白字元規則修剪該行，若修剪後沒有留下任何內容，該行即為空行。純空格的行、純 Tab 的行，或兩者混合的行都是空行。像是「 hello 」這樣在可見字母前後帶有空格的行則是非空行，因為字母會在修剪後保留下來。
僅含空白字元的行仍然是輸入的一部分：其原始字元不會被移除，且仍會繼續影響最長行的長度。這意味著一個由 200 個空格組成的單行會同時被回報為空行與最長行；當最長行指標旨在反映實際貼上的內容時，這是正確的行為。
最長行指標被標示為「字碼點」，且此標籤會在結果下方再次顯示。這對三類文字來說很重要：
- 輔助平面表情符號（例如 😀）在 JavaScript 中佔用兩個 UTF-16 字碼單位，但在這裡僅計為一個字碼點。
- 分解形式的重音符號（例如字母 e 後接組合銳音符號）計為兩個字碼點，即使它們呈現為單一可見字素。
- 以零寬接合符號連接的家人表情符號包含數個字碼點，但呈現為單一符號。
字碼點長度不等於終端機寬度、不等於等寬字元格數、不等於位元組數，也不等於正規化後的文字長度。Tab 無論在編輯器中視覺上展開為多少，一律計為一個字碼點。組合標記、變體選擇器與接合符號各計為其本身的字碼點。計算器在分析前不會對 Unicode 進行正規化、展開 Tab、移除非分隔用途的歸位字元，或變更貼上的內容。
輸入上限何時會停止計算
作為瀏覽器記憶體與回應速度的保護機制，計算器最多接受 1,000,000 個 JavaScript UTF-16 字碼單位。編輯器下方顯示的大小採用相同的字碼單位計量，因此用量指示與上限一致。輸入剛好等於上限時會被完整處理。
若輸入即使僅超出上限一個字碼單位，整個分析會回傳錯誤，且所有先前的統計數字都會消失。本工具絕不會計算部分內容，也絕不會默默截斷剩餘部分。此保護機制獨立於最長行字碼點指標，因此一個輔助平面表情符號會佔用兩個單位的輸入額度，卻在最長行長度中僅貢獻一個字碼點。此區別是有意為之，且在頁面上有明確說明。
若要處理更大的輸入，實際可行的做法是使用能保留行結構的工具將來源切割、計算各部分的行數並將總數相加，同時確認切割處沒有切斷任何部分的邊界。關於檔案層級邊界規則的補充說明，請參閱「以明確邊界規則計算檔案中的行數」指南。
跨工具與編輯器比較行數統計
當兩組行數統計出現差異時，差異幾乎總是來自以下三個因素之一：結尾換行字元的處理方式、空行的定義，以及計算器是測量 UTF-16 字碼單位還是字碼點。解決差距的核對清單如下：
- 確認另一個工具是否將最後一個空行視為一行。
- 確認它是否將僅含空白字元的行視為空行。
- 確認其「最長行」指標是位元組數、UTF-16 字碼單位數、字碼點數，還是可見欄位數。
- 確認兩者的輸入採用相同的 Unicode 正規化形式，特別是針對組合重音符號與預組字元。
- 確認採用相同的行結尾解釋方式：CR、LF 與 CRLF 是否各算一個邊界，或者另一個工具將 CRLF 計為兩個？
本計算器刻意選擇一套一致的規則並將其公開於頁面上，而非聲稱每個編輯器都會顯示相同的總數。由於所有計算皆在本機執行且具有確定性，將同一序列的 UTF-16 字碼單位貼入本工具，在任何支援的瀏覽器中都會產生相同的統計數字。若有相關需求，同樣類型的即時、僅在瀏覽器中執行的分析也適用於透過「字數計算器」計算字數總計。