初學者指南：認識 Content-Type: application/x-www-form-urlencoded
更新日期： 2025 年 5 月 26 日
當你在前端開發中送出表單資料、或是使用 fetch()、axios 發送 POST 請求時，你正在與伺服器交換資料。
而為了讓伺服器知道「你送的資料是什麼格式」，HTTP 標頭（Header）中的 Content-Type 就扮演了關鍵角色。
其中一個最常見的資料格式就是：application/x-www-form-urlencoded
這篇文章將帶你深入了解它是什麼、資料長什麼樣子、與 JSON 有何不同、實際應用場景有哪些！
什麼是 application/x-www-form-urlencoded？
這是一種表單資料格式，主要用來在 HTTP 請求中傳送資料。
它的格式最早被設計來搭配 <form> 表單使用。
當你在表單中輸入資料，然後按下「提交」，預設就會用這種方式把資料送出去。
它的資料長怎樣？
它會把資料編碼成鍵值對的字串，中間用 & 分隔，像這樣：
name=小明&age=18&city=Taipei重點特性：
| 特性 | 說明 |
|---|---|
| 資料型態 | 純文字（key=value） |
| 多個欄位 | 用 & 分隔 |
| 特殊字元會被編碼 | 空白會變成 +，其他符號會 URL encode，例如 @ 會變成 %40 |
| 沒有巢狀結構 | 不像 JSON 可直接表示物件或陣列，需要自己處理 |
實際範例：送出資料給伺服器的完整流程
在前端開發中，一個最基本也最常見的任務，就是把使用者在表單中輸入的資料送給伺服器。
這些資料可能是註冊資訊、登入帳號、留言內容、訂單資訊等。
這段流程乍看簡單，但其實背後涉及到 HTTP 的資料格式與編碼機制，必須清楚了解，才能讓資料正確被送出與解析。
表單送出範例：傳統 HTML 表單
假設我們有一個最基本的 HTML 表單如下：
<form method="POST" action="/submit">
<input name="name" value="小明" />
<input name="email" value="[email protected]" />
<button type="submit">送出</button>
</form>當使用者按下送出按鈕，瀏覽器會自動將表單內的欄位資料送出，並依照 Content-Type: application/x-www-form-urlencoded 的預設格式，自動編碼成如下字串：
name=%E5%B0%8F%E6%98%8E&email=ming%40example.com這段內容其實是把資料轉換成「key=value」的形式，中間用 & 連接每一筆欄位值。
而中文字 小明 和符號 @ 都會被進行URL 編碼（percent-encoding），讓它們在網路傳輸過程中不會造成語意錯誤或格式衝突。
🔍 編碼後的解讀：
| 原始值 | 編碼後 |
|---|---|
| 小明 | %E5%B0%8F%E6%98%8E |
| @ | %40 |
| name=小明 | name=%E5%B0%8F%E6%98%8E |
使用 JavaScript + Fetch 手動送出資料
如果你不是使用傳統表單，而是使用 JavaScript 搭配 fetch() 發送 AJAX 請求，那麼就必須手動建立符合 application/x-www-form-urlencoded 規範的資料格式。
✅ 實作範例：
const data = new URLSearchParams();
data.append("name", "小明");
data.append("email", "[email protected]");
fetch("/submit", {
method: "POST",
headers: {
"Content-Type": "application/x-www-form-urlencoded"
},
body: data.toString() // 輸出為：name=%E5%B0%8F%E6%98%8E&email=ming%40example.com
});這段程式碼的關鍵點：
URLSearchParams是內建的 JavaScript 類別，專門用來處理x-www-form-urlencoded格式的資料。- 使用
append()方法可以一筆一筆加入欄位資料，類似表單欄位名稱與值的對應。 - 最後呼叫
.toString()，會輸出符合 HTTP 傳輸格式的字串，並自動進行 URL 編碼。
這樣一來，就等同於用 JavaScript 模擬了一個完整的表單送出流程，而且格式與傳統 HTML 表單的效果一模一樣，後端也能無縫解析這段資料。
Content-Type 是什麼？為什麼要設？
在 HTTP 請求中，Content-Type 標頭（header）用來說明你送出去的資料格式是什麼。這樣後端才能知道該如何解析 body 的內容。
在本範例中，我們設定：
Content-Type: application/x-www-form-urlencoded這代表我們送出的是表單資料（與 HTML <form> 預設相同），屬於最常見的傳統格式。其他常見的格式還包括：
| Content-Type | 說明 |
|---|---|
| application/x-www-form-urlencoded | 表單預設格式，資料為 key=value&key=value |
| application/json | 現代 API 常用格式，body 為 JSON 字串 |
| multipart/form-data | 上傳檔案時使用，搭配 FormData 傳送 |
根據你設定的 Content-Type，後端會選擇不同方式解析資料。如果你送的是 JSON，卻沒標明 Content-Type，後端可能會無法正確解析，導致出現錯誤。
與 application/json 有什麼差別？
在現代 Web 開發中，最常見的兩種資料傳送格式就是：
application/x-www-form-urlencodedapplication/json
這兩種格式在表面上都能達成「資料送出」的目的，但其實在資料結構、可讀性、支援範圍、用途習慣等方面有明顯差異。
差異比較表：
| 比較項目 | application/x-www-form-urlencoded | application/json |
|---|---|---|
| 資料格式 | 鍵值對字串，例如：name=小明&age=18 | JSON 結構，例如：{"name":"小明","age":18} |
| 巢狀結構支援 | 不支援，需手動展開成平面結構 | 完整支援物件、陣列、巢狀層級 |
| 可讀性 | 中等，URL 編碼後閱讀困難 | 高，可視為物件結構，更直觀 |
| 後端解析習慣 | 傳統後端語言（如 PHP、Java Servlet）有內建支援 | 現代框架（如 Node.js、Django REST）常用 |
| 最常見場合 | 表單提交、登入表單、舊系統整合 | RESTful API、SPA、JSON-RPC 等 |
為什麼格式會影響實作？
不同格式的選擇，會直接影響：
- 你怎麼撰寫 JavaScript 的請求程式碼
- 後端要如何解析與驗證請求資料
- 資料傳輸的彈性與結構完整性
舉例來說，若你要送出一筆含有陣列的資料，如：
{
name: "小明",
skills: ["HTML", "CSS", "JavaScript"]
}使用 application/json 可以原封不動地送出；但若使用 x-www-form-urlencoded，則必須手動攤平成：
name=小明&skills[0]=HTML&skills[1]=CSS&skills[2]=JavaScript這不僅麻煩，也容易出錯。
實務建議：
| 使用情境 | 建議使用格式 |
|---|---|
| ✅ HTML 表單、登入表單 | application/x-www-form-urlencoded |
| ✅ 舊式後端（如 PHP） | application/x-www-form-urlencoded |
| ✅ API 開發、資料結構複雜 | application/json |
| ✅ 前後端分離的 Web App 或 SPA | application/json |
簡單來說：
- 簡單資料 + 舊系統 = 選用
x-www-form-urlencoded - 現代應用 + 巢狀資料 = 推薦
application/json
何時使用 application/x-www-form-urlencoded？
雖然現在 JSON 是最主流的資料格式，但 application/x-www-form-urlencoded 仍有其不可取代的用途與特定情境：
HTML 表單的預設格式
HTML 表單（<form>）若沒有特別設定 enctype，送出的內容預設就是這種格式：
<form method="POST" action="/submit">
<input name="name" value="小明">
<button type="submit">送出</button>
</form>瀏覽器會自動把這些資料轉成：
name=%E5%B0%8F%E6%98%8E並加入 Content-Type: application/x-www-form-urlencoded，不需開發者手動處理。
傳統後端語言與框架的支援度高
許多傳統後端框架（如 PHP、ASP.NET、Java Servlet、Ruby on Rails）都內建對這種格式的解析功能。例如在 PHP 中，你可以直接用：
$_POST['name'];就取得表單送來的 name 欄位值。這也是許多老系統仍習慣使用這種格式的原因。
與舊系統或低階硬體整合時
有些第三方 API、表單平台、嵌入式裝置等，僅支援 application/x-www-form-urlencoded，甚至無法解析 JSON。此時，你必須配合這種格式，才能正確傳輸資料。
資料結構簡單、變數少的情境
若你只需要傳送幾個欄位，例如登入時只送出帳號與密碼，或是一個簡單查詢表單，使用 x-www-form-urlencoded 是輕量又方便的選擇。
結論
application/x-www-form-urlencoded 雖然是較老的資料格式，但仍在許多情境下扮演重要角色。
理解它與 application/json 的差異，有助於你在開發過程中根據不同需求選擇正確的格式，避免資料錯誤或與後端系統不相容的問題。
✅ 一句話記憶：表單送出選 urlencoded，API 溝通選 JSON。