大量行號編號會為貼上段落中的每一個邏輯行（包括空白行和僅含空白的行）加上從 0 到 999999 之間選出的連續整數當作前綴，然後在單次執行中將結果匯出為最多一百萬個字元的 UTF-8 純文字檔。整個轉換過程完全在目前的瀏覽器分頁中執行，因此來源文字絕不會傳送到伺服器;一旦頁面載入完成，任何編號過的批次都不需要帳號、API 金鑰或網際網路連線。由於每個輸入行都會保留原本的位置，三位講者的逐字稿和九千行的記錄檔會套用相同的規則:數行數、加上選定的編號與分隔符，然後重複。只要掌握了這條單一規則，審閱者就能把程式碼片段、課堂筆記、支援對話紀錄或法律證物轉換成其他人(以及其他工具)能安心引用的參考資料。
對大多數想尋找為大量文字加上行號方法的人來說，瓶頸很少是規則本身，而是工作量的大小。記錄回放、長篇聊天機器人對話、堆疊追的貼文，或單一原始檔，字元數輕鬆就能達到數十萬，而許多小型工具一旦輸入變長，就會變慢、截斷，或悄悄地把空白行忽略掉。一個在四十行和四十萬行之間行為一致的大量處理流程，正是憑藉設計消除了這項風險。
單次執行中，大量行號編號實際上做了什麼
大量編號並非必須手寫腳本的迴圈。為文字加上行號工具會把貼上的文字視為一串邏輯行，從上到下一次掃過，每讀到一行就在預覽中寫出一行編號後的行。僅含空白的行仍然算行，Tab 鍵和雙空白會保留下來，而原始行的文字絕不會被修剪、重新排版，或在原地改寫。預覽所顯示的內容就是下載檔案中會得到的內容，因此螢幕上看到什麼，檔案裡就會收到什麼。
加在每一行前面的前綴是純粹的十進位數字。沒有依據地區設定的千分位分隔符、沒有羅馬數字模式、沒有字母序列，也沒有隱形的樣式。編號可以從允許輸入範圍內的任何非負整數開始，然後對每一個後續的邏輯行加一。當最後產生的編號數值超過六位數時，數字會繼續印出;六位數的上限僅用來驗證使用者輸入的起始值，在執行階段絕不會默默地把序列迴繞或截斷。
貼上之前，先了解輸入、選項與硬性上限
在提交大量貼文之前，先了解每個選項的界線會有幫助，因為某些無效的組合會產生明確的錯誤，而不是產生部分結果。下表摘要列出工具會事先驗證的所有數值。
| 控制項 | 允許的值 | 邊界行為 |
|---|---|---|
| 輸入長度 | 1 到 1,000,000 個字元 | 輸入為空會顯示錯誤;不會產生任何結果 |
| 起始編號 | 最多 6 位數的非負整數(0 到 999999) | 接著每一個邏輯行加 1，如果執行批次很長，印出時可能會超過六位數 |
| 分隔符 | 字面字串，0 到 20 個 Unicode 字元，不進行正規表示式解讀 | 超過 20 個字元會顯示錯誤，且不會產生任何輸出 |
| 補零 | 開啟或關閉 | 寬度依最後產生編號的位數決定，絕不是使用者設定的固定值 |
| 輸出格式 | 純 UTF-8 文字，不含位元組順序標記 | 無論原始輸入使用何種行尾符號，輸出行一律以單一 LF 連接 |
這些限制衍生出一些實際的結果。分隔符可以是單一句點、句點加空白、冒號、垂直線、貼上的 Tab 字元，或是空字串，它會按照所寫的原樣插入在編號與原始文字之間。20 個字元的上限對幾乎任何實際的分隔符都相當寬鬆，但能避免不小心輸入整段落長度的字串。1,000,000 字元的輸入上限可讓瀏覽器分頁中的作業保持流暢——非常大的貼文仍能在單次掃描中完成，而不必排成多個區塊。
為大量段落的每一行編號
從一份大量貼文到可下載的編號檔案，所走的路徑和處理十行時完全一樣，只是輸入更長。
- 把大量文字貼上或輸入到輸入區。一次最多可接受一百萬個字元的貼文，因此除非你想同時保留多份編號輸出，否則不需要手動把文字切成小塊。
- 選擇起始編號、分隔符，以及是否要用前置零來補齊數字。只有起始編號必須輸入;分隔符可以是空的，補零功能也可以保持關閉。
- 產生結果。預覽會立即渲染，並採用預先格式化(等寬)的換行方式，讓過長的行可以在視覺上水平捲動，而不會額外增加會洩漏到下載檔案中的換行字元。
- 如果預覽不符合需求，可以編輯任何選項。這麼做會清除舊的結果並撤銷其物件 URL，因此先前下載的檔案不會被誤認為目前的輸出。
- 下載 UTF-8 TXT 檔。檔案使用 LF(Line Feed)行尾符號，沒有位元組順序標記，而且內容正好就是你在預覽中看到的那些行。
如果讀者想先在較小的樣本上驗證格式，同樣的五個步驟套用到三十行的貼文，所產生的輸出可以在 Notepad、Sublime Text、VS Code、vim 或任何其他純文字檢視器中順利開啟。一旦選項的選擇感覺合適，同樣的貼上即完成流程就能在不改變任何步驟的情況下擴展到更大的文字量。
空白行、補零與分隔符在大規模下的行為
當輸入變長時，有三種行為往往會讓第一次使用的使用者感到意外，而每一種都值得刻意處理。
空白行會計入編號。每一個邏輯行——包括空行和僅含空白的行——都會拿到下一個整數。如果輸入是單字 "alpha"、一個空白行，以及單字 "beta"，輸出會包含三個編號行:1 對應 alpha,2 對應空白行，3 對應 beta。輸入最末端如果有一個尾端換行，也會再產生一個編號過的空白行，這能保留直接從編輯器複製出來的檔案原本的行結構。
補零的寬度依最後一個編號決定，而不是使用者設定的固定值。當開啟補零時，前綴度會依該次執行中最後產生編號的位數而定，因此同一個選項在短輸入和長輸入下表現會不同。從 8 開始編號三行，會產生 08、09 和 10——兩位數的前綴，因為最終值達到兩位數。從 1 開始編號九行，則會產生普通的一位數編號，因為最終值從未超過一位數。關閉補零則會以每個編號的自然寬度呈現，絕不會以任何方式更動原始行的文字。
分隔符以字面方式採用。你所輸入或貼上的內容會原封不動地放在編號與該行之間;它不會被當作正規表示式來解讀，不會被跳脫，也不會被修剪。常見的選擇包括:用於論文式編號的句點加空白、用於法律條款的冒號、當編號後的輸出要貼進試算表或固定寬度欄位時所使用的 Tab，以及只想讓數字和行文字直接相時所使用的空字串。
下載之後:檔案格式、行尾符號與重新執行
在大量處理的工作中，輸出的一致性很重要，因為檔案的接收者通常無從得知它是如何產生的。下載的檔案是純 UTF-8 文字，不含位元組順序標記，因此在 Windows 的 Notepad、Linux 主控台，以及偏好 LF 的 Mac 編輯器中都能以相同方式載入。輸出永遠在每一行之間使用單一的 LF(Line Feed)字元，這代表 Windows 的 CRLF 輸入、傳統 Mac 的 CR 輸入，以及 Unix 的 LF 輸入，都會在結果中統一成單一的整齊格式。
對修改過的輸入重新執行工具，設計上同樣乾淨。產生結果時，輸入區不會被更動，因此你可以貼上修正過的版本、變更分隔符，並產生新的檔案，而無需重建原本的貼文。在結果就緒後編輯任何選項，都會清除舊的預覽並撤銷先前的下載 URL，這道防護機制能避免過時的檔案被當作目前的輸出流傳。預覽使用預先格式化的換行方式，因此過長的行在螢幕上會以視覺方式換行，但下載的檔案仍保持單一不中斷的行——所以視覺上的行數永遠不會與你儲存的檔案不一致。供參考之用，下載路徑會把該字串組裝成 UTF-8 文字的 Blob——這是用於本機檔案下載的標準瀏覽器機制，在 MDN 有相關說明——因此檔案是在裝置本機產生，而不是從伺服器取得。
值得了解的編號大量文字的使用情境
編號過的行是穩定的參考依據，而許多工作都仰賴這些參考在第一次就必須正確。在審閱遠端 pull request 或封存的程式碼片段時，程式碼審閱經常以行號來引用特定行。當每一句口語內容都帶有編號時，逐字稿就能被搜尋。詩詞、劇本和舞台指示的草稿，會為每一行取得一個明確無歧義的位址。支援記錄回放和當機傾印檔在每列都編號，且工程師與客戶看到的內容一致時，討論起來會容易得多。法律審閱工作副本、課堂講義和會議紀錄，都能從同一個簡單的轉換中受益:每一行都取得一個穩定的識別碼，而後續的工作流程就能放心地加以引用。
此處介紹的大量行號編號工作流程，適合用於以下任務:在一個掃描中為每一行加上連續整數，並能完全控制起始值、分隔符與補零寬度。相鄰的工具在各自的領域中仍然有用——當唯一的工作只是計算行數時，專用的行數計數器是更好的鄰居;而當前綴需要是任意的文字而非編號序列時，通用的前綴/後綴工具則更直接。
如果你正在權衡各種選項，在瀏器中為大型文字的每一行加上前綴對此有詳細說明。
如果你正在權衡各種選項，如何在不上傳的情況下免費將 PDF 轉換為 Markdown對此有詳細說明。