一款基於瀏覽器的前綴工具，能在單一本地端流程中為最多一百萬字符的輸入文字加上字面的前綴與後綴字串，並產生一個可下載的 UTF-8 TXT 檔案，整個過程不會將任何資料傳送到伺服器。任何在尋找「API 替代方案」來為每行加上前綴的人，通常心裡有兩個想法：他們嘗試過或考慮過用腳本來執行這個轉換（sed、awk、Python、Node.js 腳本，或一個代管的文字處理 API），並想要一條更快的路徑；或者他們希望得到可預期、字面的輸出，讓像括號、美元符號、反斜線這類字元在結果中能與輸入完全一致。為每行加上前綴與後綴正是能在瀏覽器中同時滿足這兩種需求的工具。你貼上你的每一行，輸入前綴與後綴字串，頁面就會為每一個邏輯行串接出「前綴 + 原始行 + 後綴」，並把結果中的 CRLF、CR 與 LF 統一標準化為 LF。一切都在目前的分頁中執行，文字從不上傳，下載的檔案是一個本地端的 UTF-8 Blob。

add prefix to each line api alternative
add prefix to each line api alternative

為什麼要尋找 API 的替代方案

大多數「為每行加上前綴」的教學文章，都預設你已經開啟了一個終端機。經典的做法包括：用 sed 進行就地編輯、用 awk 進行有條件的裝飾，或是寫一支簡短的 Python 腳本來逐行迴圈並串接字串。這些方法都能用，但每一個也都帶有各自的假設：一個可用的 shell、一個特定的執行環境、上傳檔案的方式——或者以代管 API 來說，則需要一組帳號、一把金鑰，以及每月的額度配額。對於一次性處理一份識別碼、提示詞、SQL 片段或 shell 註解的工作，這些前置成本往往不值得。

代管的文字處理 API 會把情況再推得更遠。它們接收一個請求本文、回傳裝飾後的文字，通常以 MB 或以請求次數計費。第二個問題是隱私：把一份內部識別碼清單、客戶電子郵件或尚未公開的日誌行送到第三方端點，可能就違反了你最基本的資料處理政策。一款在目前分頁中完成同樣工作的瀏覽器工具，則能一次避開執行環境、金鑰、配額與網路往返。

現今以 API 為基礎的前綴工作流程長什麼樣子

如果你之前已經寫過腳本處理這件事，你大概寫過類似下列其中之一的程式：

  • 一個使用 sed 或 awk 的 shell 一行指令，為每一筆紀錄加上字面字串。
  • 一支 Python 或 Node.js 腳本，讀取檔案、以換行符切割，並串接出「前綴 + 行 + 後綴」。
  • 對一個代管的文字處理端點發出請求，將輸入以 JSON 傳遞並解析回應。
  • 一個自訂的內部微服務，擁有自己的路由、身分驗證與速率限制。

這些模式都有相同的輪廓：載入文字、切成一行行、進行裝飾、重新合併、回傳。差別在於由誰擁有執行環境、文字在傳輸過程中位於何處，以及結果依賴多少個活動部件。一款在用戶端以 JavaScript 執行相同演算法的瀏覽器工具，則能把依賴鏈縮短到只剩一個分頁。

呼叫 API 的瀏覽器替代方案

「為每行加上前綴與後綴」是這個概念最簡化的版本：把行貼進文字框、輸入前綴與後綴、按一下即可產生。頁面會根據文件記載的限制來驗證輸入、在 CRLF、CR 或 LF 的邊界上切割文字、依據空白行設定逐行決定是否套用詞綴、串接結果，並在一個保留空白與換行的預覽區中顯示完全一致的輸出字串。下載檔案是以本地端的 UTF-8 Blob 建立，因此檔案內容就只是純文字——不含位元組順序標記、不含任何樣式、不含試算表引號、不含 CSV 跳脫、也不會依檔名做任何裝飾。

對於最多一百萬字符的一次性裝飾工作，從貼上到下載的往返時間，通常比安裝一套函式庫、寫一支請求處理程式，或註冊一把代管 API 金鑰還要短。轉換會在輸入通過驗證的瞬間執行，結果在預覽中可逐字檢查，再決定是否下載。

如何在瀏覽器中為每行加上前綴

最短的路徑包含六個明確步驟。每一步都是一項字面操作——沒有腳本、沒有環境設定、也沒有 API 呼叫。

  1. 在新分頁中開啟「為每行加上前綴與後綴」。
  2. 把你想要裝飾的行貼上或輸入到輸入區。最多接受一百萬字符。
  3. 輸入前綴、後綴，或兩者都輸入。兩者各自獨立限制為 200 個 Unicode 字元，且至少其中之一必須包含文字——空的前綴與空的後綴只會原樣回傳輸入。
  4. 選擇是否讓僅含空白的行保持不變。當此選項啟用時，空白行或僅含空格、Tab 等空白的行會原樣通過；當此選項停用時，每一個邏輯行——包括空白與僅含空白的行——都會被加上詞綴。
  5. 產生結果並檢查預覽。預覽使用一個保留空白與換行、但允許視覺上長行換行的預先格式化區域，因此畫面上的換行不會在實際下載檔案中插入真正的換行符。
  6. 使用頁面產生的本地端 Blob 下載 UTF-8 TXT 檔案；如果你只需要把結果貼到別處，也可以直接複製預覽內容。

在產生結果之後若編輯輸入、前綴、後綴或空白行設定，會清除舊的結果並撤銷其下載 URL，因此你絕不會拿到一份下載檔案，但其控制項所描述的卻是另一組輸出。

字面文字代表可預期的輸出

前綴與後綴會以字面字串插入。像括號、引號、美元符號、反斜線、星號與括弧這類字元在輸出中會與輸入完全一致——它們不會被當作正規表示式、取代符號、Markdown、HTML 或程式碼來解讀。這是刻意的設計，也是為什麼任何一行的改動，無論周圍字元長什麼樣，都能每次都產生相同結果。

常見的應用情境包括：

  • 列表標記：在每一行開頭加上 - 或 * 。
  • 在識別碼外加上引號或分隔符號："、'、(、)、[、]。
  • SQL 片段：把 SELECT ' 當作前綴、' 當作後綴，產生一個 IN 子句。
  • 日誌標籤：在每一行開頭加上 [INFO] 或日期戳記。
  • Shell 註解：在設定檔片段中每一行開頭加上 # 。
  • 縮排：在每一行開頭加上兩個或四個空格，或一個 Tab 字元。

這個工具不會裁切行的開頭或結尾、不會合併內部空白、不會改變大小寫、不會移除 Tab、不會排序項目，也不會去除重複值。它只會為符合空白行原則的每一行，串接出「前綴 + 原始行 + 後綴」。如果你還需要上述其他轉換，那屬於另一個工具的工作範圍。

空白行、行尾換行與換行字元

有三個行為值得事先了解，因為它們往往決定了輸出是否能與你管線中的其他環節吻合。

一個行尾換行會產生一個最終的空白邏輯行。當「保留空白行不變」啟用時，那個最終空白行會維持空白；當該選項停用時，它會被加上前綴與後綴——這在下游解析器預期每一筆紀錄都要被裝飾、但你又不想刪掉最終邊界時很好用。這個選擇會改變覆蓋範圍，但不會刪除任何一行。

換行字元會被標準化。工具能辨識 Windows 的 CRLF、傳統 Mac 的 CR 與 Unix 的 LF，並在輸出中統一為 LF，因此你從 Notepad 貼上的檔案，下載後會得到一份換行一致的新檔案。如果你的下游工具特別需要 CRLF，請另外再對下載下來的檔案做一次轉換。

空白的輸入與超過一百萬字符上限的輸入，會顯示明確的錯誤，而不是悄悄截斷或只處理部分資料。這個上限讓瀏覽器在大型轉換過程中仍能保持穩定的記憶體用量與操作反應速度。

空白行設定空白行的結果僅含空白之行的結果最終空白行的結果
保留空白行不變（開啟）維持空白維持輸入原樣，保留所有空格維持空白
保留空白行不變（關閉）加上前綴與後綴加上前綴與後綴加上前綴與後綴

限制、錯誤與這個工具不做的事

文件記載的限制很簡短，貼上之前值得先讀過一次：

  • 輸入大小：最多 1,000,000 個貼上或輸入的字元。
  • 前綴與後綴長度：各自最多 200 個 Unicode 字元。
  • 詞綴需求：前綴與後綴中至少必須有一個不為空；否則結果只是輸入的拷貝，且下載動作會被略過。
  • 輸出格式：一個 UTF-8 TXT 檔案，不含位元組順序標記，由本地端 Blob 產生。

這個工具刻意不做的事：它不會在行內尋找並取代文字、不會加上連續編號、不會解析 CSV 欄位、不會編輯 Word 文件、不會推斷語法、也不會解讀 Markdown 或 HTML。若需要編號前綴，請使用專門的逐行編號工具；若需要子字串變更，請使用字面尋找與取代工具。這份狹窄的合約正是讓轉換結果可以預期的關鍵。

由於整個操作是在瀏覽器中使用 JavaScript 字串執行，表情符號與非拉丁文字會原樣通過而不被修改，最終 Blob 會標示為 UTF-8 純文字。字素在畫面上實際呈現的樣貌仍取決於使用者的字型與下游編輯器，但位元組序列就是該字串實際產生的內容。

若想了解下載檔案是如何建立的，MDN 上的 Blob 參考文件說明了用來在本地端建構 TXT 檔案的底層物件。

如果你正在權衡選項，為文字檔的每一行批次加上前綴對此有詳細說明。

如果你正在權衡選項，為程式碼與資料的每一行加上引號對此有詳細說明。