cURL指令建構器

curl指令建構器能將繁瑣且包含多個旗標的指令轉化為引導式表單。您只需選擇 HTTP 方法、貼上 URL、按行輸入標頭和查詢參數、設定請求主體並選擇認證模式 — 本工具就會為您寫出對應的 curl 指令。終端機風格的預覽畫面會隨著您的輸入即時更新，讓您在複製指令前即可看清其完整結構。

此工具完全在瀏覽器中執行。它不會呼叫您輸入的 URL，也不會儲存您的標頭、權杖或主體內容。您將獲得一個可以直接執行的指令，並可將其貼到終端機、CI 步驟、Makefile、Postman 匯入檔案或錯誤報告中。

為什麼視覺化建構器優於手寫 cURL

如何使用 curl指令建構器

1. 選擇方法：GET 用於讀取、POST 用於建立、PUT/PATCH 用於更新、DELETE 用於刪除、HEAD 僅獲取標頭，而 OPTIONS 則是向伺服器查詢資源支援哪些方法。
2. 輸入 URL：最好輸入完整的 URL，例如 https://api.example.com/v1/users。如果省略協定，建構器會自動將其標準化為 https://。
3. 列出查詢參數：每行一個，格式為 key=value。對於旗標風格的參數，可將值留空。建構器會在 ? 後方自動附加這些參數。
4. 列出標頭：每行一個，格式為 Header-Name: value。建構器會自動去重，且在您未手動設置的前提下，會為 JSON、表單和 XML 主體自動新增對應的 Content-Type。
5. 選擇主體類型：選擇 JSON 可直接貼上物件、選擇 Form 可輸入 application/x-www-form-urlencoded 欄位、選擇 Multipart 用於檔案上傳（使用 name=@/path/to/file）、選擇 Raw 按原樣發送位元組，或選擇 XML 用於 SOAP 及類似的 API。
6. 設定認證：Basic 用於 user:password，Bearer 用於 OAuth 和 JWT 權杖，API 金鑰則可作為標頭（如 X-API-Key）或查詢參數（如 ?api_key=...）。
7. 新增旗標：切換最常用的 cURL 旗標：跟隨重新導向、請求 gzip、顯示回應標頭、詳細模式、靜音模式，或在本地偵錯時略過 TLS 憑證檢查。
8. 選擇輸出風格：帶有反斜線換行連接的「多行」風格最適合在指令稿中閱讀；「單行」風格最適合複製貼上；「Windows CMD」風格會使用雙引號並將百分比符號加倍；「PowerShell」風格則會明確呼叫 curl.exe，以免與 PowerShell 的別名衝突。
9. 複製並執行：點擊 複製指令，貼到您的終端機中，即可查看回應結果。

輸出風格詳解

多行（預設）將每個旗標放在單獨的行中，並以反斜線結尾。這是文件、網誌文章和 Shell 指令稿中最推薦的格式，因為它非常便於由上至下閱讀。

curl \
  -X POST \
  -H 'Content-Type: application/json' \
  --data '{"name":"Jesse"}' \
  'https://api.example.com/v1/users'

單行用空格將所有內容連成一體 — 非常適合臨時貼到終端機、日誌訊息或聊天對話框中。

Windows CMD 會將 Bash 風格的單引號轉換為雙引號（CMD 無法解析單引號），並透過加倍百分比符號來進行跳脫，以便指令能直接在 cmd.exe 或 .bat 檔案中原樣執行。

PowerShell 會明確呼叫 curl.exe，因為在 PowerShell 中 curl 是 Invoke-WebRequest 的別名，而後者有著完全不同的參數語法。

引號規則：單引號 vs 雙引號

在 Linux 和 macOS Bash 中，單引號是最安全的，因為 Bash 不會展開其中的變數或反引號。建構器會將數值內部字面上的 ' 轉換為跳脫序列 '\''，以便外層的單引號依然能正確配對。

當您希望 Bash 保留跳脫規則但又需要容納其他難以跳脫的引號字元時，雙引號會是正確的選擇。建構器會跳脫雙引號內部的 $、`、\\ 和 "，從而確保數值在傳輸過程中不被更改。

身分認證模式

Basic 認證會發送 Authorization: Basic base64(user:password)。cURL 旗標 -u user:password 會自動為您處理此編碼。請務必配合 HTTPS 使用 — 在純 HTTP 上使用 Basic 認證極易被竊聽攔截。

Bearer 權杖（OAuth 2.0、JWT、GitHub 個人存取權杖）會新增 Authorization: Bearer <token>。請像對待密碼一樣對待權杖：如果它不小心洩露到螢幕截圖、Slack 訊息或 CI 日誌中，請立即更換。

API 金鑰可以存放在標頭（X-API-Key、X-RapidAPI-Key）或查詢參數（?api_key=...）中。存放在標頭中通常更安全，因為 URL 經常會被反向代理伺服器和瀏覽器歷史記錄留存下來。

常用 HTTP 方法一覽

• GET — 讀取資源。應具備安全性和等冪性。
• POST — 建立新資源，或提交不符合 GET 語義的資料。不具備等冪性。
• PUT — 替換指定 URL 處的資源。具備等冪性。
• PATCH — 局部更新。根據 API 設計，通常使用 JSON Patch (RFC 6902) 或 Merge Patch (RFC 7396)。
• DELETE — 移除資源。具備等冪性。
• HEAD — 類似 GET，但伺服器僅返回標頭。可用於在不下載主體的情況下測試快取新鮮度或內容長度。
• OPTIONS — 查詢伺服器允許哪些 HTTP 方法並讀取 CORS 中介資料。

生成的指令故障排除

• SSL 憑證錯誤。 僅在面對受信任的主機或您自己的本地伺服器時，才開啟 --insecure。對於生產環境的偵錯，更推薦使用 --cacert 將 cURL 指向正確的 CA 憑證包。
• 回應為空或卡住。 使用 -v 詳細模式執行，以觀察 TLS 握手過程和標頭資訊。連線步驟卡住通常意味著伺服器無法連通；傳輸步驟卡住則代表伺服器已接受請求但處理緩慢。
• 415 Unsupported Media Type。 伺服器預期不同的 Content-Type。如果您沒有手動設定，建構器會為 JSON、表單和 XML 主體自動新增正確的值。
• 401 vs 403。 401 表示缺少憑證或憑證無效（請重新檢查 Bearer 權杖）；403 表示憑證有效但該使用者沒有相應的操作權限（請檢查範圍權限 scopes）。
• 413 Payload Too Large。 某些上游伺服器會將主體大小限制在 1–10 MB。此時可考慮使用分塊上傳端點或串流傳輸。

安全與隱私說明

• 本建構器完全在客戶端進行渲染。不會向您輸入的 URL 發送任何資料；輸出的純粹是指令文字。
• 避免貼上生產環境的權杖。如果必須這樣做，請將生成的指令視為敏感資訊 — 切勿將其提交至公開代碼庫、貼到含有機器人的聊天頻道中，或將其附加到公開的 Issue 上。
• 在指令稿中更推薦使用環境變數：寫成 -H 'Authorization: Bearer '"$TOKEN"，而不是直接將權杖硬編碼寫死。先用單引號閉合，再切換到雙引號包裹變數，以便 Bash 進行變數展開。

常見問題集

我可以從 Chrome 開發者工具 (DevTools) 匯入 cURL 指令嗎？

本建構器的功能方向正好相反 — 它是透過表單來生成 cURL。如果您想進行反向操作，請從開發者工具中「複製為 cURL」，並使用專門的 cURL 解析工具。

JSON 主體需要預先進行跳脫處理嗎？

不需要。請完全按照預期呈現的格式貼上 JSON。建構器會妥善處理引號跳脫，以確保主體完好無損地送達伺服器。

-d 和 --data-urlencode 有什麼區別？

-d 按原樣發送主體位元組。--data-urlencode 則會對每個欄位進行百分比編碼（URL-encode），這與瀏覽器發送 HTML 表單時的方式相同。建構器會為「表單」主體類型使用 --data-urlencode，而為 JSON / 原始資料 / XML 使用 --data。

我該如何上傳檔案？

請選擇 Multipart form-data 並新增一行如 avatar=@/Users/jesse/photo.png 的內容。其中的 @ 符號會通知 cURL 去讀取該路徑下的檔案內容。

為什麼 cURL 報告 “Argument list too long”（參數列表過長）？

這代表主體內容超出了 Shell 的 argv 限制。此時應改用檔案來傳遞主體，例如配合 --data @body.json。

本工具支援 HTTP/2 和 HTTP/3 嗎？

如果您的本地 cURL 在編譯時加入了正確的函式庫，則 cURL 本身是透過 --http2 和 --http3 來支援這兩者的。您可以手動將這兩個旗標新增到生成的指令中。