解析查詢參數意味著將 URL 的查詢元件——也就是問號之後的文字，例如 tag=js&tag=api——轉換成接收端程式碼可以使用的結構化資料，同時遵循 WHATWG application/x-www-form-urlencoded 規則來處理百分比跳脫、加號轉空格、以及重複的參數名稱。每一對資料會在第一個等號處切開，百分比跳脫會解碼為字元，加號會變成字面上的空格，而出現超過一次的鍵名則會保留為依序排列的值列表，而不是被靜默覆寫。空值、缺少的等號、以及出現在值內部而非作為分隔符號的保留字元，都是這個契約的一部分，必須在來回轉換過程中不受意外變更地保留下來。Query String Parser 直接在瀏覽器中使用 URLSearchParams 模型實作這些規則，因此任何查詢文字、JSON 或識別碼都不會離開你的機器。了解確切的規則很重要，因為不同的伺服器對重複鍵的處理方式不同——有些保留第一個值，有些保留最後一個值，有些則一律產生陣列——而錯誤的假設會產生一個看似有效但對接收端來說意思不同的負載。
解析查詢參數實際上在做什麼
查詢元件是一連串以 & 號分隔的扁平鍵值對。妥善地解析它需要三個具體行為：只以第一個等號切分、使用 UTF-8 位元組解碼百分比跳脫，以及將字面上的加號視為空格。WHATWG URL 標準在第 6 節為 URLSearchParams 定義了這些規則，而 MDN 也為瀏覽器內建的建構函式記錄了相同的實作方式。遵循這些規則可以讓解析後的值在重新編碼後與來源語意等價，雖然百分比跳脫的拼法以及加號與 %20 的選擇會在序列化時被正規化。
前面的問號不屬於資料的一部分，因此一個行為良好的解析器能夠容許它存在或不存在。同樣地，輸出也應該是一個不帶問號的純查詢元件，因為呼叫端可能需要將它插入到 URL、HTTP 請求主體、日誌測試資料或獨立的單元測試中。消除這種模糊性正是讓結果在不同情境下都能保持可預測的原因。
為什麼專用的解析器比手寫程式碼更好
先用 split("&") 再用 split("=") 的天真作法在簡單情況下能用，但在值包含保留字元、出現空值、缺少等號、以及出現重複鍵時就會失效。常見的失敗模式包括：
- 將加號視為字面字元而非空格
- 在每個等號處都切分，導致包含 = 的值損壞
- 當資料結構實際上需要陣列時，卻丟掉重複鍵後面的出現項目
- 當呼叫端不小心貼上完整 URL 時，把完整 URL 的路徑誤認為是參數名稱的一部分
- 將鍵依字母排序，這會悄悄地改變已簽章 URL 的簽章
專用的解析器透過單一實作來處理這些邊角情況，一致地套用 WHATWG 解碼規則，並回傳一個忠實反映線路格式實際內容的結構——也就是文字，而非猜測的型別。
如何使用 Query String Parser 解析查詢參數
- 在瀏覽器中開啟 Query String Parser，並選擇 query-to-JSON 方向進行解析，或選擇 JSON-to-query 方向進行建構。
- 將來源文字貼到輸入欄位中。解析時，請貼上帶有或不帶前置問號的查詢元件；建構時，請貼上一個扁平 JSON 物件，其值為字串、有限數字、布林值、null，或是這些純量值的陣列。
- 執行轉換。工具會解碼百分比跳脫、將加號視為空格、保留空值，並將重複的參數名稱保留為依序排列的 JSON 陣列。
- 檢查結果中重複的鍵（會以陣列呈現）以及空值（會以空字串呈現），這樣你就能確切知道接收端會看到什麼。
- 在將值往下游送出之前，先複製輸出並針對將會消費它的 API 或端點進行驗證。
轉換規則：重複值、空值與編碼
解析器遵循一組小而明確的規則，使輸出可預測。下表顯示各類輸入的處理方式。
| 輸入 | 行為 | 輸出 |
|---|---|---|
| tag=a&tag=b | 依遇到順序保留重複的名稱 | "tag": ["a", "b"] |
| q=hello+world | 加號解碼為空格 | "q": "hello world" |
| name=John%20Doe | 解碼 UTF-8 百分比跳脫 | "name": "John Doe" |
| flag&ok=1 | 缺少等號視為空值 | "flag": "", "ok": "1" |
| note=a%26b | 已編碼的 & 號保留在值內 | "note": "a&b" |
| ?page=2 | 移除前置問號 | "page": "2" |
這些規則反向也適用。空格會以加號序列化回去，字面上的加號則會被百分比編碼，以免被誤認為空格，而像 & 號和等號這類保留字元當屬於值的一部分而非充當分隔符時，也會被百分比編碼。這裡沒有型別推論：從查詢中解析時，文字 2 仍然是 JSON 字串 "2"，因為線路格式承載的是文字而非數字型別宣告。
從 JSON 建構查詢字串
在 JSON-to-query 方向中，工具接受刻意受限的 JSON 結構：字串、有限 JSON 數字、布林值、null，以及這些純量值的陣列。巢狀物件和巢狀陣列會被拒絕，因為對於在查詢字串中表示巢狀資料並沒有單一標準——方括號記法、點記法、索引記法以及嵌入 JSON 都是相互競爭的慣例，而猜測會產生看似有效但對其他解析器而言意思不同的輸出。
空陣列會被省略，因為它們沒有可以附加的值。null 會變成空值，而 JSON 數字和布林值則變成其文字形式。這會產生一個忠於來源的負載，避免在接收端出現整數 2 悄悄變成字串 "2" 或反之的陷阱。
何時不該重新編碼：已簽章的 URL 和快取鍵
排序、重建或正規化查詢參數可能會破壞已簽章的 URL 和快取鍵。順序、重複出現、百分比跳脫的拼法，以及加號與 %20 的選擇都可能涵蓋在簽章範圍內，因此變更其中任何一項都會讓工具下游的簽章失效。除非簽章協定明確定義了標準化演算法，否則應保留原始的序列化位元組。
凡是 URL 包含根據查詢元件的確切位元組計算出的權杖、雜湊、簽章或 sig 參數時，都適用這項原則。如果協定不明確，安全的做法是不修改地複製查詢文字，並使用協定專用的編碼器——若不存在，則使用 URL Parser 在做任何變更之前檢查現有的元件。
限制、隱私與該驗證的事項
此工具在目前的分頁中將輸入限制為 200,000 個字元，並且完全在瀏覽器中執行，因此任何查詢文字、JSON、權杖、識別碼或 URL 都不會被上傳到伺服器。即便如此，查詢字串經常帶有工作階段識別碼、電子郵件地址、搜尋詞彙和追蹤值，而瀏覽器、歷史記錄、分析工具、代理伺服器、引用來源和伺服器日誌都可以獨立於此工具之外保留這些資料。在分享輸出之前，請先將敏感資料遮罩掉。
此解析器不會驗證完整的 URL、主機名稱、路徑、片段、簽章或授權政策。如果貼上了完整的 URL，其路徑可能會被誤認為是參數名稱的一部分，因此當你需要 URL 層級的驗證時，請先使用 URL 元件解析器。最後，在送出產生的資料之前，請先確認接收應用程式的契約，因為不同框架在處理重複鍵、空值以及保留字元的編碼方式上有所不同。
如需更深入的探討，請參閱如何使用內建的 URL 類別在 Node.js 中解析 URL。
如需更深入的探討，請參閱如何在不破壞資料的情況下將 Excel 中的表格匯出為 CSV。