以固定行寬換行，代表重新排版純文字，讓每一行都落在你選定的欄數以內或剛好等於該欄數——電子郵件與提交(commit)訊息通常是 72 欄，終端機與程式碼通常是 80 欄——格式化工具會在還能容納的最後一個空格處斷行，絕不會把單一個字切成兩半。當讀者搜尋「word怎麼設定文字換行」時，他們問的通常正是這個行長問題：想在把文字貼進 Word、提交(commit)到 Git、寄到郵件群組，或顯示在終端機之前，先讓文件中的字詞排在可預期長度的行上。微軟自家的「文繞圖」按鈕其實是另一項功能——它讓文字環繞圖片與圖形排列——並不會改變一行上的字元數。就「文字換行」的行長意義而言，實際可行的做法是用一個純文字格式化工具，接收貼上的內容、套用選定的欄數，然後把同樣的字詞在正確的位置斷行輸出。這些慣例數字並非隨意訂定：網際網路郵件格式標準 RFC 5322 指出，網際網路郵件的每一行不應超過 78 個字元，也絕不能超過 998 個字元，而由來已久的 72 欄習慣，則是為了在不需重新換行的情況下，留出空間讓引用層級可以往上加。80 欄則是程式碼風格指南至今仍在參照的經典終端機寬度。這兩項慣例都被內建進文字換行／行長格式化工具，與 100 和 120 一起做成一鍵預設值。
本指南會說明純文字換行到底是什麼、為什麼 72 和 80 會是預設值，以及如何一步一步使用這個格式化工具，包括軟換行與硬換行的取捨、針對已經換行過的文字的重排(reflow)選項，還有縮排區塊與引用前綴如何在重新格式化後被保留下來。
「格式化換行文字」在純文字中實際代表什麼
純文字換行跟圖片一點關係都沒有。它指的是在字詞邊界插入換行，讓每一行連續文字都維持在目標字元數以下。編輯器、郵件用戶端與終端機自從固定寬度螢幕出現以來就一直這麼做，純文字慣例至今仍然預期如此。像 Microsoft Word 這類文書處理軟體，會在你輸入時視覺上即時重排段落，這正是為什麼「word換行」對每天使用 Word 的人來說感覺像個假問題；螢幕會自動換行。這個問題只有在目的地不是 Word 時才會浮現——當文字要進入 Git 提交(commit)訊息、會被多次引用回覆的郵件、類似 man page 的文件、程式碼註解、給固定寬度顯示器用的橫幅，或是另一個程式會逐行讀取的檔案。在所有這些場合，行長是由檔案本身決定，而非由讀者的視窗決定，唯一能控制它的方法，就是事先插入硬換行或軟換行。
因此，格式化換行文字這項工作有三項輸入：要格式化的文字、以字元為單位的目標寬度，以及換行模式(軟或硬)。輸出則是同樣的字詞、在正確位置換行，而這正是文字換行／行長格式化工具在單一線性流程中所產出的結果。
標準行寬：為什麼 72 和 80 會是預設值
這些預設值並非憑空猜測，而是對應到有文件記載的標準與行之有年的慣例：
| 寬度 | 常見用途 | 數字的來源 |
|---|---|---|
| 72 欄 | 郵件內文、Git 提交(commit)訊息內文行 | RFC 5322 建議郵件行維持在 78 個字元以下；在 72 欄換行，可以留出空間讓「> 」這類回覆引用前綴日後能加上去而不必重新換行。Git 提交(commit)沿用同樣的習慣，因為官方 Pro Git 貢獻指南建議把提交(commit)內文換行，好讓它在git log中的縮排顯示保持完整。 |
| 78 個字元 | RFC 5322 建議的上限 | 網際網路郵件格式標準本身，把 78 定為 SMTP 傳送「應該(SHOULD)」遵守的行長。 |
| 80 欄 | 經典終端機、程式碼風格指南 | 這是 1980 年代到 1990 年代實體終端機的寬度；POSIX 的fold工具規範預設為 80，也是硬換行行為的參考依據。 |
| 100 與 120 欄 | 現代程式碼風格指南、文件 | 更寬的螢幕促使部分風格指南把上限拉到 100 或 120，其中 100 是常見的上限。 |
| 998 個字元 | RFC 5322 的絕對上限 | SMTP 郵件行必須遵守的硬性上限；超過這個長度的部分都必須經過編碼。 |
這四個小型預設值在格式化工具中都只需一鍵套用，而 8 到 500 之間的其他任何寬度也都可以直接輸入，所以這些預設值只是起點，並非唯一選項。Pro Git 官方書籍中關於參與專案貢獻的章節與POSIX 的fold工具規範，是這些數字背後的兩份主要參考資料。
如何用行長格式化工具來格式化換行文字
一旦文字準備好，整個流程只需要三個動作：
- 貼上文字並選擇寬度。郵件回覆與提交(commit)訊息用 72，終端機輸出與經典程式碼註解用 80，現代程式碼用 100 或 120，若目的地有自己的規則，也可以直接輸入 8 到 500 之間的任何數字。
- 選擇軟換行或硬換行，並決定是否要重排(reflow)與處理縮排。軟換行會在還能容納的最後一個空格處斷行，絕不會切開一個字詞；硬換行則會在必須遵守嚴格上限的檔案中，精確地在指定欄數處切斷。重排(reflow)會先把段落內既有的換行合併起來，再重新換行，所以原本以錯誤寬度換行過的文字，重新輸出後會很乾淨。縮排處理預設為開啟，會在每個接續行上保留前導空格或引用前綴。
- 閱讀統計資訊並複製結果。輸出面板會回報輸入行數、輸出行數、最長的輸出行，以及在軟換行下被完整保留下來的過長字詞數量。這些數字中沒有一個會在你沒看到報告的情況下超出上限。
舉例來說，假設有人在自己的編輯器裡把這段提交(commit)內文段落寫成一整行：
This commit adds the new pagination helper to the user API. It supports both offset and cursor modes and falls back to offset mode when the cursor token is missing or has expired. Tests cover the empty-result case, the single-page case, and the multi-page case where the cursor advances past the dataset boundary.
把它貼進格式化工具、寬度設為 72、開啟重排(reflow)後，會變成不超過 72 個字元的多行，在還能容納的最後一個空格處斷行，整個段落仍維持是單一段落。同一段文字若重新以寬度 100 換行，會產生明顯較長的行，顯示出改變的是欄數，而不是字詞本身。
軟換行對比硬換行：什麼時候該用哪一種
對於任何會被人當作散文閱讀的內容——電子郵件、提交(commit)訊息、man page、README、部落格草稿——軟換行都是正確的選擇。它把換行視為一種呈現方式的決定，絕不會切開一個字詞。如果單一個字詞比選定的寬度還長——一個很長的網址、很長的識別碼、很長的雜湊值——軟換行會讓那個字詞單獨留在自己那一行，而不是把它切開，結果面板也會回報有多少個這樣的字詞被完整保留下來，讓上限絕不會在你不知情的情況下被超過。軟換行同時具有冪等性：把輸出用同樣的寬度再跑一次格式化工具，結果不會有任何改變，這在換行過的文字可能會被再次換行的管線流程中很有用。
硬換行則適合給固定寬度工具消費的輸出：7 段顯示器用的橫幅、另一個程式會在已知欄位逐行讀取的檔案、必須塞進狀態列的記錄行，或是欄位位置本身就是格式一部分的 S-record 或結構化記錄。硬換行會精確地在指定欄數切斷，並且不會切開一組 Unicode 代理對(surrogate pair)，所以表情符號絕不會被腰斬。寬度是以 Unicode 碼點計算的，而這個格式化工具也明白說出它唯一的邊界：東亞全形字元算作一個碼點，而終端機在螢幕上實際套用的雙倍寬度顯示效果並不會被模擬出來。
在不破壞結構的前提下重新換行既有文字
你需要格式化的文字很少會是單一一長行。更常見的情況是：一段已經以 60 或 65 個字元換行過的段落、一段在檔案改用 100 欄風格後仍停留在 80 欄換行的程式碼註解，或是一則以某個寬度換行、又在另一個寬度被引用回覆的郵件。重排(reflow)選項正是為了讓這些情況也能正確處理：開啟重排時，格式化工具會先把每個段落內既有的換行合併起來，再以新的寬度重新換行，所以舊有的 60 欄文字換成 100 欄後會很乾淨。關閉重排時，每一行既有的換行都會各自被單獨換行，這適用於換行本身就有意義的情況——例如一首詩、每一行都是一筆記錄的設定檔，或是被攤平成文字的表格。
在這整個過程中，結構都會被保留下來。空白行仍然是空白行。每個段落各自換行，所以段落之間的硬換行不會變成段落內部的軟換行。縮排會從有效換行寬度中扣除，所以一個以四個空格開頭的段落，會在每個接續行上保留這四個空格，維持對齊，而不會隨著行數增加而逐漸往右偏移。同樣的規則也適用於引用郵件的前綴：角括號前綴會被算作縮排，所以回覆郵件即使在以新寬度重新換行之後，仍會逐行保留其引用結構。
就輸入大小而言，這個格式化工具把文字上限設在一百萬個字元，並在單一線性流程中執行，所以即使到達這個上限也能即時回應。一切都在瀏覽器中執行：不會有任何內容被上傳、儲存或附加到帳號，這讓它適合用在程式碼、郵件草稿與尚未發布的草稿上。
讓換行寬度符合目的地的需求
選擇合適的寬度，主要取決於這段文字接下來會用在哪裡。對於 Git 提交說明的內文來說，72 是常用的數字，因為 Git 官方的貢獻指南就建議這個寬度，而且提交內容經常會在 git log 的輸出畫面、pull request 的審查介面，以及像 git rebase -i 這類工具中被縮排顯示。對電子郵件來說，72 同樣是正確的答案，因為郵件群組回覆會疊加引用前綴，而 72 加上好幾層「> 」符號後，仍然落在 RFC 5322 建議的 78 字元以內。對程式碼註解與原始碼來說，80 是能滿足所有舊式風格指南的保守選擇，而 100 則是許多現行風格指南所允許的現代替代方案。對於既會在終端機中閱讀、也會在網站上閱讀的 README 與類似 man page 的文件來說，72 或 80 能讓文字內容緊湊到在兩種場合都能舒適閱讀。
換行完成後，下一步通常是為了審查或製作文件而加上行號 — 這種情況下，Add Line Numbers to Text指南會說明如何從指定的起始值開始，為換行後的輸出內容加上行號。反過來說，如果貼上的內容已經含有你不想要的強制換行，關閉重新排版功能的 Word Wrap / Line Length Formatter，則會分別獨立處理每一行既有的內容。
如果你還在權衡選項，How to Generate Random Words in Word Documents對此有詳細說明。