प्रॉम्प्ट और दायरा
आपको ब्राउज़र में बड़ी फ़ाइलें अपलोड करनी होंगी और एक डाइजेस्ट की गणना करनी होगी। नए ब्राउज़र Blob.bytes() का समर्थन करते हैं, लेकिन पुराने ब्राउज़र शायद न करें। रीडिंग, चंकिंग, फ़ॉलबैक, रद्दीकरण (cancellation), एरर हैंडलिंग और कम्पैटिबिलिटी वैलिडेशन डिज़ाइन करें।
MDN ने Blob.bytes() को Baseline 2026 के रूप में चिह्नित किया है: यह एक Promise लौटाता है जो Blob डेटा वाले Uint8Array में रिज़ॉल्व होता है और Web Workers में उपलब्ध है। इंटरव्यू में API सेमेंटिक्स और रिसोर्स सीमाओं का परीक्षण किया जाता है; केवल एक नए मेथड का समर्थन करना एक पूर्ण अपलोड डिज़ाइन नहीं है।
इंटरव्यूअर क्या मूल्यांकन करता है
- Promise और
Uint8Arrayपरिणाम को स्ट्रीम कहे बिना सटीक रूप से समझाना। - पूरे Blob को पढ़ने के मेमोरी पीक को पहचानना और चंक्स या एक स्ट्रीम पाथ डिज़ाइन करना।
- ब्राउज़र-नाम की जांच के बजाय
arrayBuffer()याstream()फ़ॉलबैक के साथ फ़ीचर डिटेक्शन का उपयोग करना। - रद्दीकरण, पुनः प्रयास (retries), डाइजेस्ट स्थिति, वर्कर मैसेजिंग और उपयोगकर्ता फ़ीडबैक को संभालना।
- एक कम्पैटिबिलिटी मैट्रिक्स और बड़ी फ़ाइलों के स्ट्रेस टेस्ट के साथ डिज़ाइन को साबित करना।
स्पष्टीकरण प्रश्न
- फ़ाइल-आकार की सीमाएं, अपलोड समवर्तीता (concurrency), लक्षित ब्राउज़र और Worker की उपलब्धता क्या हैं?
- कौन सा डाइजेस्ट एल्गोरिदम, सर्वर चंक प्रोटोकॉल, रिज़्यूमे सेमेंटिक्स और डुप्लिकेट-चंक नीति लागू होती है?
- क्या अपलोड से पहले एक पूर्ण डाइजेस्ट मौजूद होना चाहिए, या क्लाइंट पढ़ते समय अपलोड कर सकता है और अंत में सत्यापित कर सकता है?
- क्या कोई विफल स्थानांतरण पुष्टि किए गए चंक्स से फिर से शुरू हो सकता है, और सर्वर आइडम्पोटेंसी कैसे परिभाषित है?
- क्या होता है जब कोई उपयोगकर्ता पेज से नेविगेट कर जाता है, टैब बंद कर देता है, या डिवाइस पर मेमोरी का दबाव होता है?
API सेमेंटिक्स और रीड पाथ्स
Blob.bytes() कोई तर्क नहीं लेता है और एक Promise लौटाता है। फ़ुलफ़िल्ड मान एक Uint8Array होता है; रीड विफलता Promise को अस्वीकार (reject) कर देती है। यह कॉलर को एक बाइट ऐरे के रूप में Blob सामग्री सौंपता है, इसलिए यह ज़ीरो-कॉपी व्यवहार या असीमित बड़ी-फ़ाइल क्षमता को साबित नहीं करता है। यदि उपयोगी हो तो Worker में छोटी फ़ाइलें पढ़ें; बड़ी फ़ाइलों के लिए, slice() चंक्स और उसके बाद प्रति-चंक पढ़ने और अपलोड करने को प्राथमिकता दें।
पाथ का फ़ीचर-डिटेक्ट करें: उपलब्ध होने पर bytes() का उपयोग करें, अन्यथा arrayBuffer() का उपयोग करें और एक Uint8Array बनाएं; जहां ब्राउज़र और प्रोटोकॉल इसका समर्थन करते हैं, वहां stream() को वृद्धिशील (incrementally) रूप से उपयोग करें। फ़ॉलबैक को चंक नंबरिंग, डाइजेस्ट इनपुट और एरर अनुबंधों को बनाए रखना चाहिए ताकि सर्वर वैलिडेशन API के साथ न बदले।
मेमोरी, चंक्स और डाइजेस्ट
पूरे Blob को पढ़ने से कम से कम फ़ाइल के आकार के बराबर पीक बनता है, साथ ही अपलोड बफ़र्स, डिकोडिंग और रनटाइम ओवरहेड भी होता है। निश्चित या अनुकूली (adaptive) सीमाओं के साथ slice(start, end) को कॉल करें और केवल वर्तमान चंक और एक सीमित अपलोड कतार बनाए रखें। डाइजेस्ट को फ़ाइल क्रम में फ़ीड करें; समानांतर अपलोड्स को डाइजेस्ट इनपुट के क्रम को नहीं बदलना चाहिए।
प्रत्येक चंक में एक फ़ाइल ID, संस्करण, इंडेक्स, लंबाई और कंटेंट डाइजेस्ट होता है। सर्वर फ़ाइल ID और इंडेक्स द्वारा आइडम्पोटेंट रूप से स्टोर करता है, फिर क्रम में असेंबल करता है और कुल लंबाई व पूर्ण-फ़ाइल डाइजेस्ट को सत्यापित करता है। चंक डाइजेस्ट एंड-टू-एंड डाइजेस्ट की जगह नहीं लेते हैं क्योंकि डेटा हानि, पुन:क्रमण (reordering), या गलत संयोजन (concatenation) से अभी भी एक गलत फ़ाइल बन सकती है।
रद्दीकरण, पुनः प्रयास और वर्कर्स
रीड्स और अपलोड अनुरोधों को एक AbortController सिग्नल पास करें; रद्दीकरण कतारबद्ध चंक्स को साफ़ करता है और संदर्भों (references) को रिलीज़ करता है। केवल एक्सपोनेंशियल बैकऑफ़ और एक आइडम्पोटेंट चंक कुंजी के साथ पुनर्प्राप्त करने योग्य एरर्स का पुनः प्रयास करें। प्रमाणीकरण (Authentication) समाप्ति पर पुन: प्रमाणीकरण के लिए रुकना चाहिए, हमेशा के लिए पुनः प्रयास नहीं करना चाहिए। यदि कोई Worker डाइजेस्ट की गणना करता है, तो मुख्य थ्रेड पूरे बाइट ऐरे को वापस कॉपी करने के बजाय प्रगति, एरर्स और अंतिम परिणाम प्राप्त करता है।
stream() के साथ, बैकप्रेशर का सम्मान करें: रीडर को नेटवर्क और डाइजेस्ट उपभोक्ता से आगे नहीं निकलना चाहिए। प्रत्येक पाथ फ़ाइल सामग्री या संवेदनशील पाथ को लॉग किए बिना पुष्टि किए गए चंक्स, पढ़ने और अपलोड करने की अवधि, पुनः प्रयास, रद्दीकरण के कारणों और एक अनुमानित मेमोरी पीक को रिकॉर्ड करता है।
कम्पैटिबिलिटी और सुरक्षा सीमाएं
फ़ीचर डिटेक्शन bytes() का चयन करने से पहले typeof Blob !== "undefined" और "bytes" in Blob.prototype की जांच कर सकता है। केवल User-Agent पर निर्भर न रहें। पुराने ब्राउज़र arrayBuffer() या एक नियंत्रित FileReader पर फ़ॉलबैक कर सकते हैं, और मेमोरी बजट पूरा न होने पर उन्हें एक स्पष्ट संदेश प्राप्त होना चाहिए।
क्लाइंट डाइजेस्ट अखंडता (integrity) का प्रमाण प्रदान करते हैं, न कि प्राधिकरण (authorization), मैलवेयर स्कैनिंग या कंटेंट-टाइप सत्यापन। सर्वर को फ़ाइल आकार, चंक आकार, इंडेक्स रेंज और कुल अवधि को सीमित करना चाहिए; एक क्लाइंट MIME प्रकार कोई सुरक्षा निर्णय नहीं है। वर्कर्स के बीच संवेदनशील डेटा की प्रतिलिपि बनाने से बचें और कार्य पूरा होने के बाद संदर्भों को तुरंत रिलीज़ करें।
विफलता अभ्यास (Failure drills) और सत्यापन चेकलिस्ट
बिना और साथ वाले bytes() ब्राउज़रों, Worker और मुख्य-थ्रेड पाथ, खाली फ़ाइलों, एक-चंक और क्रॉस-चंक फ़ाइलों, बहुत बड़ी फ़ाइलों, नेटवर्क रुकावट, रद्द-और-फिर से शुरू, डुप्लिकेट चंक्स, आउट-ऑफ़-ऑर्डर चंक्स और डाइजेस्ट बेमेल को कवर करें। स्ट्रेस टेस्ट p95 रीड समय, अपलोड थ्रूपुट, पीक मेमोरी, लंबे टास्क, विफलता दर और रिकवरी समय को रिकॉर्ड करते हैं।
यदि bytes() अस्वीकार (reject) करता है, तो चंक स्थिति को सुरक्षित रखें और एक स्पष्ट फ़ॉलबैक पर स्विच करें। यदि फ़ॉलबैक मेमोरी बजट से अधिक हो जाता है, तो पूर्ण रीड को बाध्य करने के बजाय अगले चरण के संदेश के साथ रुकें। यदि सर्वर किसी चंक या पूर्ण डाइजेस्ट बेमेल का पता लगाता है, तो अपुष्ट असेंबली को छोड़ दें और अंतिम सुसंगत चंक से फिर से शुरू करें।
अनुवर्ती प्रश्न और संदर्भ उत्तर
आप bytes() और arrayBuffer() के बीच कैसे चयन करते हैं?
दोनों पूरे Blob को मेमोरी में लोड कर सकते हैं। bytes() सीधे एक Uint8Array की आपूर्ति करता है, जो बाइट-उन्मुख कोड के लिए उपयोगी है, लेकिन यह स्वचालित रूप से स्ट्रीमिंग प्रदान नहीं करता है। बड़ी फ़ाइलों को चंक्स या स्ट्रीम पाथ का उपयोग करना चाहिए।
केवल क्लाइंट-साइड पूर्ण-फ़ाइल डाइजेस्ट अपर्याप्त क्यों है?
यह साबित नहीं कर सकता कि सर्वर को प्रत्येक चंक क्रम में प्राप्त हुआ है, और यह प्राधिकरण या सामग्री सुरक्षा जांच की जगह नहीं लेता है। चंक इंडेक्स, चंक डाइजेस्ट, कुल लंबाई और सर्वर के अंतिम डाइजेस्ट को सत्यापित करें।
आप पुराने-ब्राउज़र फ़ॉलबैक को कैसे सत्यापित करते हैं?
फ़ीचर डिटेक्शन के साथ दोनों क्षमता पाथ्स को बाध्य करें, फिर एक वास्तविक ब्राउज़र मैट्रिक्स, Worker और मुख्य-थ्रेड निष्पादन, मेमोरी दबाव, ऑफ़लाइन रिकवरी और रद्दीकरण का परीक्षण करें। केवल एक आधुनिक ब्राउज़र पर्याप्त नहीं है।