是的—Query String Parser 可安全地線上用於其支援的轉換工作，因為貼上的查詢文字、JSON、權杖、識別碼與 URL 都不會上傳；轉換及剪貼簿寫入作業都會留在瀏覽器中。

Query String Parser 可雙向轉換 application/x-www-form-urlencoded 查詢資料。這種本機處理範圍適用於檢視及轉換參數，但無法驗證完整 URL、無法保護 URL 中攜帶的密密，也不保證接收該要求的伺服器會以與此工具相同的方式解讀重複參數。

is query string parser safe to use online
Query String Parser 可安全地線上使用嗎？

隱私與處理範圍

線上介面仍可在瀏覽器內執行主要處理，而不必將貼上的內容傳送至遠端伺服器。對此工具而言，轉換及剪貼簿作業都會留在瀏覽器中。貼上的查詢字串、JSON 物件、權杖、識別碼或 URL，不會由轉換工作流程上傳。

然而，本機處理並不會使周邊的 URL 工作流程變得無害。查詢字串經常包含工作階段識別碼、電子郵件地址、搜尋字詞及追蹤值。無論此工具是否參與，瀏覽器、歷史記錄系統、分析服務、Proxy、參照來源與伺服器記錄都可能保留這些值。密碼資料一開始就不應放入 URL 中。

  • 若只是要檢查一般格式，請將可識別的值替換為預留位置。
  • 不要以本機轉換為理由，將密碼、工作階段權杖或私密 API 金鑰放入 URL 中。
  • 在工單、聊天或問題報告中分享轉換後的輸出內容之前，請遮蔽敏感資料。
  • 請記住，輸出內容在複製後，仍須遵循其目的地的處理規則。

支援的格式與排除項目

此解析器刻意支援兩種不同的輸入形式。選擇正確的方向，可避免完整 URL 或巢狀 JSON 結構被依據不支援的規則解讀。

模式接受的輸入輸出與限制
查詢轉 JSON查詢元件，可有或沒有開頭的問號解碼後的 JSON；重複名稱會變成有序陣列，而只出現一次的值則維持字串。
JSON 轉查詢平面 JSON 物件不含開頭問號的編碼查詢元件；不接受巢狀物件及巢狀陣列。

JSON 轉查詢模式接受字串、有限的 JSON 數值、布林值、null，以及包含這些純量值的陣列。空陣列會被省略，因為其中沒有可附加的值。Null 會變成空值，而數值與布林值則變成其文字形式。不接受巢狀物件及巢狀陣列。

這項限制可避免對巢狀資料慣例進行臆測。查詢字串沒有通用的物件語法：括號記法、點分隔名稱、索引名稱與嵌入式 JSON 都是彼此競爭的做法。自動選取其中一種做法的轉換器，可能產生看似有效，但對接收應用程式而言含義不同的輸出內容。

目前分頁的輸入上限為 200,000 個字元。此解析器也不會驗證完整 URL、主機名稱、路徑、片段、簽章或授權政策。如果貼上的是完整 URL，其路徑可能會被誤認為參數名稱的一部分。需要驗證完整 URL 各元件時，請先使用 URL Parser。

安全地轉換查詢元件

當你需要可讀的表示形式，或測試固定資料或 API 要求所需的編碼查詢字串時，請使用下列工作流程。

  1. 選擇轉換方向。 若要檢視收到的查詢資料，請選擇查詢轉 JSON；若已有符合預期表單資料形式的平面物件，則選擇 JSON 轉查詢。
  2. 只貼上適當的輸入並執行轉換。 查詢轉 JSON 時，請貼上查詢元件而非完整 URL；開頭的問號可有可無。JSON 轉查詢時，請貼上平面物件。請將原始來源另外保存，以便與結果比較。
  3. 檢查重複值、空值及編碼值。 確認重複名稱依出現順序顯示為陣列、空值仍清楚可見，且加號、保留字元、Unicode 文字與字串型別皆正確。
  4. 複製結果，並對照接收端 API 進行驗證。 確認重複鍵、空參數、型別轉換及參數順序的預期處理方式。產生的查詢元件不含開頭的問號，因此只有目的地 URL 需要時才加以加入。

值得檢查的解碼行為

此解析器遵循 MDN URLSearchParams 文件及 WHATWG URL 標準所述、相容於瀏覽器的 URLSearchParams 模型。這些規則定義了表單形式的查詢資料如何解碼及序列化；但並未定義每個應用程式的重複鍵政策。

查詢輸入解析結果應驗證的項目
tag=a&tag=b{"tag":["a","b"]}兩次出現的值都會保留，且依出現順序排列。
tag=a{"tag":"a"}只出現一次的值會維持字串，不會變成只有一項的陣列。
q=hello+world{"q":"hello world"}在表單形式的查詢資料中，加號會解碼為空格。
q=a%26b{"q":"a&b"}編碼的 ampersand 會視為值內容，而非分隔符號。
empty={"empty":""}空值仍清楚可見，不會消失。
n=2{"n":"2"}文字會維持字串，因為傳輸格式不包含數值型別宣告。

在相反方向，空格會序列化為加號，而加號字元本身則會進行百分比編碼。當 ampersand、等號等保留字元屬於某個值，而非作為分隔符號時，就會經過編碼。Unicode 文字則會透過 UTF-8 百分比編碼進行轉換。

伺服器行為仍會決定最終結果

將重複名稱保留為陣列很有用，但這並非通用的伺服器慣例。框架可能會保留第一個值、保留最後一個值、一律建立陣列、拆分以逗號分隔的值，或套用特定結構描述的型別轉換。因此，解析器產生的 JSON 會顯示傳輸層上可用的資料，但不保證伺服器最終的記憶體內型別。

此解析器不會進行型別推斷。像 2 這樣的值仍是 JSON 字串 "2"，因為查詢資料包含的是文字，而非型別宣告。如果端點要求數值、布林值、日期或巢狀物件，請確認其結構描述，並在應用程式程式碼中或透過該端點的官方用戶端執行必要的轉換。

簽署的 URL 與快取鍵需要原始位元組

除非通訊協定明確訂定了標準化的參數順序與編碼規則，否則不要使用轉換後的輸出內容重新建立簽署 URL 或快取鍵。重新排序或重新編碼參數，可能會使簽章失效，因為順序、重複出現值、百分比跳脫的拼寫，以及加號與 %20 之間的選擇，都可能包含在簽章涵蓋的範圍內。

如果不熟悉標準化規則，請保留原始序列化位元組。一般用途的轉換器無法取代通訊協定的官方編碼器。如需進一步了解這項差異，請參閱如何在不破壞簽章的情況下解析查詢參數。

線上使用的實用檢查清單

傳送或分享轉換後的資料之前，請完成最後檢查：

  • 確認輸入內容是查詢元件或平面 JSON 物件，而不是完整 URL。
  • 檢查輸入內容是否仍在 200,000 個字元的限制內。
  • 檢視重複鍵、空值、加號、保留字元與 Unicode 輸出內容。
  • 驗證接收端 API 的重複鍵、型別轉換及巢狀資料規則。
  • 為簽署的 URL、快取鍵及其他對順序敏感的資料保留原始位元組。
  • 分享任何輸出內容之前，請移除密密資料及可識別個人身分的值。

在上述範圍內使用，Query String Parser 是一款實用且以瀏覽器為基礎的工具，可轉換及檢查查詢資料，而不必上傳貼上的內容。