Microsoft Word 中的自動換行會將文字流向頁面的右邊界或周圍文字方塊的欄寬，而不是固定的字元數——因此，如果你需要每一行都在 72、80 或任何其他欄位結束，換行必須在文字進入 Word 之前就完成。 MS Word 並沒有像舊式終端機編輯器那樣提供「在第 N 個字元處換行」的設定。Word 會在你輸入時以及頁面配置變更時，以視覺方式重新排版段落，而想在 Word 文件中獲得可預測、以字元數計算的換行，唯一實際可行的方式是先在一個支援固定寬度的工具中完成換行，再貼上結果。Word Wrap / Line Length Formatter 正是為此設計：貼上文字，從 8 到 500 個字元之間選擇寬度，選擇在字詞邊界進行軟換行，或在精確欄位進行硬換行，然後複製出每一行都按照你指定位置結束的文字。該結果貼進 MS Word 時會以預先格式化的內容呈現，保留你所指定的換行，因此無論 Word 本身的邊界、縮放等級或視窗大小為何，每一行都會落在自己的視覺位置上。這是提交訊息、郵件列表回覆、程式碼註解，以及任何必須在 Word 自動重排中存活的純文字區塊所採用的方法。
「在 MS Word 中換行」這個詞彙其實涵蓋了兩個不相關的功能。本文要討論的是第二個：控制每行的字元寬度，使純文字內容在進入 Word 文件後仍能保持其形狀。
Microsoft Word 中「wrap」的兩種含義
第一種含義是圖片格式或圖案格式功能區上的排版功能：文繞圖，提供「矩形」、「緊密」、「穿透」、「上下型」和「浮於文字下方」等選項。該功能用於定位圖片或圖案，並決定周圍段落文字如何環繞它，與行長完全無關。
第二種含義是 Word 對文件中每個段落套用的換行行為：當你輸入時，Word 會在文字區域的右邊緣切斷該行並開始新的一行，然後在你編輯、調整視窗大小或變更頁面設定時重新排版整個段落。這就是從文字編輯器沿襲而來的「自動換行」，也是人們詢問如何讓每一行在特定字元數結束時所指的意思。
Word 內建的自動換行是視覺化且動態的：同一個段落在窄視窗中可能重排為 60 個字元，在寬視窗中則為 95 個。對於必須在所有環境下看起來都相同的文件——存檔在純文字記錄中的提交訊息、帶有引文前綴的郵件列表回覆、原始檔案中的程式碼註解——這種視覺化的換行是錯誤的工具。你需要的是能產生硬性、可預測行尾的換行，這正是固定寬度換行所提供的。
為什麼固定寬度換行在 Word 文件中仍然重要
有幾項純文字慣例仍然要求行長保持在特定欄位以下，而 Word 文件往往是在文字被電子郵件寄出、存檔或貼進程式碼審查之前的最後一站。
- 電子郵件本文。網際網路訊息格式標準規定訊息的每一行不應超過 78 個字元，而將本文在 72 個字元處換行，可以預留空間加入引文層級而不必強制重新換行。
- 郵件列表回覆。每一層引文都會在每行前面加上一個或多個字元，因此原始訊息必須一開始就夠短，才能容納這些前綴。
- Git 提交訊息。廣泛遵循的 Git 慣例將提交訊息本文在 72 欄處換行，使訊息在 git log、程式碼審查工具和終端機用戶端中以縮排顯示時仍能保持完整。
- 程式碼註解和原始檔案。經典的 80 欄終端機度仍被程式碼風格指南引用，超出該寬度的註解在以正好 80 欄呈現的編輯器中會被截斷。
- 手冊頁、README 和純文字存檔。任何以原始文字形式散佈的內容，在與讀者終端機相符的固定寬度下閱讀效果最佳。
Pro Git 書在其 Contributing to a Project 頁面中記錄了 72 欄提交本文的慣例，而 Unix 系統歷史上用於換行的 fold 工具的 POSIX 規格，則由 The Open Group 以預設 80 欄加以記錄。
如何為 MS Word 以固定欄寬換行
以下是把文字以可預測、以字元數計算的行尾放入 MS Word 文件的實用工作流程。
- 開啟 Word Wrap / Line Length Formatter，在瀏覽器中將來源文字貼入輸入框。內容不會上傳，工具在本機頁面中執行。
- 選擇寬度。點選 72 預設值用於電子郵件本文和提交訊息，80 用於經典終端機輸出和程式碼註解，100 用於現代終端機和 README，120 用於較寬的文件，或直接輸入 8 到 500 之間的任何整數。
- 選擇換行模式。軟換行會在最後一個可容納的空格處斷行，因此絕不會切斷任何字詞。硬換行則在精確的欄位處斷行，這是當每行無論如何都必須低於限制時所需要的。縮排處理和重排是同一面板上的獨立切換選項。
- 若文字已經以不同寬度換行，請保持重排開啟。重排會在換行前先合併各段落內既有的換行符號，因此原本為 60 欄的文字能以新的寬度乾淨地重新換行。當既有換行具有意義時——詩歌、原始程式碼、地址清單——且希望每一行獨立換行時，請關閉重排。
- 檢查工具在換行後回報的最長行統計。若最長的輸出行等於或低於你選擇的寬度，則換行結果是乾淨的。該工具也會回報有多少超長字詞被保留為完整，確保不會有任何內容悄悄超出你的限制。
- 複製換行結果並貼入 MS Word。在 Word 中，若內容為程式碼或終端機輸出，請將段落設為等寬字型；若為散文，則設為比例字型——你所貼上的換行會保留為段落標記，因此無論 Word 本身的邊界為何，每一行都會在你指定的位置結束。
若內容會在 Word 中以比例字型和非預設字型大小顯示，請貼入固定寬度的文字方塊，或使用具有明確寬度的表格儲存格，讓行尾仍能與原始欄位邊界對齊。
軟換行與硬換行在 Word 文件中的比較
軟換行和硬換行之間的選擇，取決於當字詞長度超過所選寬度時該如何處理。這兩種模式在字詞完整性與行長嚴格性之間進行取捨，正確的選擇取決於目的地。
| 模式 | 在限制處的行為 | 最適合用於 |
|---|---|---|
| 軟換行 | 在最後一個可容納的空格處斷行；超長字詞獨立成行，並在結果中回報。 | 散文、提交訊息、電子郵件本文、文件——任何不應切斷字詞的場合。 |
| 硬換行 | 在精確欄位處斷行，但絕不會在表情符號或任何其他雙碼單位字元中間切斷。 | 嚴格的終端機輸出、固定欄位記錄，或任何要求每行低於硬性字元限制的目的地。 |
軟換行具有等冪性：以相同寬度再次將軟換行後的輸出送入工具，會產生相同的行，這使得該操作在重複執行的流程中是安全的。硬換行則因結構上不具備此特性——新的精確欄位切斷點可能落在軟換行會保留完整的字詞中間。
標準換行寬度及其用途
工具內建的預設值——72、80、100、120——是各具名慣例實際使用的寬度。選擇正確的預設值意味著要對應目的地，而非隨意猜測。
| 寬度 | 來源或慣例 | 最適合用於 |
|---|---|---|
| 72 | 廣泛遵循的 Git 提交本文慣例；傳統電子郵件換行。 | 提交訊息、郵件列表回覆、引文式電子郵件本文。 |
| 78 | RFC 5322 對訊息行的「建議」上限。 | 符合標準上限的電子郵件本文。 |
| 80 | 經典終端機寬度；POSIX fold 預設值。 | 程式碼註解、終端機輸出、純文字文件。 |
| 100 | 許多 shell 中的現代終端機預設值。 | README、現代文件、較長的散文。 |
| 120 | 現代寬文件慣例。 | 寬幅文件、設計文件、長篇散文。 |
| 998 | RFC 5322 對訊息行的絕對最大值。 | 邊緣情況——幾乎永遠不是正確選擇。 |
提交訊息 72 欄的習慣記錄於 Pro Git 書的 Contributing to a Project 章節，而 Unix fold 工具 80 欄的預設值則由 The Open Group 加以記錄。如果沒有任何預設值符合目的地，也可以直接輸入 8 到 500 個字元之間的任何寬度。
Indentation, quoting, and overlong words in MS Word paste
Three things tend to break a fixed-width paste inside Word: indented blocks that drift off alignment, quoted-email prefixes that grow on every reply level, and long URLs that force ugly breaks. The formatter handles each of these explicitly.
Indentation is preserved and counted against the width. A paragraph that starts with four spaces keeps those four spaces on every continuation line, and the effective wrap width subtracts them, so indented blocks stay aligned instead of drifting right as the paragraph reflows. Quoted-email prefixes made of angle brackets — > or >> — are treated as indentation under the same rule, so replies keep their quoting structure when they are wrapped.
Overlong words stand alone. Soft wrap never cuts a word. Anything longer than the width — a long URL, an unbroken identifier, a hash with no spaces — stands alone on its own line, and the tool reports how many such words were left intact so nothing silently exceeds your limit. The result distinguishes "no line longer than N" from "no word longer than N," which is the distinction that matters when the destination enforces a strict column.
Hard wrap respects surrogate pairs and emoji. Width is counted in Unicode code points, and the tool never splits a surrogate pair — the two-code-unit sequence that represents an emoji or any other supplementary-plane character. A naive column cutter that counts code units will cut an emoji in half; this one does not. The one scope boundary the tool states plainly: East Asian full-width characters count as one, and terminal double-width rendering is not simulated, so if the destination is a terminal that renders CJK characters as two columns, the visual wrap may differ from the counted wrap.
Inputs are capped at one million characters and the tool wraps in a single linear pass, so even large pastes return instantly. Because everything runs in the browser, drafts stay on the local machine, which matters for confidential email replies, unreleased code comments, and any other text that should not be uploaded to a server for formatting.
For a deeper look, see Capitalize Each Word: From Title Case to camelCase.
For a deeper look, see How to Count Characters in Word and Check Limits Live.