若要在 Word 文件中以固定的欄寬換行文字，請將文字貼到純文字的行長格式化工具，選擇一個字元數的寬度（常見為電子郵件和提交訊息的 72，終端機的 80），選擇在字邊界的軟換行或在精確欄位的硬換行，然後將結果複製回文件。這裡所說的「欄」是字元計數，而非頁面上的英吋，因為大多數在意換行的純文字目的地 — 電子郵件用戶端、Git 提交訊息內文、程式碼風格指南、man pages — 都是計算每行的字元數，而非視覺寬度。72 這個數字並非隨意：RFC 5322 這個網際網路訊息格式標準規定，訊息行應保持在 78 字元以內，而在 72 處換行可為日後加入引用層級預留空間，無需重新換行原始內容。同樣的 72 欄習慣也延續到 Git 提交訊息，其中官方的 Pro Git 書籍建議將內文換行，以便在 git log 輸出中以縮排顯示時仍能保留。80 欄是經典的終端機寬度，至今仍有風格指南引用。無論哪種情況，規則都相同：選擇一個欄數，在最後一個符合寬度的空格處斷行，絕不讓任何一行超過該限制。
軟換行 vs 硬換行：您的文字需要哪一種
將一行長文字拆成較短的行有兩種方式，選擇哪一種取決於讀取結果的是什麼。軟換行會在所選寬度內最後一個符合的空格處斷行。單字保持完整，行長大致相同，稍微窄一點或寬一點的視窗只會讓一切在視覺上重新流動，而不會改變底層的斷行。這就是電子郵件用戶端和美化輸出工具所做的。
硬換行會在精確的欄位處切斷該行，即使切在單字中間，並插入一個字面上的換行字元，使限制在檔案本身中受到強制執行。當下游工具實際強制執行該限制時 — 某些郵件轉發伺服器、特定的終端機介面、計算每行位元組的純文字格式化工具 — 您就會採用硬換行。
對於幾乎所有人類閱讀的目的地來說，軟換行是正確的選擇。原因很簡單：在精確欄位處硬換行會切開一個長 URL、長識別碼，甚至更糟的是切開表情符號的中間。軟換行可以防止這種情況 — 任何超過限制的內容會獨立成一行並被計算，這樣您會知道發生了什麼，而不必稍後才發現連結損壞。一個表現良好的硬換行實作即使在精確欄位處切斷時，仍會拒絕拆分表情符號或其他雙單位字元。預設選擇軟換行。只有在您有證據證明接收系統會拒絕超過限制的任何內容時，才切換到硬換行。
72、80、100 和 120 的由來
這些數字並非民間傳說。它們是標準和風格指南實際記載的寬度，這些慣例之所以延續數十年，是因為純文字從幾乎一開始有螢幕時就擁有固定寬度的螢幕。
| 寬度 | 由來 | 典型用途 |
|---|---|---|
| 72 | Git 提交內文慣例；為電子郵件回覆中的引用預留空間 | 提交訊息、郵件列表回覆 |
| 78 | RFC 5322 對網際網路訊息格式行的 SHOULD 限制 | 電子郵件內文、純文字電子報 |
| 80 | 經典的終端機寬度；長久以來的程式碼風格指南引用 | 原始碼、man pages、終端機輸出 |
| 100 | 現代終端機預設值；常見於更新的風格指南 | 較寬終端機中的原始碼 |
| 120 | 寬螢幕終端機；部分網頁和文件風格指南 | 長程式碼行、文件內文 |
RFC 5322 這個網際網路訊息格式標準規定，訊息的每行不得超過 998 字元，且應不超過 78 字元；72 欄的習慣早於該標準，並且仍是為日後加入引用層級預留空間而無需重新換行原始內容的數值。同樣的 72 欄習慣也延續到 Git 提交訊息，其中官方的 Pro Git 書籍建議將內文換行，以便在日誌中以縮排顯示時仍能保留。80 欄是經典的終端機寬度，POSIX fold 工具規範至今仍對其有描述。較寬的預設值（100、120）反映的是現代終端機和更新的風格指南，而非有記載的標準。除了預設值之外，8 到 500 字元之間的任何寬度都可以直接輸入。預設值是一鍵完成；自訂欄位則用於目的地指定其自身數值的情況。
在 Word 文件中以設定的欄位換行文字
Microsoft Word 內建的文字換行控制項是用來在段落周圍定位物件 — 它們是版面配置功能，而不是行長工具。若要以固定欄位換行文字，您需要改用文件的純文字版本：將文字貼到基於瀏覽器的行長格式化工具，設定欄位，然後將結果貼回。
- 貼上文字並選擇寬度。開啟Word 換行 / 行長格式化工具，將您的段落放入輸入框，然後為電子郵件和提交訊息選擇 72，為經典終端機輸出選擇 80，或輸入您自己的寬度。
- 選擇軟換行或硬換行。軟換行在最後一個符合的空格處斷行；硬換行在精確欄位處切斷。在幾乎所有情況下，保持軟換行開啟。
- 設定重新流動和縮排處理。重新流動預設為開啟 — 它會在換行前先合併每個段落內既有的斷行，讓已換行的文字能乾淨地重新換行。當既有斷行具有意義時（詩歌、程式碼、ASCII 藝術），請關閉重新流動。縮排處理是自動的：前導空格和引用前綴會被保留並從有效寬度中扣除。
- 檢查最長行的統計。結果面板會報告最長的輸出行以及保持完整的過長單字數量。如果一個段落以無縮排的句子開頭，且最長行顯示為 73，則表示換行正常運作。
- 複製換行後的結果。複製輸出並將其貼回您的 Word 文件、提交訊息緩衝區、電子郵件草稿或純文字檔案中。
一切都在瀏覽器中執行。不會上傳、儲存或附加到任何帳戶，因此相同的工作流程適用於敏感的草稿、內部文件和日常散文。
換行時保持縮排、引用和列表對齊
一個忽略結構的行長包裝器會產生在每個延續行都向右漂移的輸出，最終在錯誤的欄位為縮排段落換行。三項內容必須在換行後保持完整：縮排、空行和電子郵件引用前綴。
縮排。以四個空格開頭的段落會在每個延續行保留這四個空格，且有效換行寬度會將其扣除。縮排區塊的換行輸出會與第一行對齊到相同的欄位，而不會漂移。
空行。空行會被保留，每個段落獨立換行。一個多段落的電子郵件或提交訊息會保留其段落分隔，而不會被合併成一個長區塊。
電子郵件引用前綴。以一個或多個 > 字元開頭的行會依照相同規則被視為縮排。當您回覆訊息且引用層級從 > 增加到 >> 時，換行後的內文會保持其引用結構而不違反慣例。
長單字。軟換行絕不切斷單字。任何超過限制的內容 — 長 URL、未中斷的識別碼、十六進位雜湊 — 會獨立成一行，結果會報告有多少這類過長單字被保持完整。不會有任何內容悄悄超出您選擇的限制。
寬度以 Unicode 碼位計算，因此帶變音符號的拉丁字母、西里爾字母和希臘字母各計算為一個。東亞全形字元也計算為一個；格式化工具不會模擬終端機的雙寬渲染，這是值得了解的唯一範圍邊界。
以新的寬度重新換行已換行的文字
重新換行文字最常見的原因是，原始內容在一個欄位換行，而新的目的地預期不同的欄位 — 例如 60 欄的提交內文移至 72 欄慣例，或 78 欄的電子郵件回覆移至更緊湊的引用格式。天真的做法是直接對已換行的檔案再進行換行，這會產生零碎的輸出，每個短行都會被再次獨自換行。
重新流動模式可修正此問題。在重新流動開啟時（預設），格式化工具會先合併每個段落內既有的斷行以復原原始換行，然後以新的寬度對合併後的段落進行換行。產出結果是新的欄位下乾淨的重新換行。在重新流動關閉時，每個既有行會獨立換行 — 當既有斷行具有意義時（例如程式碼、詩歌、ASCII 藝術或任何以行為基礎且斷行為內容一部分的資料），這是您想要的行為。
軟換行也是等冪的：以相同寬度再次將輸出通過格式化工具不會改變任何內容。這使得該工具在重複的管線中是安全的 — 72 欄換行後的提交內文在第二次處理後仍維持 72 欄，因此腳本可以在多個階段呼叫相同的格式化工具而不會產生漂移。
輸入上限為一百萬字元，並以單一線性階段完成換行，即使在該大小下也能瞬間返回。對於該限制以下的所有內容，相同的工作流程可在單一步驟中涵蓋單行提交主旨、多段落版本說明以及引用的電子郵件討論串回覆。
如需更深入的探討，請參閱如何在不重寫文字的情況下清理 AI 文字。