Content-Type ในการพัฒนาเว็บ: คืออะไร, ชนิด MIME และทำงานอย่างไร

Content-Type คืออะไร?

Content-Type คือส่วนหัว HTTP จากกลุ่มส่วนหัวการแสดงผลที่บอกผู้รับถึงรูปแบบของข้อมูลในเนื้อหาของข้อความ เป็นสิ่งจำเป็นสำหรับคำขอและการตอบสนอง HTTP ที่มีเนื้อหา และหากไม่มี ไคลเอ็นต์จะไม่สามารถตีความไบต์ที่ได้รับได้อย่างถูกต้อง ตาม Content-Type เบราว์เซอร์หรือแอปมือถือจะเลือกโปรแกรมแยกวิเคราะห์: สำหรับ text/html จะเริ่มต้นเอนจิน HTML, สำหรับ image/png — ตัวถอดรหัส PNG, สำหรับ application/json — โปรแกรมแยกวิเคราะห์ JSON

ค่า Content-Type คือ ชนิด MIME — ตัวระบุมาตรฐานสำหรับรูปแบบข้อมูล ตัวย่อ MIME ย่อมาจาก Multipurpose Internet Mail Extensions เนื่องจากมาตรฐานนี้ถูกสร้างขึ้นสำหรับไฟล์แนบอีเมล อย่างไรก็ตาม มันกลายเป็นรากฐานของ HTTP และปัจจุบันถูกใช้ทุกที่ — จากการส่งหน้าเว็บไปจนถึงการแลกเปลี่ยนข้อมูลใน REST API แต่ละชนิด MIME ประกอบด้วยสองส่วน: หมวดหมู่หลักและชนิดย่อยที่คั่นด้วยเครื่องหมายทับ

พารามิเตอร์ charset เสริม Content-Type สำหรับรูปแบบข้อความ ตัวอย่างเช่น Content-Type: text/html; charset=utf-8 หมายความว่ามีการส่งเอกสาร HTML ในรูปแบบการเข้ารหัส UTF-8 ตาม IETF RFC 7231 ส่วน 3.1.1.5 ส่วนหัว Content-Type เป็นสิ่งจำเป็นสำหรับข้อความ HTTP ที่มีเนื้อหา และการไม่มีจะถูกถือว่าเป็น application/octet-stream หรือนำไปสู่ MIME sniffing

ประวัติของชนิด MIME ใน HTTP

โปรโตคอล HTTP/0.9 ที่เปิดตัวในปี 1991 ส่งเฉพาะหน้า HTML ดังนั้นชนิดข้อมูลจึงเป็นที่เข้าใจโดยปริยาย ด้วยการเปิดตัว HTTP/1.0 ใน RFC 1945 นักพัฒนาตระหนักถึงความจำเป็นในการส่งรูปภาพ สไตล์ชีต และสคริปต์ พวกเขาปรับ มาตรฐาน MIME จากโปรโตคอลอีเมล และ Content-Type กลายเป็นส่วนสำคัญของ HTTP ตั้งแต่นั้นมา ทะเบียน IANA ได้ขยายเป็นหลายร้อยค่า — จาก text/html ที่คุ้นเคยไปจนถึง image/avif และ application/manifest+json ที่ทันสมัย

บทบาทของ Content-Type ในความปลอดภัย

Content-Type มีบทบาทสำคัญในการป้องกันการโจมตี หากเซิร์ฟเวอร์ส่งไฟล์ HTML ด้วยชนิด MIME text/plain เบราว์เซอร์จะไม่เรียกใช้ JavaScript หรือสร้าง DOM — ซึ่งป้องกันการโจมตี XSS ส่วนหัว X-Content-Type-Options: nosniff ที่ OWASP แนะนำ ห้ามเบราว์เซอร์คาดเดาชนิด MIME ตามเนื้อหาอย่างเด็ดขาด ตาม PortSwigger Research การโจมตี MIME sniffing แพร่หลายโดยเฉพาะใน Internet Explorer 6-9 ซึ่งเบราว์เซอร์ไม่สนใจ Content-Type และกำหนดชนิดจากไบต์แรกของไฟล์

โครงสร้างของชนิด MIME

ชนิด MIME ระบุในรูปแบบ type/subtype โดยที่ type คือหมวดหมู่ข้อมูลทั่วไป และ subtype คือรูปแบบเฉพาะภายในนั้น ตัวอย่างเช่น ใน image/png หมวดหมู่ image ระบุรูปภาพ และชนิดย่อย png ระบุรูปแบบ Portable Network Graphics มีเพียงไม่กี่หมวดหมู่: text, image, audio, video, application, multipart และ message ความหลากหลายที่เหลือมาจากชนิดย่อย ซึ่งมีจำนวนหลายร้อยชนิด

พารามิเตอร์เพิ่มเติมถูกส่งผ่านเครื่องหมายอัฒภาคหลังชนิดย่อย พารามิเตอร์ที่พบบ่อยที่สุดคือ charset สำหรับระบุการเข้ารหัส Content-Type: application/json; charset=utf-8 ระบุว่ามีการส่งเอกสาร JSON ในรูปแบบการเข้ารหัส UTF-8 ตามหลักการแล้ว charset สำหรับ application/json ซ้ำซ้อนเนื่องจาก JSON อยู่ใน UTF-8 เสมอตาม RFC 8259 แต่การระบุอย่างชัดเจนช่วยเพิ่มความเข้ากันได้กับไคลเอ็นต์ HTTP รุ่นเก่า

ชนิด MIME มาตรฐานและไม่มาตรฐาน

ชนิด MIME มาตรฐาน ลงทะเบียนในทะเบียน IANA และมีคำนำหน้าหมวดหมู่หลัก ชนิดที่ไม่มาตรฐาน (เฉพาะผู้ขาย) ใช้คำนำหน้า x- หรือรูปแบบ vnd.company.type — ตัวอย่างเช่น application/vnd.google-earth.kml+xml สำหรับรูปแบบ KML ของ Google เบราว์เซอร์อาจไม่รู้จักชนิดที่ไม่มาตรฐาน ดังนั้นสำหรับไฟล์แนบที่ไม่รู้จักจึงใช้ application/octet-stream — สตรีมไบนารีสากลที่เบราว์เซอร์ไม่พยายามแสดง แต่เสนอให้ดาวน์โหลดเป็นไฟล์

พารามิเตอร์ charset ในทางปฏิบัติ

พารามิเตอร์ charset มีความสำคัญต่อการแสดงข้อความที่ถูกต้อง หากไม่มี เบราว์เซอร์อาจตีความตัวอักษรผิด ซึ่งนำไปสู่ mojibake มาตรฐานสำหรับเว็บคือ UTF-8 แต่ก็พบ ISO-8859-1 (Latin-1) สำหรับภาษายุโรปตะวันตกและ windows-1251 สำหรับอักษรซีริลลิกบนเว็บไซต์เก่า คำแนะนำของ W3C คือระบุ charset=utf-8 เสมอสำหรับ text/html และ text/plain ในขณะที่ไม่จำเป็นต้องใช้ charset สำหรับ application/json

ชนิด Content-Type ทั่วไป

ในทางปฏิบัติ นักพัฒนาเว็บและมือถือทำงานกับชุดชนิด MIME ที่จำกัด การรู้จักชนิดเหล่านี้เป็นสิ่งจำเป็นสำหรับการกำหนดค่าเซิร์ฟเวอร์อย่างถูกต้อง การเขียนไคลเอ็นต์ HTTP และการจัดการไฟล์คงที่ text/html เป็นชนิดหลักสำหรับหน้าเว็บ ซึ่งเซิร์ฟเวอร์ Apache และ Nginx ส่งคืนตามค่าเริ่มต้นสำหรับไฟล์ HTML application/xhtml+xml ใช้น้อยกว่าและใช้เฉพาะสำหรับเอกสาร XHTML

application/json กลายเป็นมาตรฐานสำหรับ REST API เซิร์ฟเวอร์ส่งคืนข้อมูล JSON ด้วยชนิด MIME นี้ และไคลเอ็นต์ส่งในคำขอ POST และ PUT text/javascript (เลิกใช้แล้ว) และ application/javascript ใช้สำหรับไฟล์ JavaScript ตาม แบบสำรวจ W3Techs, 2025 JSON เป็นรูปแบบข้อมูลที่เติบโตเร็วที่สุดบนเว็บ แซงหน้า XML ในปี 2018 สำหรับบริการ SOAP ยังคงใช้ text/xml หรือ application/soap+xml

สำหรับรูปภาพ ชนิด MIME ถูกกำหนดโดยรูปแบบไฟล์: image/jpeg สำหรับ JPEG, image/png สำหรับ PNG, image/gif สำหรับ GIF, image/webp สำหรับรูปแบบ WebP ที่ทันสมัย image/svg+xml ใช้สำหรับกราฟิกเวกเตอร์และรองรับสไตล์และสคริปต์แบบฝัง video/mp4, audio/mpeg และ application/pdf เป็นชนิดอื่นที่พบบ่อย สำหรับฟอนต์เว็บ ใช้ font/woff2, font/woff และ font/ttf

Content-Type ในการอัปโหลดไฟล์

เมื่ออัปโหลดไฟล์ผ่านแบบฟอร์ม HTML จะใช้ multipart/form-data — ชนิด MIME แบบประกอบที่แบ่งคำขอเป็นหลายส่วน แต่ละส่วนมีส่วนหัว Content-Type และ Content-Disposition ของตัวเองที่ระบุชื่อฟิลด์และชื่อไฟล์ดั้งเดิม เซิร์ฟเวอร์รับไฟล์ด้วยชนิด MIME จริงที่เบราว์เซอร์กำหนดและสามารถตรวจสอบได้ที่ฝั่งแบ็กเอนด์ application/octet-stream ใช้สำหรับไฟล์ชนิดที่ไม่รู้จัก — เบราว์เซอร์ไม่พยายามแสดงเนื้อหาแต่เสนอให้บันทึกลงดิสก์

ผลกระทบของ Content-Type ต่อการแคช

ชนิด MIME ส่งผลต่อนโยบายการแคชของ CDN และเบราว์เซอร์ รูปภาพที่มี URL คงที่มักถูกแคชเป็นระยะเวลานาน (หนึ่งปีหรือมากกว่า) ในขณะที่หน้า HTML ถูกแคชเป็นนาทีหรือวินาที เซิร์ฟเวอร์ CDN เช่น Cloudflare และ Akamai ใช้ Content-Type เพื่อเลือกอัลกอริทึมการบีบอัด: text/* ถูกบีบอัดด้วย gzip หรือ brotli, image/* ไม่ถูกบีบอัดเนื่องจากรูปภาพถูกบีบอัดแล้ว การกำหนดค่า Content-Type ที่ถูกต้องบนเซิร์ฟเวอร์ส่งผลโดยตรงต่อประสิทธิภาพการโหลดของหน้าเว็บและแอปพลิเคชันมือถือ

เซิร์ฟเวอร์และไคลเอ็นต์ใช้ Content-Type อย่างไร

เซิร์ฟเวอร์ตั้งค่าส่วนหัว Content-Type ในการตอบสนอง HTTP ตามชนิดของไฟล์ที่ร้องขอหรือเนื้อหาที่สร้างแบบไดนามิก เซิร์ฟเวอร์เว็บยอดนิยมเช่น Nginx และ Apache มีตารางชนิด MIME ในตัวที่จับคู่นามสกุลไฟล์กับ Content-Type ที่เกี่ยวข้อง ตัวอย่างเช่น index.html ได้รับ text/html และ style.css ได้รับ text/css สำหรับการตอบสนองแบบไดนามิก นักพัฒนากำหนด Content-Type ในโค้ดแอปพลิเคชันใน PHP, Python, Java หรือ Kotlin

ไคลเอ็นต์ใช้ Content-Type เพื่อเลือกตัวจัดการ หากเซิร์ฟเวอร์ส่งคืน text/html เบราว์เซอร์จะเริ่มโปรแกรมแยกวิเคราะห์ HTML และสร้างโครงสร้าง DOM หาก image/png — เริ่มตัวถอดรหัส PNG หาก Content-Type หายไปหรือไม่ถูกต้อง ไคลเอ็นต์จะใช้ MIME sniffing — พยายามคาดเดาชนิดจากลายเซ็น (ไบต์มหัศจรรย์) ที่จุดเริ่มต้นของไฟล์ JPEG เริ่มต้นด้วยไบต์ FF D8 FF, PNG เริ่มต้นด้วย 89 50 4E 47 และ PDF เริ่มต้นด้วย 25 50 44 46 กระบวนการนี้อาจเป็นอันตรายและถูกปิดใช้งานโดยส่วนหัว X-Content-Type-Options: nosniff

ในแอปพลิเคชันมือถือ Content-Type ถูกจัดการโดยไคลเอ็นต์ HTTP OkHttp บน Android จะแยกวิเคราะห์ส่วนหัว Content-Type จากการตอบสนองโดยอัตโนมัติและให้ผ่านเมธอด Response.header("Content-Type") ไคลเอ็นต์ URLSession ของ iOS ทำเช่นเดียวกันผ่านคุณสมบัติ URLResponse.mimeType บนทั้งสองแพลตฟอร์ม Content-Type ถูกใช้เพื่อเลือกโปรแกรมแยกวิเคราะห์: JSON — ผ่าน Moshi หรือ Gson บน Android, ผ่าน Codable บน iOS; รูปภาพ — ผ่าน Glide, Coil หรือ SDWebImage

การเจรจาเนื้อหาผ่าน Accept และ Content-Type

การเจรจาเนื้อหา เป็นกลไก HTTP ที่ไคลเอ็นต์ระบุรูปแบบการตอบสนองที่ต้องการผ่านส่วนหัว Accept และเซิร์ฟเวอร์เลือกรูปแบบที่เหมาะสมและส่งคืนพร้อมกับ Content-Type ที่เกี่ยวข้อง ตัวอย่างเช่น ไคลเอ็นต์ส่ง Accept: application/json เซิร์ฟเวอร์ตอบสนองด้วย Content-Type: application/json หากเซิร์ฟเวอร์ไม่สามารถให้รูปแบบที่ร้องขอได้ มันจะส่งคืน 406 Not Acceptable ใน REST API กลไกนี้ช่วยให้จุดสิ้นสุดเดียวสามารถส่งคืนข้อมูลในรูปแบบ JSON, XML หรือ HTML

Content-Type ในคำขอและการตอบสนอง

ส่วนหัว Content-Type ใช้ทั้งในคำขอ HTTP และการตอบสนอง HTTP ในคำขอ มันระบุรูปแบบของเนื้อหาคำขอ เช่น เมื่อส่ง JSON ผ่าน POST ในการตอบสนอง มันระบุรูปแบบของข้อมูลที่ส่งคืน ความแตกต่างหลักคือ Content-Type ของคำขอถูกกำหนดโดยไคลเอ็นต์ ในขณะที่ Content-Type ของการตอบสนองถูกกำหนดโดยเซิร์ฟเวอร์ การตั้งค่า Content-Type ไม่ถูกต้อง ในคำขอทำให้เซิร์ฟเวอร์ไม่สามารถแยกวิเคราะห์เนื้อหาได้ และส่งคืนข้อผิดพลาด 400 Bad Request หรือ 415 Unsupported Media Type

ในคำขอ HTTP Content-Type เป็นสิ่งจำเป็นสำหรับเมธอด POST, PUT และ PATCH หากคำขอมีเนื้อหา GET, HEAD และ DELETE โดยทั่วไปไม่ใช้เนื้อหา ดังนั้น Content-Type จึงไม่ถูกระบุหรือถูกละเว้นสำหรับเมธอดเหล่านี้ เมื่อส่งแบบฟอร์ม HTML ด้วยแอตทริบิวต์ enctype="multipart/form-data" เบราว์เซอร์จะตั้งค่า Content-Type: multipart/form-data โดยอัตโนมัติพร้อมสตริงขอบเขตที่ไม่ซ้ำกันซึ่งแยกส่วนต่างๆ ของคำขอประกอบ แต่ละส่วนถูกคั่นด้วย --boundary และจุดสิ้นสุดของคำขอถูกทำเครื่องหมายด้วย --boundary--

ในการตอบสนอง HTTP Content-Type ถูกกำหนดโดยเซิร์ฟเวอร์ หากเซิร์ฟเวอร์ไม่ระบุ Content-Type ไคลเอ็นต์จะเปิดใช้งาน MIME sniffing หรือประมวลผลการตอบสนองเป็น application/octet-stream เมธอด HTTP HEAD ช่วยให้รับส่วนหัวการตอบสนอง รวมถึง Content-Type โดยไม่ต้องส่งเนื้อหา ซึ่งมีประโยชน์สำหรับการตรวจสอบชนิดทรัพยากรก่อนโหลดเต็มที่ เซิร์ฟเวอร์ CDN อาจแทนที่ Content-Type เมื่อแปลงเนื้อหา — ตัวอย่างเช่น เมื่อแปลงรูปภาพเป็น WebP

import okhttp3.*

fun checkContentType() {
    val client = OkHttpClient()
    val request = Request.Builder()
        .url("https://api.example.com/resource")
        .head()
        .build()

    client.newCall(request).execute().use { response ->
        val contentType = response.header("Content-Type")
        val mediaType = MediaType.parse(contentType)
        println("ชนิด: ${mediaType?.type}, ชนิดย่อย: ${mediaType?.subtype}")
    }
}

Content-Type ในไคลเอ็นต์ HTTP มือถือ

ในการพัฒนามือถือ ส่วนหัว Content-Type ถูกจัดการโดยอัตโนมัติโดยไคลเอ็นต์ HTTP ใน OkHttp บน Android Content-Type ถูกตั้งค่าผ่าน RequestBody: val body = "{}".toRequestBody("application/json".toMediaType()) Retrofit จัดการ Content-Type ผ่านคำอธิบายประกอบ: @Body สำหรับ JSON, @Part สำหรับ multipart บน iOS URLSession ตั้งค่า Content-Type สำหรับ HTTPBody และ Alamofire ทำผ่านพารามิเตอร์ encoding: JSONEncoding.default หรือ URLEncoding.default การตั้งค่า Content-Type ด้วยตนเองจำเป็นเมื่อทำงานกับซ็อกเก็ตดิบหรือโปรโตคอลที่กำหนดเอง

ข้อผิดพลาดของ Content-Type

Content-Type ที่ไม่ถูกต้องเป็นหนึ่งในปัญหาที่พบบ่อยที่สุดในการพัฒนาและรวมบริการเว็บ ข้อผิดพลาดที่พบบ่อยที่สุดคือเมื่อเซิร์ฟเวอร์ส่งคืน text/html แทน application/json ไคลเอ็นต์ได้รับ JSON เป็นสตริง HTML ไม่สามารถแยกวิเคราะห์ได้และโยนข้อยกเว้น สิ่งนี้เกิดขึ้นเมื่อเฟรมเวิร์กเว็บถูกกำหนดค่าสำหรับ HTML เป็นค่าเริ่มต้นและนักพัฒนาลืมแทนที่ Content-Type สำหรับจุดสิ้นสุด API ใน PHP สิ่งนี้ปรากฏเมื่อไม่มี header('Content-Type: application/json') ใน Spring Boot — เมื่อไม่มีคำอธิบายประกอบ produces

ข้อผิดพลาดที่พบบ่อยเป็นอันดับสองคือ charset ไม่ถูกต้องหรือหายไป หากเซิร์ฟเวอร์ส่ง text/html; charset=iso-8859-1 และเบราว์เซอร์คาดหวัง UTF-8 อักขระซีริลลิกจะแสดงเป็น mojibake ปัญหานี้เป็นเรื่องปกติสำหรับเว็บไซต์เก่าที่ยังไม่ได้ย้ายไปใช้ UTF-8 สำหรับ JSON ข้อผิดพลาดนี้พบน้อยกว่าเนื่องจาก RFC 8259 กำหนด UTF-8 โดยไม่ต้องเจรจาเพิ่มเติม วิธีแก้ไขคือระบุ charset=utf-8 อย่างชัดเจนเสมอสำหรับชนิด MIME แบบข้อความในการกำหนดค่าเซิร์ฟเวอร์

ปัญหาที่สามคือ ความไม่ตรงกันระหว่าง Content-Type กับเนื้อหาจริง หากเซิร์ฟเวอร์ส่ง Content-Type: image/png แต่เนื้อหาการตอบสนองมีรูปภาพ WebP เบราว์เซอร์อาจไม่ถอดรหัส เซิร์ฟเวอร์ CDN บางครั้งบีบอัดรูปภาพด้วยการเปลี่ยนรูปแบบแต่ไม่อัปเดตส่วนหัว Content-Type การตรวจสอบความสอดคล้องของ Content-Type กับเนื้อหาจริงเป็นขั้นตอนบังคับในการทดสอบ API และการทดสอบการรวมระบบของแอปพลิเคชันมือถือ

การวินิจฉัยและแก้ไขข้อผิดพลาด Content-Type

สำหรับการดีบัก ให้ใช้เครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์ (แท็บ Network), curl พร้อมแฟลก -I เพื่อตรวจสอบส่วนหัวการตอบสนอง หรือโปรแกรมดักจับการรับส่งข้อมูลเช่น Charles Proxy และ Wireshark Nginx ถูกกำหนดค่าผ่านคำสั่ง include mime.types, Apache — ผ่าน AddType และ AddDefaultCharset สำหรับไฟล์คงที่ ให้ตรวจสอบเสมอว่านามสกุลไฟล์ตรงกับชนิด MIME ของมัน สำหรับการตอบสนองแบบไดนามิกในภาษาการเขียนโปรแกรมทั้งหมด ให้กำหนด Content-Type อย่างชัดเจนก่อนส่งออกข้อมูล — ซึ่งป้องกันปัญหาส่วนใหญ่