ब्राउझरमधली लोकल फाइल प्रोसेसिंग कशी चालते
काहीच अपलोड होत नसेल, तर मग काम प्रत्यक्षात करतं कोण — आणि कुठे?
इथे “लोकल” म्हणजे नेमकं काय
नेहमीचा ऑनलाइन कन्व्हर्टर म्हणजे अपलोड एंडपॉइंट असलेली एक वेबसाइट. तुमची फाइल तुमच्या नियंत्रणात नसलेल्या मशीनकडे पाठवली जाते, तिथे तिच्यावर प्रक्रिया होते, काही काळ ती साठवली जाते, आणि मग डाउनलोड म्हणून परत दिली जाते. लोकल प्रोसेसिंग या वाक्यातला मधला भागच काढून टाकते: तुमची फाइल वाचणारा कोड तुम्ही आधीच उघडलेल्या ब्राउझर टॅबमध्ये, तुमच्याच प्रोसेसरवर चालतो, आणि निकाल तुमच्याच डिस्कवर लिहिला जातो.
साइट अजूनही नेटवर्कवरूनच आणली जाते — HTML, स्टाइलशीट, स्क्रिप्ट आणि WebAssembly मॉड्यूल हे सगळं इतर कोणत्याही वेब पेजप्रमाणे सर्व्हरवरूनच येतं. फरक दिशेचा आहे. प्रोग्रामचा कोड खाली येतो; तुमची फाइल वर जात नाही.
लागणारे सुटे भाग ब्राउझरमध्ये आधीपासूनच आहेत
| वैशिष्ट्य | ते काय पुरवतं |
|---|---|
| File आणि Blob API | फॉर्म सबमिट न करता वापरकर्त्याने निवडलेल्या किंवा ड्रॅग करून टाकलेल्या फाइलचे बाइट्स वाचणं |
| 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 दिली जात नाही, आणि एखाद्या कोडने प्रयत्न केलाच तरी पेज कुठे कनेक्ट होऊ शकतं यावर content security policy बंधन घालते.
तडजोडी, स्पष्ट शब्दांत
| मुद्दा | तुमच्या ब्राउझरमध्ये | सर्व्हरवर |
|---|---|---|
| तुमची फाइल कुठे जाते | कुठेही नाही | तुमच्या नियंत्रणात नसलेल्या मशीनकडे |
| वेग | तुमचं डिव्हाइस जेवढं करू शकेल तेवढा | ऑपरेटरने जेवढ्याचे पैसे भरले असतील तेवढा |
| खूप मोठ्या फाइल | ब्राउझरच्या मेमरीने मर्यादित | ऑपरेटरने घातलेल्या मर्यादांनी मर्यादित |
| ऑफलाइन चालतं का | इंजिन एकदा कॅश झालं की हो | नाही |
| दुर्मीळ फॉरमॅट | फक्त जे WebAssembly मध्ये कंपाइल होतात तेवढेच | ऑपरेटर जे इन्स्टॉल करेल ते सगळे |
| हजार फाइलचा बॅच | डिव्हाइसच्या मर्यादेत अडकतो | सहसा यासाठी अधिक योग्य |
लोकल प्रोसेसिंग सगळ्याच बाबतीत सरस नाही. फाइल खासगी असेल, डिव्हाइस सक्षम असेल आणि काम मेमरीत बसत असेल तेव्हा ती सरस ठरते. एका मशीनमध्ये मावणार नाही एवढं काम करायचं असेल तेव्हा सर्व्हर चांगला. कोणता तरी एक मार्ग सगळीकडे जिंकतो असा हट्ट धरण्यापेक्षा आपण नेमक्या कोणत्या परिस्थितीत आहोत हे स्पष्ट असणं जास्त उपयोगी.
याचा दावा काय नाही
हे विधान या ॲप्लिकेशनच्या वर्तनाबद्दल आहे. तुम्ही उघडलेल्या कोणत्याही पेजचा मजकूर वाचू शकणाऱ्या तुमच्या ब्राउझर एक्स्टेन्शनबद्दलचा हा दावा नाही, तुम्ही हाताळलेली कोणतीही फाइल तपासू शकणाऱ्या तुमच्या ऑपरेटिंग सिस्टिमबद्दलचाही नाही, आणि तुम्ही एखाद्या साइटला भेट दिली हे पाहू शकणाऱ्या तुमच्या नेटवर्क ऑपरेटरबद्दलचाही नाही. या गोष्टी कोणत्याही वेबसाइटच्या आवाक्याबाहेर आहेत, आणि याहून वेगळं सांगणारं टूल स्वतःचा दावा फुगवून सांगत आहे.
दावा मर्यादित आहे आणि तपासून पाहता येण्याजोगा आहे: तुम्ही निवडलेल्या फाइल याच ब्राउझरमध्ये लोकल पातळीवर प्रोसेस होतात आणि FileSlimmer त्या अपलोड करत नाही. यावर नुसता विश्वास ठेवण्याऐवजी त्याची खात्री स्वतः कशी करून घ्यायची, हे पुढचं मार्गदर्शक सांगतं.
यासाठीची टूल्स
स्रोत
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs