為什麼預設是 72 與 80？

RFC 5322 建議訊息行維持在 78 個字元以內，而 72 會替引用前綴保留空間；80 是經典終端寬度，許多程式風格指南仍引用。兩者都是真實文件記載的慣例，且任何 8 至 500 的寬度都可用。

比限制更長的字詞會怎樣？

軟換行不會切開字詞：超長字詞會完整獨佔一行，結果會報告其數量。硬換行會在精確欄位切開，但不會在 emoji 或其他雙 code-unit 字元的中間切開。

已經換行的文字可以重新換行嗎？

可以。重整段落會在換行前合併每個段落內的既有行尾，讓舊的 60 欄文字能乾淨地改為 100 欄。既有行尾必須保留時，請關閉重整段落。

文字換行／行長格式化工具

使用方式

1.貼上文字並選擇寬度：電子郵件與 commit 訊息可用 72，經典終端可用 80，或自行輸入數值。
2.選擇在字詞邊界軟換行或在精確欄位硬換行，並設定重整段落與縮排處理。
3.檢查最長行統計後，複製換行結果。

關於文字換行／行長格式化工具

文字換行工具會將文字整理為指定的最大行長，這是編輯器、郵件用戶端和終端從固定寬度螢幕時代一路沿用的做法，也是許多純文字慣例至今仍要求的形式。貼上文字、選擇寬度後，會取得在合適位置斷行的相同內容：軟換行在最後一個放得下的空白處斷行；若確實要求每行不得超出限制，可開啟硬換行，在精確欄位切開。

預設寬度都對應實際慣例。網際網路訊息格式 RFC 5322 規定每行不得超過 998 個字元，且最好不超過 78；傳統的 72 欄內文換行會為引用層級預留空間，也延續到 Git commit 訊息，讓內文能在日誌的縮排顯示中維持可讀。80 欄則是許多程式風格指南仍會提及的經典終端寬度。72、80、100、120 四個預設可一鍵套用，也能輸入 8 至 500 之間的任意整數。

換行會保留結構。空白行不會刪除，每個段落獨立換行。預設開啟的重整段落會先合併同一段落內的既有行尾，因此已依舊寬度換行的文字可以乾淨地改用新寬度；關閉後則逐行處理，適合原本行尾有意義的內容。縮排會保留並納入寬度：以四個空格開頭的段落，每一個延續行都會保留四個空格，實際可用寬度也會扣除它們，避免對齊漂移。由角括號組成的電子郵件引用前綴也按相同規則視為縮排。

軟換行絕不切開字詞。任何長於限制的內容，例如長 URL 或沒有空白的識別字，會完整獨佔一行，結果會報告保留了多少這類超長字詞，避免你不知情地超過限制。硬換行會在精確欄位切開，但不會把 emoji 或其他占兩個 UTF-16 code unit 的字元切成兩半。寬度按 Unicode code point 計算；頁面明確說明一項邊界：東亞全形字元仍計為 1，不模擬終端的雙倍寬度。

同一寬度下的軟換行具有冪等性，再次處理輸出不會改變內容，適合重複工作流程。結果會列出輸入行數、輸出行數和最長輸出行。輸入上限為一百萬字元，演算法單次線性處理，即使接近上限也能快速完成。所有內容在瀏覽器中處理，不會上傳、儲存或連結到帳戶；適合 commit 訊息、郵件清單回覆、程式註解、man-page 風格文件與任何要求誠實固定行長的目的地。

方法與來源

以空白行切分段落，可選擇重整段落內的既有行尾，再以單次處理在最後一個可容納的空白或硬換行的精確欄位斷行；保留並扣除縮排寬度，不切開代理對，寬度以 Unicode code point 計算，並如實揭露 East Asian width 未模擬的邊界。

常見問題

為什麼預設是 72 與 80？: RFC 5322 建議訊息行維持在 78 個字元以內，而 72 會替引用前綴保留空間；80 是經典終端寬度，許多程式風格指南仍引用。兩者都是真實文件記載的慣例，且任何 8 至 500 的寬度都可用。
比限制更長的字詞會怎樣？: 軟換行不會切開字詞：超長字詞會完整獨佔一行，結果會報告其數量。硬換行會在精確欄位切開，但不會在 emoji 或其他雙 code-unit 字元的中間切開。
已經換行的文字可以重新換行嗎？: 可以。重整段落會在換行前合併每個段落內的既有行尾，讓舊的 60 欄文字能乾淨地改為 100 欄。既有行尾必須保留時，請關閉重整段落。

文字工具使用指南

查看全部

使用方式

關於文字換行／行長格式化工具

方法與來源

常見問題

相關工具

文字工具 使用指南

文字工具使用指南