Content-Type در توسعه وب: چیست، انواع MIME و نحوه کار

Content-Type چیست؟

Content-Type — یک هدر HTTP از گروه هدرهای نمایش (representation headers) است که به گیرنده درباره فرمت داده‌های موجود در بدنه پیام اطلاع می‌دهد. این هدر برای درخواست‌ها و پاسخ‌های HTTP که شامل بدنه (body) هستند اجباری است و بدون آن مشتری نمی‌تواند بایت‌های دریافتی را به درستی تفسیر کند. مرورگر یا برنامه موبایل بر اساس 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 همیشه طبق مشخصات RFC 8259 به صورت UTF-8 است، اما مشخص کردن صریح سازگاری با مشتریان HTTP قدیمی را بهبود می‌بخشد.

انواع MIME استاندارد و غیراستاندارد

انواع MIME استاندارد در ثبت IANA ثبت می‌شوند و پیشوند دسته اصلی را دارند. انواع غیراستاندارد (vendor-specific) از پیشوند 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 مشخص کنید و برای application/json charset مورد نیاز نیست.

انواع اصلی 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 Survey، 2025، JSON سریع‌ترین فرمت داده در حال رشد در وب است و در سال 2018 از XML پیشی گرفته است. برای سرویس‌های 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 در اندروید به طور خودکار هدر Content-Type را از پاسخ تجزیه می‌کند و آن را از طریق متد Response.header("Content-Type") فراهم می‌کند. مشتری iOS URLSession همین کار را از طریق ویژگی URLResponse.mimeType انجام می‌دهد. در هر دو پلتفرم، Content-Type برای انتخاب تجزیه‌گر استفاده می‌شود: JSON — از طریق Moshi یا Gson در اندروید، از طریق Codable در iOS; تصاویر — از طریق Glide، Coil یا SDWebImage.

توافق محتوا از طریق Accept و Content-Type

Content negotiation (توافق محتوا) — مکانیزم HTTP که در آن مشتری فرمت پاسخ مورد نظر را از طریق هدر Accept مشخص می‌کند و سرور فرمت مناسب را انتخاب کرده و آن را با Content-Type مربوطه بازمی‌گرداند. برای مثال، مشتری Accept: application/json ارسال می‌کند، سرور با Content-Type: application/json پاسخ می‌دهد. اگر سرور نتواند فرمت درخواستی را ارائه دهد، 406 Not Acceptable را برمی‌گرداند. در REST API، این مکانیزم به یک endpoint اجازه می‌دهد داده‌ها را در JSON، XML یا HTML بازگرداند.

Content-Type در درخواست‌ها و پاسخ‌ها

هدر Content-Type هم در درخواست‌های HTTP (Request) و هم در پاسخ‌های HTTP (Response) استفاده می‌شود. در درخواست‌ها، فرمت بدنه درخواست را مشخص می‌کند، برای مثال هنگام ارسال JSON از طریق POST. در پاسخ‌ها — فرمت داده‌های بازگردانده شده را. تفاوت اساسی این است که Content-Type درخواست را مشتری و Content-Type پاسخ را سرور تنظیم می‌کند. تنظیم نادرست Content-Type در درخواست باعث می‌شود که سرور نتواند بدنه را تجزیه کند و خطای 400 Bad Request یا 415 Unsupported Media Type را بازگرداند.

در درخواست‌های HTTP، Content-Type برای متدهای POST، PUT و PATCH اگر درخواست حاوی بدنه (body) باشد اجباری است. GET، HEAD و DELETE معمولاً از بدنه استفاده نمی‌کنند، بنابراین Content-Type برای آنها مشخص نمی‌شود یا نادیده گرفته می‌شود. هنگام ارسال فرم HTML با ویژگی enctype="multipart/form-data"، مرورگر به طور خودکار Content-Type: multipart/form-data را با یک رشته مرز (boundary) منحصر به فرد تنظیم می‌کند که بخش‌های درخواست ترکیبی را جدا می‌کند. هر بخش با --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 در اندروید، 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 را برای endpoint API بازنویسی کند. در PHP این با عدم وجود header('Content-Type: application/json') ظاهر می‌شود، در Spring Boot — با عدم وجود حاشیه‌نویسی produces.

دومین خطای رایج — charset نادرست یا گمشده. اگر سرور text/html; charset=iso-8859-1 را ارسال کند و مرورگر UTF-8 را انتظار داشته باشد، کاراکترهای سیریلیک به صورت بهم ریخته نمایش داده می‌شوند. این مشکل برای سایت‌های قدیمی که به UTF-8 مهاجرت نکرده‌اند مشخص است. برای JSON چنین خطایی کمتر رخ می‌دهد، زیرا RFC 8259 UTF-8 را بدون توافق اضافی الزامی می‌کند. راه‌حل — همیشه در پیکربندی سرور برای انواع MIME متنی به طور صریح charset=utf-8 را مشخص کنید.

سومین مشکل — عدم تطابق Content-Type با محتوای واقعی. اگر سرور Content-Type: image/png را ارسال کند اما بدنه پاسخ حاوی تصویر WebP باشد، مرورگر نمی‌تواند آن را رمزگشایی کند. سرورهای CDN گاهی تصاویر را با تغییر فرمت فشرده می‌کنند اما هدر Content-Type را به‌روز نمی‌کنند. بررسی تطابق Content-Type با محتوای واقعی — مرحله اجباری تست API و تست یکپارچه‌سازی برنامه‌های موبایل است.

تشخیص و رفع خطاهای Content-Type

برای رفع اشکال از ابزارهای توسعه‌دهنده مرورگر (تب Network)، curl با پرچم -I برای بررسی هدرهای پاسخ یا snifferهای ترافیک مانند Charles Proxy و Wireshark استفاده کنید. Nginx از طریق دستور include mime.types پیکربندی می‌شود، Apache — از طریق AddType و AddDefaultCharset. برای فایل‌های استاتیک همیشه بررسی کنید که پسوند فایل با نوع MIME آن مطابقت دارد. برای پاسخ‌های پویا در همه زبان‌های برنامه‌نویسی قبل از خروجی داده، Content-Type را به صراحت تنظیم کنید — این کار از اکثریت قاطع مشکلات جلوگیری می‌کند.