براؤزر میں لوکل فائل پروسیسنگ کیسے کام کرتی ہے
اگر کچھ اپ لوڈ ہی نہیں ہوتا تو کام آخر کر کون رہا ہے، اور کہاں؟
یہاں “لوکل” کا مطلب کیا ہے
روایتی آن لائن کنورٹر دراصل ایک ویب سائٹ ہوتی ہے جس کے پاس اپ لوڈ کا اینڈ پوائنٹ ہوتا ہے۔ آپ کی فائل ایسی مشین تک بھیجی جاتی ہے جو آپ کے قابو میں نہیں، وہیں اس پر کام ہوتا ہے، کچھ عرصے کے لیے وہیں محفوظ رہتی ہے، اور پھر ڈاؤن لوڈ کے طور پر واپس پیش کر دی جاتی ہے۔ لوکل پروسیسنگ اس جملے کا درمیانی حصہ ہٹا دیتی ہے: آپ کی فائل پڑھنے والا کوڈ اُسی براؤزر ٹیب کے اندر چلتا ہے جو پہلے سے کھلا ہے، آپ ہی کے پروسیسر پر، اور نتیجہ واپس آپ ہی کی ڈسک پر لکھا جاتا ہے۔
سائٹ پھر بھی نیٹ ورک ہی سے آتی ہے — HTML، اسٹائل شیٹس، اسکرپٹس اور WebAssembly ماڈیول سب کسی بھی ویب صفحے کی طرح سرور سے آتے ہیں۔ فرق سمت کا ہے۔ پروگرام کا کوڈ نیچے آتا ہے؛ آپ کی فائل اوپر نہیں جاتی۔
پرزے براؤزر میں پہلے سے موجود ہیں
| فیچر | یہ کیا فراہم کرتا ہے |
|---|---|
| File اور Blob APIs | صارف کی منتخب کی ہوئی یا ڈراپ کی ہوئی فائل کے بائٹس فارم جمع کرائے بغیر پڑھنا |
| Web Workers | بھاری کام بیک گراؤنڈ تھریڈ پر چلانا تاکہ انٹرفیس جواب دیتا رہے |
| WebAssembly | کمپائل شدہ C، C++ یا Rust کوڈیک لائبریریوں کو تقریباً نیٹو رفتار پر چلانا |
| Canvas اور OffscreenCanvas | تصاویر کو ڈی کوڈ کرنا، بنانا، سائز بدلنا اور دوبارہ اینکوڈ کرنا |
| WebCodecs | براؤزر کے اپنے، ہارڈویئر سے تیز کیے گئے ویڈیو اینکوڈرز اور ڈی کوڈرز تک پہنچنا |
| WebGPU | ماڈل انفرنس اور متوازی پکسل کام گرافکس پروسیسر پر چلانا |
| File System Access | جہاں سپورٹ ہو، نتیجہ سیدھا اُس جگہ لکھنا جو صارف خود چنتا ہے |
اس میں کچھ بھی انوکھا نہیں۔ یہ وہی پلیٹ فارم ہے جو ایک ٹیب کے اندر اسپریڈ شیٹس، ڈیزائن ٹولز اور گیمز چلاتا ہے۔ غیر معمولی فیصلہ صرف ایک ہے: اس کے ساتھ سرور جوڑنے سے انکار۔
فائل کا راستہ
- آپ ایک فائل چنتے ہیں۔ براؤزر صفحے کو اس کا ہینڈل تھما دیتا ہے — نقل نہیں، صرف ایک حوالہ۔
- صفحہ پہلے چند بائٹس پڑھ کر فائل کی اصل قسم اُس کے سگنیچر سے پہچانتا ہے، ایکسٹینشن پر بھروسا کرنے کے بجائے۔
- یہ اندازہ لگاتا ہے کہ کام کو کتنی میموری درکار ہوگی، اور اگر یہ اُس سے بڑھ جائے جو ڈیوائس محفوظ طریقے سے دے سکتی ہے تو کام سے انکار کر دیتا ہے یا اسے قطار میں ڈال دیتا ہے۔
- بائٹس ایک Web Worker میں منتقل کیے جاتے ہیں۔ ArrayBuffer منتقل کرنے سے ملکیت بدلتی ہے، نقل نہیں بنتی، اس لیے بڑی فائل میموری میں دو بار موجود نہیں ہوتی۔
- ورکر کے اندر ایک WebAssembly کوڈیک یا کوئی پلیٹ فارم API اصل ڈی کوڈنگ اور اینکوڈنگ کرتی ہے۔
- نتیجہ بائٹس کی صورت واپس آتا ہے، ایک Blob میں لپیٹا جاتا ہے، اور آپ کو ڈاؤن لوڈ کے طور پر پیش کیا جاتا ہے یا آپ کی چنی ہوئی جگہ پر لکھ دیا جاتا ہے۔
- اُس Blob کا عارضی URL منسوخ کر دیا جاتا ہے اور بفرز آزاد کر دیے جاتے ہیں۔
اصل تبدیلی WebAssembly سے کیوں آئی
امیج اور ویڈیو کوڈیک دہائیوں کی محنت سے بہتر بنائی گئی C ہیں۔ انہیں JavaScript میں دوبارہ لکھنا کبھی حقیقت پسندانہ نہیں تھا۔ WebAssembly ایک پورٹیبل بائنری انسٹرکشن فارمیٹ ہے جسے براؤزر سینڈ باکس کے اندر نیٹو کوڈ کے قریب رفتار سے چلاتے ہیں، یعنی وہ موجودہ لائبریریاں جوں کی توں کمپائل ہو کر براؤزر تک پہنچائی جا سکتی ہیں۔
سینڈ باکس رفتار جتنا ہی اہم ہے۔ WebAssembly ماڈیول کو آپ کے فائل سسٹم، آپ کے نیٹ ورک یا آپ کے دوسرے ٹیبز تک خودبخود کوئی رسائی نہیں ہوتی۔ اسے صرف وہی میموری نظر آتی ہے جو صفحہ اسے دیتا ہے، اس کے سوا کچھ نہیں۔ کوئی بدنیت یا محض خراب کوڈیک بھٹک کر ایسی چیز نہیں پڑھ سکتا جو اسے دی ہی نہیں گئی۔
نیٹ ورک سے اب بھی کیا گزرتا ہے، اور وہ آپ کی فائل کیوں نہیں
نیٹ ورک سے تین چیزیں آتی ہیں: خود صفحہ، آپ کے کھولے ہوئے ٹول کا انجن، اور — بیک گراؤنڈ ہٹانے کے لیے — ماڈل ویٹس۔ تینوں FileSlimmer کے اپنے اسٹیٹک اثاثے ہیں، جو آپ کا کوئی بھی بائٹ پڑھے جانے سے پہلے FileSlimmer ہی کے اوریجن سے لیے جاتے ہیں۔ یہ ڈاؤن لوڈ ہیں، کیش ہو سکتے ہیں، اور پہلی بار استعمال کے بعد براؤزر کے اپنے کیش سے، بغیر کسی نیٹ ورک کے، مل جاتے ہیں۔
اس مقام کے بعد سب کچھ لوکل ہے۔ انجنوں کو فائل کے بائٹس صرف صفحے کی جانب سے postMessage کے ذریعے ملتے ہیں؛ انہیں کبھی کوئی ایسا URL نہیں دیا جاتا جہاں وہ کچھ بھیج سکیں، اور کنٹینٹ سیکیورٹی پالیسی یہ محدود کر دیتی ہے کہ صفحہ کہاں رابطہ کر سکتا ہے، چاہے کوئی کوڈ کوشش ہی کیوں نہ کرے۔
لین دین، صاف الفاظ میں
| پہلو | آپ کے براؤزر میں | سرور پر |
|---|---|---|
| آپ کی فائل کہاں جاتی ہے | کہیں نہیں | ایسی مشین پر جو آپ کے قابو میں نہیں |
| رفتار | جتنی آپ کی ڈیوائس دے سکے | جتنی آپریٹر نے خرید رکھی ہے |
| بہت بڑی فائلیں | براؤزر کی میموری تک محدود | آپریٹر کی مقرر کردہ حدود تک محدود |
| آف لائن چلتا ہے | انجن ایک بار کیش ہو جائے تو ہاں | نہیں |
| غیر معمولی فارمیٹس | صرف وہی جو WebAssembly میں کمپائل ہو سکیں | جو کچھ بھی آپریٹر انسٹال کر دے |
| ہزار فائلوں کا بیچ | ڈیوائس کی حد میں بندھا ہوا | عام طور پر زیادہ موزوں |
لوکل پروسیسنگ ہر حال میں بہتر نہیں۔ یہ تب بہتر ہے جب فائل نجی ہو، ڈیوائس سکت رکھتی ہو، اور کام میموری میں سما جائے۔ سرور تب بہتر ہے جب آپ کو اتنا کچھ پروسیس کرنا ہو جو ایک مشین میں سما ہی نہ سکے۔ یہ سمجھ لینا کہ آپ کس صورتحال میں ہیں، اس ضد سے کہیں زیادہ کارآمد ہے کہ کوئی ایک طریقہ ہر جگہ جیتتا ہے۔
یہ کس بات کا دعویٰ نہیں کرتا
یہ بیان صرف اس بارے میں ہے کہ یہ ایپلیکیشن کیا کرتی ہے۔ یہ آپ کی براؤزر ایکسٹینشنز کے بارے میں دعویٰ نہیں، جو آپ کے کھولے ہوئے کسی بھی صفحے کا مواد پڑھ سکتی ہیں؛ نہ آپ کے آپریٹنگ سسٹم کے بارے میں، جو آپ کی چھوئی ہوئی ہر فائل دیکھ سکتا ہے؛ اور نہ آپ کے نیٹ ورک آپریٹر کے بارے میں، جو یہ دیکھ سکتا ہے کہ آپ نے کون سی سائٹ کھولی۔ یہ سب کسی بھی ویب سائٹ کی پہنچ سے باہر ہیں، اور جو ٹول آپ کو اس کے برعکس بتائے وہ اپنی بات بڑھا چڑھا کر کہہ رہا ہے۔
دعویٰ محدود بھی ہے اور جانچنے کے قابل بھی: آپ کی منتخب کردہ فائلیں اسی براؤزر میں لوکلی پروسیس ہوتی ہیں اور FileSlimmer انہیں اپ لوڈ نہیں کرتا۔ اگلا گائیڈ بتاتا ہے کہ اس پر یقین کرنے کے بجائے خود اس کی تصدیق کیسے کی جائے۔
اس کام کے ٹولز
مآخذ
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs