直書是指字元以由上到下的方式排列成直行，而不是由左到右排列成橫列，而直書產生器會產生該版面配置的可攜帶純文字版本，將多達 5,000 個 Unicode grapheme cluster 重新排列成有邊界的直行，讓你可以貼到任何聊天視窗、簡介、字幕或文件中。你貼上原始文字，從 1 到 100 中選擇一個整數的直行高度，並挑選邏輯直行是由左到右還是由右到左顯示；接著工具會回報原始 grapheme 數量和輸出直行數，向你顯示完全等寬的預覽，並讓你將結果下載為 UTF-8 TXT 檔案。由於輸出是由一般字元和兩個空格分隔符所組成的純文字，因此它可以在 Unicode 通行之處流通——終端機、程式碼區塊、訊息應用程式、社群個人檔案、課堂講義和電子郵件簽名檔——而不需要依賴 CSS、字型或渲染引擎。從分段到建立下載檔案的每一步都在你的瀏覽器中執行，所以在你決定儲存之前，原始文字絕不會送到伺服器。
純文字檔案中的直書代表什麼
純文字沒有旋轉、直行或書寫方向的概念。每個字元都是一串程式碼點，目的地會以自己的字型來呈現，而支援 Unicode 的應用程式可以自由地以任何方式顯示字串。因此，純文字中的直書無法依賴真正的印刷旋轉；它只能重新排列字元序列，讓文字在由上到下、再一一直行接著讀時，仍保留原本的閱讀順序。這正是直書產生器所依據的合約。它不會輸出 CSS、影像或文件；它輸出一個等寬的字元區塊，直行之間以兩個一般空格分隔，每一行的結尾使用 LF 行分隔符。讀者會看到你的原始文字從第一直行由上往下讀，接著是第二直行，依此類推，完全就像印刷的直書書籍中閱讀的方式。
這種純文字的做法有工具明確告知的取捨。由於每一直行與下一行之間相隔兩個空格，對齊效果取決於目的地字型是否一致地處理這些空格和所選的字元。比例字型、寬度混合的文字、備援的 emoji 字型和定位字元都可能讓直行看起來不均勻，即使底層的儲存格序列是正確的。輸出在嚴格的意義上是可攜帶的：它是一段可以複製貼上的字串，而不是有樣式的版面配置。這種可攜帶性同時也是它的優勢，因為結果在 CSS writing-mode 不可用、不支援或視覺上錯誤的地方依然可以運作——例如在聊天泡泡、簡短簡介或禁止 HTML 的程式碼區塊中。
使用工具產生直書
若要將你的原始文字轉換成直行，請依照工具強制執行的相同三步驟流程進行。
- 將你想重新排列的文字貼上或輸入到輸入區域，然後從 1 到 100 之間選擇一個直行高度。高度是指從上到下填滿每一直行的 grapheme 數量，之後才會開始下一行。
- 挑選直行方向。由左到右會將第一個原始直行顯示在視覺左側，符合大多數讀者橫向掃讀的方式。由右到左會反轉直行順序，讓第一個原始直行出現在視覺右側，這是日文、蒙古文以及部分雙語標示傳統上使用的方向。
- 產生版面配置。工具會回報原始 grapheme 數量和輸出直行數，在預覽中顯示完全等寬的結果，並讓你下載內容與你看到的字串完全一致的 UTF-8 TXT 檔案。下載使用的是一個短暫存在的 Blob URL，並會立即撤銷；對原始文字、高度或方向的任何變更都會清除先前的結果，這樣舊的版面配置就不會與目前的設定混淆。
如果你選擇的高度會產生超過 50 行，工具會拒絕產生，並要求使用更高的直行，而不會產生難以閱讀的預覽。空白輸入、小數或超出範圍的高度、無效的方向、超過 5,000 個 grapheme，或超過 50 個輸出直行，各自會產生明確的錯誤，而不是產生部分結果。格式錯誤的 UTF-16 surrogate 序列在分段之前也會被拒絕，且工具絕不會靜默地截斷你的原始文字。你可以在瀏覽器中開啟 直書產生器，無需任何帳號或上傳即可依照這三個步驟操作。
換行、Emoji 和組合記號的處理方式
grapheme cluster 是人眼視為一個字元的單位，即使底層的 Unicode 是多個程式碼點。工具會以 Unicode grapheme 的細粒度，透過瀏覽器的 Intl.Segmenter 對你的輸入進行分段，並在網站上記錄了經過測試的備援方案，這表示常見的 emoji 序列（例如 👨👩👧👦、👩🏽💻 和 🇯🇵）會保持為單一儲存格，而不是被拆分成原始的程式碼單位。膚色修飾符、區域指示符號旗幟、keycap 基礎、變體選擇器和組合附加記號，都會與其所屬的基礎 grapheme 保持連結。組合記號（例如 é 上的尖音符（e + ́））會保持配對，而不會散落到相鄰的儲存格中。底層的分段是由 Unicode 文字分段標準 UAX #29 所定義，並透過 JavaScript 中的 Intl.Segmenter 來公開，相關說明記載於 MDN。
現有的換行會套用一條明確且可見的規則。每個被辨識出來的 CRLF、單獨 CR 或 LF 邊界，在直書序列中都會變成一個全形空白儲存格。連續的行尾會產生連續的空白儲存格。這些空白儲存格不會啟動新的獨立直書區塊——它們仍然屬於同一個矩形版面的一部分，這樣可以在序列中保留可見的間隙，同時維持一個可預測的矩形。如果較短的直行需要內部填補以保持後續直行對齊，該填補會以全形空白儲存格呈現；如果缺少的儲存格位於視覺右側邊緣，則會省略，以避免輸出行增加不必要的尾端填補。這條規則就是為什麼段落分隔在直書重新排列後會以明顯的間隙保留，而不會塌縮到周圍的儲存格中。
選擇直行高度和方向
高度是最關鍵的決定，因為它設定了你的文字所要符合的矩形。試想輸入「HELLO」——五個 grapheme（H、E、L、L、O）——並選擇高度 3。第一直行從上到下填入 H、E、L；第二直行接收 L 和 O。因為五個 grapheme 放入三格直行需要進位到兩行，而第二直行是最右邊的那一行，所以該行底部缺少的一格會被省略。預覽會顯示為：
H L E O L其背後的算術很簡單：原始 grapheme 數除以直行高度，進位到整數直行數。同樣的五個 grapheme 搭配高度 5 會產生剛好一直行（⌈5 ÷ 5⌉ = 1），而同樣的五個 grapheme 搭配高度 2 則會產生三直行（⌈5 ÷ 2⌉ = 3）。
如果將方向切換為由右到左，輸入和高度相同的情況下，第一個原始直行（H、E、L）會移到視覺右側，第二個原始直行（L、O）則會移到視覺左側：
L H O E L較高的高度會產生較窄的預覽和較長的整體輸出。較低的高度會產生較寬的預覽，每行有更多儲存格，且視覺上有更多直行。同樣的 25 個 grapheme 搭配高度 10 會剛好排成 3 直行；同樣的 25 個 grapheme 搭配高度 3 則需要 9 直行，而這正是 50 行上限發揮作用的地方。方向的選擇大多取決於視覺：當你想要原始字元從左上往下讀時選擇由左到右，當你想要原始字元從右上往下讀時選擇由右到左，這是讀者聯想到傳統日文直書書籍和部分雙語標示的方向。
適合純文字做法的使用情境
直書產生器是為可攜帶的純文字排列而設計的，而非用於完整的排版。下表將常見的情境對應到合適的工具選擇。
| 情境 | 最佳選擇 | 原因 |
|---|---|---|
| 聊天或簡介中的裝飾性字幕 | 直書產生器 | 單一可複製貼上的字串，無需 CSS，無需上傳。 |
| 簡短的雙語標籤（英文 + 日文並排） | 直書產生器 | 純文字讓兩種文字皆可閱讀，無需處理字型。 |
| Unicode grapheme 的課堂範例 | 直書產生器 | 儲存格順序可預測，每次工作階段結果一致。 |
| 保持可選取的網站主視覺文字 | CSS writing-mode | 具響應式設計、親和力，不會插入空格。 |
| 帶有旋轉標點符號的印刷海報 | 設計應用程式 | 完整掌控字形度量和頁面幾何。 |
| tate-chu-yoko、ruby 注音或雙向塑形 | CSS + 語言排版 | 純文字無法表示這些版面配置。 |
將此產生器用於詩詞實驗、直書標籤、簡短的雙語展示、課堂範例、社群貼文和純文字模擬。對於像 Instagram 限時動態這樣的特定目的地，同樣的純文字輸出可以直接放進字幕欄位；該工作流程請參閱 如何在 Instagram 限時動態上取得直書。對於真正的網站，CSS writing-mode 和適當的語言排版通常能提供更具親和力的直書版面，因為文字能保持響應式、親和力，並且無需插入空格即可選取。
何時 CSS writing-mode 是更合適的選擇
當你需要真正的網站版面配置時，CSS writing-mode 就是正確的答案。它指示瀏覽器以垂直方式排列字元，支援 CJK 語言排版，在各種螢幕尺寸下仍具響應式設計，對螢幕閱讀器保持親和力，並且不依賴可能破壞選取功能的插入空格。純文字的做法並非 writing-mode 的替代方案；它是在 CSS 不可用、不支援或視覺上錯誤之處的可攜帶備援方案。
此產生器明確說明了它不是什麼。它不是用於日文 tate-chu-yoko（直書中的短橫排）、旋轉標點符號、ruby 注音、中文換行、蒙古文字型配置、雙向塑形或印刷出版的排版引擎。對於這些需求，InDesign 或 Illustrator 等設計應用程式，或適當的語言排版，才是合適的工具。直書產生器適用於可攜帶的情境：可在聊天應用程式、簡介、程式碼區塊、終端機、課堂講義以及 CSS 無法觸及的純文字模擬之間流通的可複製貼上字串。
Limits, Errors, and Predictable Output
Three hard ceilings bound what the tool can do: 5,000 grapheme clusters of input, 50 columns of output, and 100 rows of height. Exceeding any of them produces an explicit error rather than a partial result, so the preview you see is always complete.
The cell order is deterministic given the same browser segmentation behavior, source text, height, and direction. No language mapping, dictionary, font service, remote model, or external content database is used. Segmentation, layout, previewing, and download creation all happen locally in your browser. The downloaded file exactly matches the preview string, uses LF row separators, and is created through a Blob URL that exists only for the click that triggers it.
Two practical reminders. First, changing any of the source text, height, or direction clears the prior result so an old layout cannot be confused with current settings. Second, always preview the result in the final destination font before publishing, because a visible glyph can render differently across fonts and systems, and a proportional font can make columns look uneven even when the underlying cell sequence is correct.
For a deeper look, see How to Text in Wingdings: A Copy-Paste Workflow.