工具用的順手嗎?
你的回饋能幫助我們做得更好
將URL字串解析為結構化JSON,快速提取協議、引數、路徑等關鍵資訊。
在左側輸入內容,實時檢視轉換結果
概覽
了解工具能解決的問題、計算或處理邏輯,以及資料邊界。
查詢字串是網址中用來傳遞條件的一段文字,常見形式為 ?q=茶&page=2。本工具提供兩個方向:將查詢參數轉成易讀的 JSON 物件,或把 JSON 欄位轉成 key=value&... 格式。它處理的是參數與值,不會把網址拆成協定、網域、路徑等完整欄位,也不會連線至輸入的網址。
例如將 https://example.com/search?q=%E8%8C%B6&page=2 轉換,可得到 {"q":"茶","page":"2"}。網址中的查詢值轉入 JSON 後都是文字;像頁碼 2 不會自動成為數字。反向轉換則產生參數字串,不含主機、路徑或開頭的問號。
查詢參數的百分比編碼會解碼後顯示。常見的表單式查詢編碼中,+ 代表空格;若值本身是加號,通常需先寫成 %2B。因此 q=hello+world 會讀成 hello world,而 symbol=%2B 會讀成 +。反向輸出時,空格可能以加號表示,中文及其他字元則會編碼。
把參數整理成一般 JSON 物件也有資料模型上的限制:相同名稱只能保留一個值。若輸入 tag=a&tag=b,結果會是 {"tag":"b"},前一個值不會保留。這表示轉換適合閱讀和簡單聯調,不保證能無損還原所有原始查詢字串。
反向轉換建議使用頂層物件,欄位值採文字、數字或布林值等簡單值,例如 {"q":"紅茶","page":2,"available":true}。這些值會序列化成文字參數,例如 page=2 與 available=true。巢狀物件或陣列沒有可依賴的展開格式,不適合期待轉換後仍維持原有結構的情況。
查詢語法允許的字元與應用程式如何解讀參數,是兩件事。工具只負責格式轉換,不知道接收端是否把某個欄位視為頁碼、布林開關或多選條件;使用前仍應核對目標 API 或服務的參數規格。
指南
依步驟完成操作,並透過範例核對輸入與結果。
選「URL → JSON」讀取查詢參數;選「JSON → URL」從物件產生參數字串。切換方向時,若畫面已有轉換結果,該結果會帶入新方向的輸入欄,方便接著檢查。
URL → JSON 可貼上完整網址,或只貼查詢片段,例如 q=%E8%8C%B6+葉&page=2&debug。以此例而言,輸出會把 q 解碼成「茶 葉」、把 page 保留為文字「2」,而沒有等號的 debug 會得到空字串。
結果會隨輸入即時更新。確認欄位名稱、中文解碼、空值與重複欄位的處理符合用途後,使用結果旁的複製操作取得文字。若輸入格式錯誤,先檢查 JSON 是否完整,或參數中的百分比編碼是否有效。
在 JSON → URL 模式輸入扁平物件,例如 {"q":"茶 葉","page":2},結果會是類似 q=%E8%8C%B6+%E8%91%89&page=2 的字串。若要接到網址後方,請自行在基礎網址與結果之間加上 ?。
情境
查看這項工具在不同工作與生活流程中的用法。
開發者可將測試網址的搜尋詞、頁碼或排序條件轉成 JSON,逐欄核對請求參數。比對時記得頁碼等數值仍是文字,以免誤認為工具已做型別驗證。
測試或客服人員可把網址中的條件整理成較易閱讀的物件,附在問題紀錄中,讓協作者看清楚當時使用的參數。分享前應移除令牌、簽章或個人資料。
前後端聯調時,可把簡單 JSON 轉為查詢片段,再依接收端文件接到測試網址。若 API 使用重複鍵、巢狀欄位或特殊陣列慣例,應改用該 API 明確指定的格式。
問答
集中解答常見疑問與容易混淆的問題。
不一定。URL → JSON 也能輸入單獨的查詢參數片段;貼上完整網址時,工具會取問號後的部分作為查詢內容。若網址含有 #fragment,建議先移除片段再轉換,避免片段文字進入最後一個參數值。
URL 查詢參數本身以文字傳遞,因此從參數轉成 JSON 時,值會保留為字串。工具不會根據欄位名稱猜測數字或布林型別。
輸出使用一般 JSON 物件,同名欄位只保留最後讀到的值。若必須保留多個 tag 值,請使用支援多值陣列的解析方式,並依接收端格式處理。
常見查詢參數編碼會把 + 解讀為空格。若實際值是加號,請確認輸入使用百分比編碼 %2B;檢查轉換後的字串時也留意空格可能再次以加號輸出。
不可以。結果只有查詢參數字串,不含網域、路徑或問號。請自行準備正確的基礎網址並依服務規格組合。
須知
使用前了解適用範圍、結果限制與必要提醒。
這項工具只轉換文字格式,不會驗證網域、發送請求、檢查 API 是否接受參數,或判定查詢值的業務意義。
# 及其後內容;否則該段可能被視為末尾查詢值的一部分。推薦
查找相關工具、專題與可用的 API 能力。