若要在 Word 文件中以固定欄寬自動換行，請把文字貼到純文字行長格式化工具，選擇一個以字元數計算的寬度（電子郵件和提交訊息常用 72，終端機則用 80），選擇在字詞邊界處的軟換行，或是在精確欄位處的硬換行，然後把結果複製回文件。這裡所謂的「欄」指的是字元數，而非頁面上的實際英寸，因為大多數在意換行效果的純文字目的地——電子郵件用戶端、Git 提交訊息本文、程式碼風格指南、手冊頁面——都是計算每行的字元數，而不是視覺寬度。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 | 經典終端機寬度；長期被多項程式碼風格指南引用 | 原始碼、手冊頁面、終端機輸出 |
| 100 | 現代終端機預設值；常見於更新的風格指南 | 較寬終端機中的原始碼 |
| 120 | 寬螢幕終端機；部分網頁與文件風格指南採用 | 較長的程式碼行、文件本文 |
RFC 5322 這份網際網路訊息格式標準規定，每行訊息不得超過 998 字元，建議不超過 78 字元；72 欄的習慣早於這份標準存在，至今仍是預留引用層級空間、讓原始內容不必重新換行的數值。同樣的 72 欄習慣也沿用到了 Git 提交訊息中，官方《Pro Git》一書便建議將本文換行，以便在日誌中以縮排顯示時仍能保持原貌。80 欄則是經典的終端機寬度，至今仍記載於POSIX fold 工具規範中。更寬的預設值（100、120）反映的是現代終端機與更新版風格指南，而非某份正式標準。除了預設值之外，也可直接輸入 8 到 500 字元之間的任何寬度。預設值一鍵即可套用；自訂欄位則留給目的地明確指定其他數字時使用。
在 Word 文件中以設定欄位換行
Microsoft Word 內建的文字換行控制項是用來在段落周圍配置物件的——它屬於版面配置功能，而非行長工具。若要在固定欄位換行，應改用文件的純文字版本：把文字貼到瀏覽器版的行長格式化工具，設定欄位，再把結果貼回。
- 貼上文字並選擇寬度。開啟 Word Wrap / Line Length Formatter，把你的段落放進輸入框，然後選擇 72（用於電子郵件與提交訊息）、80（用於經典終端機輸出），或自行輸入寬度。
- 選擇軟換行或硬換行。軟換行在最後一個符合的空格處斷行；硬換行則在精確欄位處切斷。除了少數例外情況，請保持使用軟換行。
- 設定回流與縮排處理。回流預設為開啟——它會在換行前先合併每個段落內既有的換行符號，讓已經換行過的文字能乾淨地重新排版。當既有的換行具有意義時（詩歌、程式碼、ASCII 藝術），請關閉回流。縮排處理則是自動進行：開頭的空格與引用前綴會被保留，並自有效寬度中扣除。
- 檢查最長行的統計資訊。結果面板會回報最長的輸出行，以及完整保留的超長字詞數量。如果某段開頭是一句未縮排的句子，而最長的一行為 73 字，即代表換行功能正常運作。
- 複製換行後的結果。複製輸出內容，貼回你的 Word 文件、提交訊息緩衝區、電子郵件草稿，或純文字檔案中。
所有處理都在瀏覽器中完成。不會上傳、儲存或綁定任何帳戶，因此同一套流程也適用於敏感草稿、內部文件與日常散文。
換行時保持縮排、引用與列表對齊
一個忽略結構的行長換行工具，會讓輸出在每個延續行逐漸向右偏移，最終在錯誤的欄位把縮排段落切斷。換行後必須保持完整的有三項：縮排、空行，以及電子郵件引用前綴。
縮排。以四個空格開頭的段落，會在每個延續行保留這四個空格，而有效換行寬度也會將它們扣除。縮排區塊的換行結果會與第一行對齊同一欄位，而不會向右漂移。
空行。空行會被保留，每個段落各自獨立換行。多段落的電子郵件或提交訊息會保留段落分隔，而不會被合併成一整塊。
電子郵件引用前綴。以一個或多個 > 字元開頭的行，依相同規則視為縮排。當你回覆訊息、引用層級從 > 增加為 >> 時，換行後的本文會保持引用結構，不會違反慣例。
過長的字詞。軟換行絕不切開字詞。任何超過限制的內容——過長的 URL、未中斷的識別碼、十六進位雜湊值——會單獨留在自己的一行，結果會回報完整保留的這類超長字詞數量。不會有任何內容悄悄超出你設定的上限。
寬度以 Unicode 字碼點計算，因此帶附加符號的拉丁字母、斯拉夫文與希臘文皆各自計為一字。東亞全形字元同樣計為一字；本格式化工具並不模擬終端機的雙寬字元渲染，這是唯一值得留意的範圍限制。
以新寬度重新換行已換行過的文字
重新換行最常見的原因是：原文原本以某個欄位換行，而新的目的地期望不同的欄位——例如 60 欄的提交本文要改為 72 欄慣例，或是 78 欄的電子郵件回覆要改成更緊湊的引用格式。天真的做法是直接對已經換行過的檔案再換行一次，結果會讓每一短行都被再各自重新排版，輸出參差不齊。
回流模式可解決此問題。在回流開啟時（預設值），格式化器會先把每個段落內既有的換行合併，還原原本的換行，再以新寬度對合併後的段落重新換行，輸出就是在新欄位下整齊的重新換行結果。關閉回流時，每一行則各自獨立換行——這適用於既有的換行具有意義的情況，例如程式碼、詩歌、ASCII 藝術，或任何以行為單位、斷行本身即屬內容的資料。
軟換行也是等冪的：以同一寬度再次將輸出送入格式化器，結果不會改變。這讓此工具在重複的管線中也能安全使用——72 欄換行後的提交本文經過第二次處理仍維持 72 欄，因此腳本可以在多個階段呼叫同一個格式化器，而不會產生漂移。
輸入上限為一百萬字元，於單一線性階段中完成換行，即使在該規模下也能瞬間回應。在這個上限以內，無論是單行提交標題、多段落版本說明，或是一串引用電子郵件回覆，都能在同一個步驟中完成。
想深入了解，請參閱 如何在不重寫文字的情況下清理 AI 文字。
想深入了解，請參閱 如何在不上傳的情況下從 Gmail 萃取電子郵件。