ویب ڈویلپمنٹ میں 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 ظاہر کرتا ہے کہ UTF-8 انکوڈنگ میں ایک HTML دستاویز منتقل ہو رہی ہے۔ IETF RFC 7231، حصہ 3.1.1.5 کے مطابق، Content-Type ہیڈر HTTP پیغامات کے لیے لازمی ہے جن میں جسم ہو، اور اس کی عدم موجودگی کو application/octet-stream سمجھا جاتا ہے یا MIME sniffing کا باعث بنتا ہے۔

HTTP میں MIME اقسام کی تاریخ

HTTP/0.9 پروٹوکول، جو 1991 میں جاری ہوا تھا، صرف HTML صفحات منتقل کرتا تھا، لہذا ڈیٹا کی قسم ڈیفالٹ طور پر مضمر تھی۔ RFC 1945 میں HTTP/1.0 کے متعارف ہونے کے ساتھ، ڈویلپرز نے تصاویر، اسٹائل شیٹس اور اسکرپٹس کو منتقل کرنے کی ضرورت محسوس کی۔ انہوں نے ای میل پروٹوکول سے MIME معیار کو اپنایا، اور Content-Type HTTP کا ایک لازمی حصہ بن گیا۔ اس کے بعد سے، IANA رجسٹری سینکڑوں اقدار تک پھیل گئی ہے — مانوس text/html سے جدید image/avif اور application/manifest+json تک۔

سیکیورٹی میں Content-Type کا کردار

Content-Type حملوں سے تحفظ میں اہم کردار ادا کرتا ہے۔ اگر سرور text/plain MIME قسم کے ساتھ HTML فائل بھیجتا ہے، تو براؤزر 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 ظاہر کرتا ہے کہ UTF-8 انکوڈنگ میں ایک JSON دستاویز منتقل ہو رہی ہے۔ رسمی طور پر، application/json کے لیے charset بے کار ہے کیونکہ RFC 8259 کے مطابق JSON ہمیشہ UTF-8 میں ہوتا ہے، لیکن واضح تعین پرانے HTTP کلائنٹس کے ساتھ مطابقت بہتر بناتا ہے۔

معیاری اور غیر معیاری MIME اقسام

معیاری MIME اقسام IANA رجسٹری میں رجسٹرڈ ہوتی ہیں اور ان کا ایک اہم زمرہ کا سابقہ ہوتا ہے۔ غیر معیاری (ویندرمخصوص) اقسام x- سابقہ یا vnd.company.type فارمیٹ استعمال کرتی ہیں — مثال کے طور پر، Google کے KML فارمیٹ کے لیے application/vnd.google-earth.kml+xml۔ براؤزر غیر معیاری اقسام کو نہیں پہچان سکتے، لہذا نامعلوم منسلکات کے لیے application/octet-stream استعمال کیا جاتا ہے — ایک عالمگیر بائنری سٹریم جسے براؤزر ڈسپلے کرنے کی کوشش نہیں کرتا بلکہ فائل کے طور پر ڈاؤن لوڈ کرنے کی پیشکش کرتا ہے۔

عملی طور پر charset پیرامیٹر

charset پیرامیٹر درست ٹیکسٹ ڈسپلے کے لیے اہم ہے۔ اس کے بغیر، براؤزر حروف کی غلط تشریح کر سکتا ہے، جس سے mojibake ہوتا ہے۔ ویب کے لیے معیار UTF-8 ہے، لیکن مغربی یورپی زبانوں کے لیے ISO-8859-1 (Latin-1) اور پرانی سائٹوں پر سیریلک کے لیے windows-1251 بھی پائے جاتے ہیں۔ W3C کی سفارش ہے کہ text/html اور text/plain کے لیے ہمیشہ charset=utf-8 متعین کریں، جبکہ application/json کے لیے charset کی ضرورت نہیں ہے۔

Content-Type کی عام اقسام

عملی طور پر، ویب ڈویلپرز اور موبائل ڈویلپرز MIME اقسام کے ایک محدود سیٹ کے ساتھ کام کرتے ہیں۔ ان اقسام کا علم سرورز کو درست طریقے سے ترتیب دینے، HTTP کلائنٹ لکھنے اور جامد فائلوں کو سنبھالنے کے لیے ضروری ہے۔ text/html ویب صفحات کے لیے اہم قسم ہے، جو Apache اور Nginx سرورز HTML فائلوں کے لیے ڈیفالٹ طور پر لوٹاتے ہیں۔ application/xhtml+xml کم استعمال ہوتا ہے اور صرف XHTML دستاویزات کے لیے۔

application/json REST API کے لیے معیار بن گیا ہے۔ سرور اس MIME قسم کے ساتھ JSON ڈیٹا لوٹاتے ہیں اور کلائنٹ اسے POST اور PUT درخواستوں میں بھیجتے ہیں۔ text/javascript (متروک) اور application/javascript JavaScript فائلوں کے لیے استعمال ہوتے ہیں۔ W3Techs Survey، 2025 کے مطابق، JSON ویب پر سب سے تیزی سے بڑھنے والا ڈیٹا فارمیٹ ہے، جس نے 2018 میں XML کو پیچھے چھوڑ دیا۔ SOAP سروسز کے لیے، اب بھی text/xml یا application/soap+xml استعمال ہوتا ہے۔

تصاویر کے لیے، MIME قسم فائل فارمیٹ سے متعین ہوتی ہے: JPEG کے لیے image/jpeg، PNG کے لیے image/png، GIF کے لیے image/gif، جدید WebP فارمیٹ کے لیے image/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 صفحات منٹ یا سیکنڈ کے لیے کیش کیے جاتے ہیں۔ Cloudflare اور Akamai جیسے CDN سرورز کمپریشن الگورتھم منتخب کرنے کے لیے Content-Type استعمال کرتے ہیں: text/* کو gzip یا brotli سے کمپریس کیا جاتا ہے، image/* کو نہیں، کیونکہ تصاویر پہلے سے کمپریسڈ ہوتی ہیں۔ سرور پر درست Content-Type ترتیب براہ راست ویب صفحات اور موبائل ایپلیکیشنز کی لوڈنگ کارکردگی کو متاثر کرتی ہے۔

سرور اور کلائنٹ Content-Type کو کیسے استعمال کرتے ہیں

سرور درخواست کردہ فائل کی قسم یا متحرک طور پر تخلیق کردہ مواد کی بنیاد پر HTTP جواب میں Content-Type ہیڈر مرتب کرتا ہے۔ مشہور ویب سرورز جیسے Nginx اور Apache میں بلٹ ان MIME قسم کی میزیں ہوتی ہیں جو فائل ایکسٹینشن کو متعلقہ Content-Type سے ملاتی ہیں۔ مثال کے طور پر، index.html کو text/html ملتا ہے اور style.css کو text/css ملتا ہے۔ متحرک جوابات کے لیے، ڈویلپر PHP، Python، Java یا Kotlin میں ایپلیکیشن کوڈ میں Content-Type مرتب کرتا ہے۔

کلائنٹ ایک ہینڈلر منتخب کرنے کے لیے 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 کلائنٹس کے ذریعے ہینڈل کیا جاتا ہے۔ Android پر OkHttp خود بخود جواب سے Content-Type ہیڈر کو پارس کرتا ہے اور Response.header("Content-Type") طریقہ کے ذریعے فراہم کرتا ہے۔ iOS URLSession کلائنٹ URLResponse.mimeType پراپرٹی کے ذریعے ایسا ہی کرتا ہے۔ دونوں پلیٹ فارمز پر، Content-Type ایک پارسر منتخب کرنے کے لیے استعمال ہوتا ہے: JSON — Android پر Moshi یا Gson کے ذریعے، iOS پر Codable کے ذریعے؛ تصاویر — 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 جوابات دونوں میں استعمال ہوتا ہے۔ درخواستوں میں، یہ درخواست کے جسم کی فارمیٹ متعین کرتا ہے، مثال کے طور پر POST کے ذریعے JSON بھیجتے وقت۔ جوابات میں، یہ لوٹائے گئے ڈیٹا کی فارمیٹ متعین کرتا ہے۔ بنیادی فرق یہ ہے کہ درخواست کا Content-Type کلائنٹ مرتب کرتا ہے، جبکہ جواب کا Content-Type سرور مرتب کرتا ہے۔ درخواست میں Content-Type کو غلط طریقے سے مرتب کرنا سرور کو جسم کو پارس کرنے سے قاصر کر دیتا ہے، جو 400 Bad Request یا 415 Unsupported Media Type کی خرابی لوٹاتا ہے۔

HTTP درخواستوں میں، Content-Type POST، PUT اور PATCH طریقوں کے لیے لازمی ہے اگر درخواست میں جسم ہو۔ GET، HEAD اور DELETE عام طور پر جسم استعمال نہیں کرتے، لہذا ان کے لیے Content-Type متعین نہیں کیا جاتا یا نظرانداز کیا جاتا ہے۔ enctype="multipart/form-data" وصف کے ساتھ HTML فارم جمع کراتے وقت، براؤزر خود بخود 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}")
    }
}

موبائل HTTP کلائنٹس میں Content-Type

موبائل ڈویلپمنٹ میں، Content-Type ہیڈر HTTP کلائنٹس کے ذریعے خود بخود ہینڈل کیا جاتا ہے۔ Android پر OkHttp میں، Content-Type RequestBody کے ذریعے مرتب کیا جاتا ہے: val body = "{}".toRequestBody("application/json".toMediaType())۔ Retrofit تشریحات کے ذریعے Content-Type کا انتظام کرتا ہے: JSON کے لیے @Body، ملٹی پارٹ کے لیے @Part۔ iOS پر، URLSession HTTPBody کے لیے Content-Type مرتب کرتا ہے اور Alamofire اسے encoding پیرامیٹر کے ذریعے کرتا ہے: JSONEncoding.default یا URLEncoding.default۔ دستی Content-Type ترتیب خام ساکٹ یا کسٹم پروٹوکول کے ساتھ کام کرتے وقت ضروری ہے۔

Content-Type کی غلطیاں

غلط Content-Type ویب سروس کی ترقی اور انضمام میں سب سے عام مسائل میں سے ایک ہے۔ سب سے عام غلطی یہ ہے جب سرور application/json کے بجائے text/html لوٹاتا ہے۔ کلائنٹ JSON کو HTML سٹرنگ کے طور پر وصول کرتا ہے، اسے پارس نہیں کر سکتا اور ایک استثناء پھینکتا ہے۔ یہ اس وقت ہوتا ہے جب ویب فریم ورک ڈیفالٹ طور پر HTML کے لیے ترتیب دیا گیا ہو اور ڈویلپر API اینڈ پوائنٹس کے لیے Content-Type کو اووررائڈ کرنا بھول جاتا ہے۔ 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 متعین کرتا ہے۔ حل یہ ہے کہ سرور ترتیب میں ٹیکسٹ MIME اقسام کے لیے ہمیشہ واضح طور پر charset=utf-8 متعین کریں۔

تیسرا مسئلہ Content-Type کا اصل مواد سے عدم مطابقت ہے۔ اگر سرور Content-Type: image/png بھیجتا ہے لیکن جواب کے جسم میں WebP تصویر ہے، تو براؤزر اسے ڈی کوڈ نہیں کر سکتا۔ CDN سرورز کبھی کبھی فارمیٹ تبدیل کرکے تصاویر کو کمپریس کرتے ہیں لیکن Content-Type ہیڈر کو اپ ڈیٹ نہیں کرتے۔ اصل مواد کے ساتھ Content-Type کی مطابقت کی جانچ API ٹیسٹنگ اور موبائل ایپلیکیشنز کے انٹیگریشن ٹیسٹنگ میں ایک لازمی مرحلہ ہے۔

Content-Type کی غلطیوں کی تشخیص اور اصلاح

ڈیبگنگ کے لیے، براؤزر ڈویلپر ٹولز (Network ٹیب)، جوابی ہیڈر چیک کرنے کے لیے -I فلیگ کے ساتھ curl، یا Charles Proxy اور Wireshark جیسے ٹریفک سنیفرز استعمال کریں۔ Nginx include mime.types ہدایت کے ذریعے ترتیب دیا جاتا ہے، Apache — AddType اور AddDefaultCharset کے ذریعے۔ جامد فائلوں کے لیے، ہمیشہ چیک کریں کہ فائل ایکسٹینشن اس کی MIME قسم سے ملتی ہے۔ تمام پروگرامنگ زبانوں میں متحرک جوابات کے لیے، ڈیٹا آؤٹ پٹ کرنے سے پہلے واضح طور پر Content-Type مرتب کریں — یہ زیادہ تر مسائل کو روکتا ہے۔