在 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 wrap」，也是人們在詢問如何讓每一行都精確停在特定字元數時所指的意思。
Word 內建的自動換行是視覺化且動態的：同一段落在狹窄的窗口中可能排成 60 字元，在寬闊的窗口中則排成 95 字元。對於無論在哪裡都必須呈現相同樣貌的文件——以純文字記錄檔封存的提交訊息、帶有引述前綴的郵件列表回覆、原始檔案中的程式碼註解——這種視覺化的換行是錯誤的工具。您需要的是能產生硬式、可預測行尾的換行，而這正是固定寬度換行所提供的。
為什麼固定寬度換行在 Word 文件中仍然重要
有幾項純文字慣例仍然要求每一行保持在特定欄寬之內，而 Word 文件往往是這些文字在被電子郵件寄出、封存或貼入程式碼審查之前，所停留的最後一個地方。
- 電子郵件本文。網際網路訊息格式標準規定訊息的每一行不應超過 78 個字元，而將本文文字以 72 字元換行，可為日後加入引述層級預留空間，而無需重新換行。
- 郵件列表回覆。每一層引述都會在每一行前面加上至少一個字元，因此原始訊息必須從一開始就夠短，才能容納這些前綴。
- Git 提交訊息。廣為遵循的 Git 慣例將提交本文文字以 72 欄進行換行，使訊息在 git log、程式碼審查工具及終端機用戶端中以縮排顯示時仍能保持完整。
- 程式碼註解與原始檔案。經典的 80 欄終端機寬度仍被許多程式碼風格指南所引用，超過此寬度的註解會在那些以正好 80 欄來顯示的編輯器中斷行。
- Man 手冊、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.