為每一行加上引號的線上工具,意思就是把一份純文字清單(一行一個項目)貼到一個瀏覽器工具中,由工具自動為每個項目加上正確的引號字元、以逗號串接,並套用目標格式實際要求的跳脫規則。真正困難的部分不是前後綴,而是字串內部的跳脫。JSON、SQL、CSV 與 JavaScript 樣板字面值各自以不同的方式處理內嵌的引號;一個只會機械式地在每行加上 " 的工具,只要清單中出現撇號、雙引號,或像 O'Brien 這類名稱,就會悄悄地產生錯誤語法。一個遵循已發布規則的引號工具——JSON 用 RFC 8259、CSV 用 RFC 4180、SQL 用 PostgreSQL 與 SQL 標準所採用的單引號加倍規則——可以把一則充滿 ID 的聊天訊息轉成可直接貼上的陣列、IN 子句或 CSV 資料列,既不會出現語法錯誤,也不必逐行手動編輯。

大多數搜尋「add quotes to each line online」的使用者,都已經試過以下三種快速方法之一:編輯器中的 regex 尋找取代、 spreadsheet 中的公式,或通用的前後綴工具。這三種方法都能幫每行加上引號;但當輸入內容含有目標格式會特別處理的字元時,它們救不了你。專門的引號工具價值在於每個預設內建的規則,而非只是加上引號這個動作本身。

add quotes to each line online
add quotes to each line online

為什麼替清單加上引號看似簡單,卻會在遇到撇號時踢到鐵板

一份包含 50 個產品 ID 的清單看起來像是 30 秒就能搞定的小事。只要任何一行出現引號字元,這件小事立刻變成一場除錯作業。如果你的目標是 JSON 陣列,像 5" monitor 這樣的一行,不能只是被包進 "...";它必須變成 "5\" monitor",否則 JSON parser 會在內嵌的引號處停止讀取。如果你的目標是一段 SQL WHERE id IN (...) 子句,同樣這一行需要用單引號包住,而內嵌的雙引號則保持原樣——'5" monitor'——因為 PostgreSQL 所記錄的 SQL 字串常值語法,採用的是加倍內嵌單引號,而非反斜線跳脫。如果你的目標是 CSV 資料列,該欄位必須用雙引號包住,並依據 RFC 4180 把內嵌的引號加倍。

這種三方差異正是手寫的前後綴方法會出錯的地方。它無法判斷輸入中的單引號應該被加倍(SQL)、保持原樣(JSON 字串內部),還是用反斜線跳脫(JavaScript 樣板字面值)。輸出結果表面上確實被加上引號,語意上卻是壞的,而且這個 bug 在 parser 拒絕讀取檔案、或查詢因為值在第一個內嵌引號處被截斷而傳回零筆資料之前是看不見的。

各種格式如何處理內嵌引號

跳脫規則因格式而異,是因為語法本身就因格式而異。JSON 由 RFC 8259 規範,該文件規定了雙引號字串內雙引號的反斜線跳脫方式。SQL 字串常值,依 PostgreSQL 文件記載並被 ISO 標準與 SQLite 採用,則是將單引號加倍。CSV 由 RFC 4180 定義,每個欄位都以雙引號包住,內嵌的雙引號則加倍。下表整理了 Add Quotes to Each Line 中各預設所套用的規則。

預設包覆字元內嵌引號規則引用標準
JSON 陣列"(雙引號)" 變成 \" ; \ 變成 \\RFC 8259
SQL IN 子句'(單引號)' 變成 ''(不使用反斜線)PostgreSQL / ISO SQL
CSV 資料列"(雙引號)" 變成 ""(不使用反斜線)RFC 4180
反引號 / JS 樣板`(反引號)` 變成 \` ; ${ 變成 \${ECMAScript 樣板字面值

同一份輸入在每個預設下會產生明顯不同、但在語法上正確的輸出。she said "hi" 這一行,為 JSON 包覆後變成 "she said \"hi\"";為 CSV 包覆後變成 "she said ""hi""";為 SQL 包覆後變成 'she said "hi"',雙引號原封不動,因為包覆用的是單引號,而輸入中並沒有單引號。把輸入跑過錯誤的預設,不僅是看起來不對,而是根本無法解析。

如何透過三個步驟在線上為每一行加上引號

  1. 把清單貼進輸入區,一行一個項目。純文字加上換行就足夠——除非你想,否則不必預先清理 tab 或尾端空白。
  2. 點選你所需格式的預設:JSON 陣列、SQL IN 子句、CSV 資料列,或單純引號。預設會挑選該格式的包覆字元、分隔符號與跳脫規則。
  3. 如有需要再做微調——引號樣式、分隔符號、跳脫開關、是否跳過空白行、是否逐行修剪——然後複製即可貼上的結果。

輸出會回報處理了多少行。最多一百萬字元的輸入會在單一線性階段中處理,因此即使是長清單也能即時回傳。所有運算都在你的瀏覽器中執行:輸入從未離開這個分頁,不會上傳到伺服器,不會被儲存,也不綁定任何帳號。當清單含有不該傳給來路不明服務的識別碼、客戶名稱或內部 ID 時,這一點格外重要。

選擇正確的預設

這四個預設涵蓋了你真正需要引號工具、而非通用前後綴工具的情境。

  • JSON 陣列——當目的地是 JavaScript 或 Python 字面值、fixture 檔、config map 值,或任何遵循 RFC 8259 解析的消費者時使用。輸出會用雙引號包覆每一行,並在外層加上 [ ]。
  • SQL IN 子句——用於對 PostgreSQL、SQLite 或任何遵循 ISO 字串常值規則的引擎下 WHERE col IN (...) 查詢。輸出會用單引號包覆每一行,把內嵌的撇號加倍,並在外層加上 ( )。
  • CSV 資料列——用於 spreadsheet 匯入、資料管線輸出,或任何遵循 RFC 4180 的消費者。輸出會將每個欄位用雙引號包住,並把整列輸出成一行,可直接放入 CSV 欄位。
  • 反引號 / 純引號——用於 JavaScript 樣板字面值,或任何需要不同包覆字元的場合。反引號預設會跳脫內嵌的反引號與 ${ 插值起頭字元,使貼上的內容無法植入運算式。

當目的地是自訂格式——例如,使用自有引號風格的設定檔——從最接近目標的預設開始,再調整引號樣式與分隔符號控制項以符合需求。

預設之外實用的控制項

預設所編碼的所有規則,也都以獨立控制項的形式開放出來;當目的地不常見,或清單在引號化前需要清理時,這格外有用。

  • 引號樣式——挑選包覆字元,或選擇「無」以得到裸式的逗號分隔清單。同一份輸入可以從一次點選切換到另一次,變成 a,b,c、"a","b","c"、'a','b','c',或 `a`,`b`,`c`。
  • 尾端分隔符號——預設為關閉,因為在多數 parser 中,帶有尾端逗號的 JSON 陣列或 SQL IN 清單會造成語法錯誤。當目標格式預期要有尾端逗號時再打開。
  • 跳脫——開或關。當行內保證不含引號字元、且你希望得到原始包覆,或當你引號化的清單將被嵌入另一個已加引號的環境中時,可關閉此選項。
  • 跳過空白行——在引號化前先丟掉空行,如此貼上時多餘的空白行才不會變成陣列中的空字串元素。
  • 逐行修剪——去除每行首尾的空白,如此來源的意外縮排才不會滲入輸出。

有一個行為是明文記錄、不會隱藏的:對工具自身的輸出再執行一次,行會被再包覆一次。引號工具無法判斷輸入中的引號究竟是內容還是包覆,重新執行時會刻意地雙重包覆。如果你需要不同的設定,請從原始清單重新開始。

搭配一個快速清理步驟

需要加引號的清單,往往在加引號前就需要先清理——移除重複、刪除空行、去掉多餘空白。duplicate-line remover 也同樣能處理一百萬字元的輸入,因此典型的工作流程就是先清理,再加引號。如果你的清單來自同事的聊天訊息,預期會夾雜多餘的重複與結尾的空白行;在引號化前先跑一次去重,不僅輸出更精簡,也能避免把同一個 ID 兩次傳進 SQL 查詢。

如果清單需要的是圍繞每行的任意文字,而不是格式感知式引號——例如每行前加上註解、項目符號字元、檔案路徑前綴——網站上另一個 Add Prefix and Suffix to Lines 工具會更合適。該工具不做任何跳脫,把每一行視為不透明文字,這正是當包覆只是裝飾而非語法時你所需要的。

對於更廣泛的清單塑形任務——隨機化、排序、與另一份清單比對、移除重複——同樣適用「在瀏覽器內、不上傳」的原則。引號化通常是整個流程中的最後一步:在清單已被塑形成你需要的樣子之後,在它被貼進真正在意正確跳脫的目的地之前。

如果你正在權衡各種做法,How to Delete Empty Lines From Excel Cleanly 對此有詳細說明。