ویب ڈویلپمنٹ میں Multipart Upload: جوہر، ساخت اور multipart/form-data کیسے کام کرتا ہے

Multipart Upload کیا ہے؟

Multipart Upload HTTP پروٹوکول کے ذریعے ڈیٹا کی منتقلی کا ایک طریقہ ہے جس میں درخواست کا باڈی کئی منطقی طور پر الگ کیے گئے حصوں پر مشتمل ہوتا ہے۔ ہر حصہ مختلف قسم کا ڈیٹا رکھ سکتا ہے: ایک ٹیکسٹ فارم فیلڈ، ایک بائنری فائل، ایک JSON آبجیکٹ یا ایک تصویر۔ تمام حصوں کو ایک ہی POST درخواست میں پیک کیا جاتا ہے، جس سے N علیحدہ HTTP کالز بھیجنے کی ضرورت ختم ہو جاتی ہے۔ Multipart Upload ویب فارمز اور فائل اپ لوڈ APIs کا ایک لازمی حصہ ہے۔

ملٹی پارٹ فارمیٹ کو ای میل پیغامات کے لیے MIME معیار کے حصے کے طور پر RFC 2046 تصریح میں بیان کیا گیا تھا، اور بعد میں RFC 1867 میں HTTP کے لیے ڈھال لیا گیا۔ آج، ویب ڈویلپمنٹ تقریباً خصوصی طور پر multipart/form-data استعمال کرتی ہے — فائلوں پر مشتمل فارمز کے لیے ڈیزائن کردہ ملٹی پارٹ ذیلی قسموں میں سے ایک۔ دیگر ذیلی اقسام — multipart/mixed (صوابدیدی منسلکات کے لیے) اور multipart/byteranges (فائلوں کے جزوی ڈاؤن لوڈ کے لیے) — بہت کم استعمال ہوتی ہیں۔

ملٹی پارٹ اور سادہ application/x-www-form-urlencoded کے درمیان بنیادی فرق یہ ہے کہ مؤخر الذکر تمام ڈیٹا کو URI کے مطابق سٹرنگ میں کوڈ کرتا ہے اور بائنری فائلوں کو سپورٹ نہیں کرتا۔ دوسری طرف، Multipart/form-data ہر فائل کو بغیر کوڈنگ کے اس کی اصل بائنری شکل میں منتقل کرتا ہے، جو زیادہ موثر ہے اور درستگی نہیں کھوتا۔ درخواست کا سائز ملٹی پارٹ کے ساتھ حصوں کے ہیڈرز اور حدود کے اوور ہیڈ کی وجہ سے فائل کے سائز کے مجموعے سے ہمیشہ 5-15% بڑا ہوتا ہے۔

Multipart Upload کب استعمال ہوتا ہے

Multipart Upload ہر جگہ استعمال ہوتا ہے جہاں فائل اپ لوڈ کی ضرورت ہو: سوشل نیٹ ورکس میں اوتار اور پروفائل تصویریں، میسنجر میں منسلکات، CRM سسٹمز میں دستاویزات، آن لائن سٹورز میں پروڈکٹ کی تصاویر۔ موبائل ایپلیکیشنز میں، Multipart Upload میڈیا فائلوں کو سرور کو بھیجنے کے لیے استعمال ہوتا ہے — ڈیوائس کیمرے سے تصاویر، وائس ریکارڈنگز، ویڈیو کلپس۔ Cloudflare Research کے مطابق، ویب پر تقریباً 15% تمام POST درخواستیں multipart/form-data استعمال کرتی ہیں۔

ملٹی پارٹ اور چنکڈ ٹرانسفر کے درمیان فرق

Multipart Upload اور Chunked Transfer مختلف طریقہ کار ہیں۔ ملٹی پارٹ ایک درخواست کو بامعنی حصوں (فیلڈز اور فائلوں) میں تقسیم کرتا ہے، جبکہ چنکڈ ٹرانسفر کل سائز جانے بغیر منتقلی کے لیے ڈیٹا سٹریم کو ٹکڑوں میں تقسیم کرتا ہے۔ ملٹی پارٹ چنکڈ ٹرانسفر کے اندر منتقل کیا جا سکتا ہے: سرور اپنا مکمل سائز جانے بغیر ملٹی پارٹ جواب حصوں میں بھیجتا ہے۔ یہ طریقہ کار متصادم نہیں ہوتے اور مختلف سطحوں پر مختلف مسائل حل کرتے ہیں۔

multipart/form-data کیسے کام کرتا ہے

جب براؤزر enctype="multipart/form-data" وصف کے ساتھ فارم جمع کراتا ہے، تو یہ درخواست کا باڈی ملٹی پارٹ فارمیٹ میں بناتا ہے۔ ہر فارم فیلڈ ایک علیحدہ بلاک بن جاتا ہے، جو ایک حد بندی (boundary) کے ذریعے دوسروں سے الگ کیا جاتا ہے۔ حد بندی خودکار طور پر تیار ہوتی ہے اور حروف کا ایک منفرد سلسلہ ہے جو ڈیٹا کے اندر نہ آنے کی ضمانت دیتا ہے۔ کلائنٹ اس حد بندی کو Content-Type ہیڈر میں شامل کرتا ہے: multipart/form-data; boundary=----WebKitFormBoundaryX7K۔

ہر بلاک --boundary سے شروع ہوتا ہے اور فیلڈ کا نام (name) اور فائلوں کے لیے اصل فائل نام (filename) کے ساتھ Content-Disposition ہیڈر پر مشتمل ہوتا ہے۔ خالی لائن کے بعد اصل فیلڈ ڈیٹا یا بائنری شکل میں فائل کا مواد آتا ہے۔ درخواست سٹرنگ --boundary-- کے ساتھ ختم ہوتی ہے۔ سرور موصولہ سٹریم کو پارس کرتا ہے: پہلے حد بندی ڈھونڈتا ہے، پھر ہر حصے کے ہیڈر نکالتا ہے، ڈیٹا کی قسم کا تعین کرتا ہے اور انہیں فارم ہینڈلر یا API کنٹرولر کو بھیجتا ہے۔

IETF RFC 7578 کے مطابق، multipart/form-data کو ہر حصے کے لیے charset متعین کرنے کی ضرورت نہیں ہے، کیونکہ ٹیکسٹ فیلڈز UTF-8 میں سمجھی جاتی ہیں اور بائنری حصوں میں فائلیں اپنی اصل انکوڈنگ میں ہوتی ہیں۔ ایک حصے کا سائز پروٹوکول کے ذریعے محدود نہیں ہے — حدود سرور کی سطح پر متعین کی جاتی ہیں: مثال کے طور پر، Nginx میں client_max_body_size کے ذریعے، Spring Boot میں spring.servlet.multipart.max-file-size کے ذریعے۔

Boundary کی شکل اور اس کی تخلیق

Boundary ایک منفرد سٹرنگ ہے جو منتقل کردہ ڈیٹا میں ظاہر نہیں ہونی چاہیے۔ یہ عام طور پر ایک سابقہ (مثلاً ----WebKitFormBoundary یا ----Boundary) سے شروع ہوتی ہے اور بے ترتیب حروف پر مشتمل ہوتی ہے۔ براؤزر اور HTTP کلائنٹ خود بخود boundary تخلیق کرتے ہیں۔ RFC 2046 کے مطابق boundary کی لمبائی 70 حروف سے زیادہ نہیں ہونی چاہیے۔ ہر حصہ سٹرنگ --boundary\r\n سے الگ کیا جاتا ہے، اور درخواست کا اختتام --boundary--\r\n سے نشان زد کیا جاتا ہے۔

ملٹی پارٹ درخواست کی ساخت

ملٹی پارٹ درخواست کی MIME اور HTTP معیارات کے ذریعے متعین کردہ سخت ساخت ہوتی ہے۔ درخواست ہیڈر boundary پیرامیٹر کے ساتھ Content-Type: multipart/form-data سیٹ کرتا ہے۔ درخواست کا باڈی حصوں کے سلسلے پر مشتمل ہوتا ہے، ہر ایک کے اپنے ہیڈر اور باڈی ہوتے ہیں۔ حصے کے ہیڈر میں Content-Disposition (لازمی) اور Content-Type (اختیاری — فائلوں کے لیے) شامل ہیں۔ حصے کے ہیڈر اور اس کے ڈیٹا کے درمیان خالی لائن لازمی ہے۔

ملٹی پارٹ درخواست کی مثال

ایک ٹیکسٹ فیلڈ اور ایک تصویری فائل بھیجنے والی ملٹی پارٹ درخواست کی حقیقی مثال پر غور کریں۔ کلائنٹ ایک منفرد boundary کے ساتھ Content-Type ہیڈر بناتا ہے۔ درخواست کا باڈی ترتیب وار تمام فارم فیلڈز پر مشتمل ہوتا ہے۔ وصول کرنے پر، سرور ان حصوں کو پارس کرتا ہے اور ڈویلپر کو ہر فیلڈ تک علیحدہ آبجیکٹ کے طور پر رسائی فراہم کرتا ہے۔ یہ طریقہ ایک ہی HTTP کال میں فائلوں کے ساتھ پیچیدہ فارمز پر کارروائی کرنے کی اجازت دیتا ہے۔

import okhttp3.*
import java.io.File

fun uploadFile() {
    val client = OkHttpClient()
    val imageFile = File("/path/to/photo.jpg")

    val requestBody = MultipartBody.Builder()
        .setType(MediaType.parse("multipart/form-data"))
        .addFormDataPart("username", "john_doe")
        .addFormDataPart(
            "avatar", "photo.jpg",
            RequestBody.create(
                MediaType.parse("image/jpeg"), imageFile
            )
        )
        .build()

    val request = Request.Builder()
        .url("https://api.example.com/upload")
        .post(requestBody)
        .build()

    client.newCall(request).execute().use { response ->
        println("اپ لوڈ ہو گیا: ${response.isSuccessful}")
    }
}

سرور پر ملٹی پارٹ جواب کا تجزیہ

سرور کی طرف، ملٹی پارٹ درخواست فریم ورک کے ذریعے یا دستی طور پر پارس کی جاتی ہے۔ Spring Boot میں، @RequestParam("avatar") MultipartFile file اینوٹیشن کافی ہے، اور فریم ورک خود بخود ملٹی پارٹ درخواست سے فائل نکالتا ہے۔ Kotlin میں Ktor میں receiveMultipart() استعمال ہوتا ہے، Express.js میں — multer مڈل ویئر۔ سرور ہر فارم فیلڈ اور ہر اپ لوڈ کردہ فائل تک آزادانہ رسائی حاصل کرتا ہے، فائل کو ڈسک یا کلاؤڈ سٹوریج میں محفوظ کرتا ہے اور کلائنٹ کو URL یا شناخت کنندہ لوٹاتا ہے۔

کثیر اجزائی اپ لوڈ کے فوائد

Multipart Upload ڈیٹا کی منتقلی کے متبادل طریقوں کے مقابلے میں کئی اہم فوائد فراہم کرتا ہے۔ ایک درخواست بجائے متعدد کے — تمام فارم فیلڈز اور فائلیں ایک ہی HTTP کال میں منتقل ہوتی ہیں، جس سے نیٹ ورک اور سرور کا بوجھ کم ہوتا ہے۔ N فائلیں اپ لوڈ کرنے کے لیے N کنکشن کھولنے کی ضرورت نہیں ہے — سب کچھ ایک POST میں پیک کیا جاتا ہے۔ یہ خاص طور پر موبائل ایپلیکیشنز کے لیے اہم ہے، جہاں ہر HTTP کنکشن کا مطلب تاخیر اور بیٹری کی کھپت ہے۔

بغیر انکوڈنگ کے بائنری منتقلی — application/x-www-form-urlencoded کے برعکس، جہاں بائنری ڈیٹا base64 میں انکوڈ ہوتا ہے (سائز میں 33% اضافہ)، multipart/form-data فائلوں کو ان کی اصل بائنری شکل میں منتقل کرتا ہے۔ یہ سائز اور رفتار میں زیادہ موثر ہے۔ 10 MB سے بڑی فائلوں کے لیے، فرق اہم ہو جاتا ہے: ایک ملٹی پارٹ درخواست اسی فائل کے ساتھ URL انکوڈڈ درخواست سے 30% چھوٹی ہوگی۔

صوابدیدی ساخت — ملٹی پارٹ مختلف اقسام کے فیلڈز کو کسی بھی ترتیب میں یکجا کرنے کی اجازت دیتا ہے۔ ایک فارم میں ایک ساتھ ٹیکسٹ فیلڈز، متعدد فائلیں، JSON ڈیٹا اور پوشیدہ فیلڈز ہو سکتے ہیں۔ ہر حصہ کا اپنا Content-Type ہوتا ہے، جو ٹیکسٹ اور بائنری ڈیٹا کو ملانے کی اجازت دیتا ہے۔ موازنہ کے لیے: base64 انکوڈنگ سائز میں 33% اضافہ کرتی ہے، جبکہ ملٹی پارٹ سروس ہیڈرز کے لیے صرف تقریباً 5-15% اضافہ کرتا ہے۔

ملٹی پارٹ کا دیگر منتقلی فارمیٹس سے موازنہ

HTTP Archive، 2025 کی تحقیق کے مطابق، ویب پر 94% فائل اپ لوڈ کیسز میں multipart/form-data استعمال ہوتا ہے۔ متبادل — JSON میں base64 (4%) اور WebSocket کے ذریعے براہ راست منتقلی (2%)۔ JSON کے ساتھ base64 APIs کے لیے آسان ہے جہاں دیگر تمام ڈیٹا بھی JSON میں ہے، لیکن بڑی فائلوں کے لیے ناکارہ ہے۔ WebSocket ریئل ٹائم ڈیٹا کے لیے موزوں ہے لیکن تمام HTTP انفراسٹرکچر کے ذریعے تعاون یافتہ نہیں ہے۔ ملٹی پارٹ اپنی سادگی اور کارکردگی کی وجہ سے فائل اپ لوڈ کے لیے معیاری بنا ہوا ہے۔

موبائل ڈویلپمنٹ میں Multipart Upload

موبائل ایپلیکیشنز میں، Multipart Upload صارفین کے آلات سے میڈیا مواد بھیجنے کے لیے استعمال ہوتا ہے: گیلری سے تصاویر، کیمرہ شاٹس، وائس ریکارڈنگز، دستاویزات کی فائلیں۔ Android پر، معیاری طریقہ MultipartBody.Builder کے ساتھ OkHttp ہے، جو ملٹی پارٹ درخواستیں آسانی سے بنانے کی اجازت دیتا ہے۔ Retrofit بھی @Multipart اور @Part اینوٹیشنز کے ذریعے ملٹی پارٹ کو سپورٹ کرتا ہے۔ ڈویلپر ہر حصے کے لیے ڈیٹا کی قسم متعین کرتا ہے، HTTP کلائنٹ خود بخود صحیح ہیڈر تیار کرتا ہے۔

iOS پر، اسی کاموں کو حسب ضرورت HTTPBodyStream کے ساتھ URLSession یا Alamofire کے ساتھ multipartFormData کے ذریعے حل کیا جاتا ہے۔ Alamofire ملٹی پارٹ درخواستیں بھیجنے کے لیے ایک آسان upload(multipartFormData:) طریقہ فراہم کرتا ہے۔ دونوں پلیٹ فارمز پر اپ لوڈ کردہ فائلوں کے سائز پر غور کرنا ضروری ہے — بڑی فائلوں (10-20 MB سے زیادہ) کے لیے، پس منظر میں اپ لوڈ استعمال کرنے کی سفارش کی جاتی ہے تاکہ چھوٹا کرنے پر ایپلیکیشن ختم نہ ہو۔ Android پر، یہ DownloadManager یا WorkManager کے ذریعے کیا جاتا ہے، iOS پر — پس منظر کی تشکیل کے ساتھ URLSession کے ذریعے۔

موبائل ایپلیکیشنز میں فائلیں اپ لوڈ کرتے وقت، نیٹ ورک کی حالت پر غور کرنا ضروری ہے۔ Android پر Connectivity Manager یہ تعین کرنے میں مدد کرتا ہے کہ Wi-Fi یا موبائل ڈیٹا دستیاب ہے اور اپ لوڈ کے لیے بہترین وقت منتخب کرتا ہے۔ ویڈیو جیسی بڑی فائلوں کے لیے، صارف کے موبائل ڈیٹا کو استعمال نہ کرنے کے لیے Wi-Fi سے منسلک ہونے تک اپ لوڈ ملتوی کرنے کی سفارش کی جاتی ہے۔ Android پر WorkManager NetworkType.UNMETERED کے ذریعے ایسی پابندیاں مرتب کرنے کی اجازت دیتا ہے۔

اپ لوڈ کی اصلاح: کمپریشن اور سائز تبدیل کرنا

Multipart Upload کے ذریعے فائل بھیجنے سے پہلے، موبائل ایپلیکیشنز اکثر تصویر کو کمپریس اور سائز تبدیل کرتی ہیں۔ JPEG کمپریشن 85% معیار کے ساتھ اسکرین پر دیکھنے کے لیے نمایاں معیار کے نقصان کے بغیر فائل کا سائز 3-5 گنا کم کر دیتا ہے۔ تصویر کو لمبی طرف 1920px تک ری سائز کرنے سے سائز مزید کم ہو جاتا ہے۔ Android پر، اس کے لیے Bitmap.compress() استعمال کیا جاتا ہے، iOS پر — 0.85 کے کمپریشن پیرامیٹر کے ساتھ UIImageJPEGRepresentation۔ اس طرح کی اصلاح اپ لوڈ کو تیز کرتی ہے اور موبائل ڈیٹا بچاتی ہے۔

Multipart Upload کی غلطیاں اور حدود

Multipart Upload میں سب سے عام غلطی سرور پر درخواست کے سائز کی حد سے تجاوز کرنا ہے۔ ڈیفالٹ طور پر، Nginx درخواست کے باڈی کے سائز کو 1 MB (client_max_body_size) اور Tomcat کو 2 MB (maxSwallowSize) تک محدود کرتا ہے۔ اگر ڈویلپر ان حدود میں اضافہ نہیں کرتا، تو سرور 413 Request Entity Too Large غلطی لوٹائے گا۔ حل یہ ہے کہ سرور پر زیادہ سے زیادہ اپ لوڈ سائز واضح طور پر ترتیب دیا جائے اور کلائنٹ پر انتباہ دکھایا جائے اگر فائل اجازت شدہ سائز سے تجاوز کرے۔

دوسرا مسئلہ باڈی سٹریمنگ کے دوران ملٹی پارٹ درخواستوں کی غلط پروسیسنگ ہے۔ کچھ سرور پارس کرنے سے پہلے پوری ملٹی پارٹ درخواست کو میموری میں لوڈ کرنے کی کوشش کرتے ہیں، جو بڑی فائلوں کے لیے OutOfMemoryError کا باعث بنتا ہے۔ جدید سرور (Nginx، Spring Boot، Ktor) سٹریمنگ ملٹی پارٹ پارسنگ کو سپورٹ کرتے ہیں، جہاں ہر حصہ آنے پر پروسیس ہوتا ہے۔ ڈویلپر کو یقینی بنانا چاہیے کہ سرور ملٹی پارٹ درخواستوں کی سٹریمنگ پروسیسنگ کے لیے ترتیب دیا گیا ہے۔

مسائل کا تیسرا زمرہ بڑی فائلیں اپ لوڈ کرتے وقت ٹائم آؤٹ ہے۔ HTTP کلائنٹس میں readTimeout اور connectTimeout کی ترتیبات ہوتی ہیں جو 50-100 MB سے بڑی فائلوں کے طویل اپ لوڈ کے دوران فعال ہو سکتی ہیں۔ حل یہ ہے کہ اپ لوڈ اینڈ پوائنٹس کے لیے ٹائم آؤٹ بڑھایا جائے یا ملٹی پارٹ کے اندر چنکڈ ٹرانسفر انکوڈنگ استعمال کی جائے۔ موبائل آلات پر، اپ لوڈ میں خلل کو سنبھالنا اور کنکشن منقطع ہونے پر دوبارہ شروع (resume) کرنا بھی ضروری ہے۔

Multipart Upload سیکیورٹی

فائل اپ لوڈ (ملٹی پارٹ کے ذریعے) ویب ایپلیکیشن کے سب سے کمزور اینڈ پوائنٹس میں سے ایک ہے۔ ایک حملہ آور image.jpg کا نام دے کر ایک قابل عمل اسکرپٹ اپ لوڈ کر سکتا ہے۔ سرور کو اپ لوڈ کردہ فائل کی MIME قسم کی تصدیق توسیع سے نہیں بلکہ مواد (میجک بائٹس) سے کرنی چاہیے، اجازت شدہ اقسام کو محدود کرنا چاہیے اور اینٹی وائرس سے فائلوں کو اسکین کرنا چاہیے۔ سفارش کی جاتی ہے کہ اپ لوڈ کردہ فائلوں کو ویب سرور کے document-root سے باہر محفوظ کیا جائے اور رسائی کے حقوق کی جانچ کے ساتھ علیحدہ کنٹرولر کے ذریعے فراہم کیا جائے۔