वीडियो और उपशीर्षक · डायरेक्ट मीडिया डाउनलोडर
डाउनलोड की गई फ़ाइल का नाम कहां से आता है: URL पथ बनाम सामग्री-विस्थापन
· यह काम किस प्रकार करता है
http डाउनलोड मिडिया
यह बताता है कि एक ब्राउज़र कैसे तय करता है कि किसी सहेजी गई फ़ाइल को क्या कॉल करना है: URL का अंतिम खंड, सर्वर का कंटेंट-डिस्पोज़िशन हेडर, और डाउनलोड विशेषता जो एक टूल सेट कर सकता है। दिखाता है कि क्यों एक साफ़ URL कभी-कभी ख़राब फ़ाइल नाम देता है।
फ़ाइल 'file.php' के रूप में सहेजी गई है और खुलेगी नहीं - नामकरण समस्या जिसे एक सीधा लिंक छिपा सकता है
`file.php?id=42` से समाप्त होने वाला URL एक अनुपयोगी पथ नाम के साथ ब्राउज़र छोड़ते समय वीडियो बाइट्स वितरित कर सकता है। इसके विपरीत, `.mp4` से समाप्त होने वाला पता HTML लौटा सकता है। फ़ाइल नाम अनुरोध और प्रतिक्रिया मेटाडेटा से चुना गया एक लेबल है, न कि अंदर के पेलोड के बारे में प्रमाण।
सफल GET प्रतिक्रिया आने के बाद ही डायरेक्ट मीडिया डाउनलोडर सुझाए गए नाम की गणना करता है। यह पहले सामग्री-विस्थापन की जाँच करता है, फिर अंतिम गैर-रिक्त पथ खंड की, फिर एक छोटे MIME-आधारित फ़ॉलबैक की जाँच करता है। ब्राउज़र द्वारा सार्वभौमिक बातचीत करने का दावा करने की तुलना में यह क्रम संकीर्ण और अधिक पूर्वानुमानित है। यह पृथक्करण अस्थायी प्राधिकरण सामग्री को डिस्क नाम में लीक होने से रोकता है और संपूर्ण क्वेरी स्ट्रिंग द्वारा योगदान किए गए अवैध फ़ाइल नाम वर्णों से बचाता है।
अंतिम पथ खंड: डिफ़ॉल्ट अनुमान - ब्राउज़र URL से फ़ाइल नाम कैसे पढ़ता है और क्वेरी स्ट्रिंग्स इसे कहां भ्रमित करती हैं
पथ उम्मीदवार स्लैश पृथक्करण के बाद अंतिम खंड है, जिसे प्रतिशत एन्कोडिंग से डिकोड किया गया है। क्वेरी पैरामीटर शामिल नहीं हैं क्योंकि URL API उन्हें अलग से संग्रहीत करता है। इस प्रकार `/episodes/launch.mp3?token=...` से `launch.mp3` प्राप्त होता है, जबकि अनुवर्ती स्लैश में कोई अंतिम खंड नहीं होता है और उसे किसी अन्य स्रोत की आवश्यकता होती है।
यह पथ नियम यह तय नहीं करता कि कोई एक्सटेंशन ईमानदार है या नहीं। एक हस्ताक्षरित वितरण मार्ग एक पैरामीटर में मानव शीर्षक को छिपा सकता है, और यह कार्यान्वयन नामों के लिए मनमानी क्वेरी कुंजियाँ नहीं देगा। यह प्रतिबंध किसी हस्ताक्षर घटक, अभियान मूल्य, या रिकॉर्ड पहचानकर्ता को फ़ाइल नाम समझने में गलती करने से बचाता है। जब दोनों फॉर्म मौजूद होते हैं, तो अंतर्राष्ट्रीयकृत फॉर्म गैर-ASCII नामों को अधिक स्पष्ट रूप से संरक्षित कर सकता है, जबकि फ़ॉलबैक सरल सर्वर कार्यान्वयन को संभालता है।
सामग्री-विस्थापन: सर्वर का सुझाव - एक हेडर URL के नाम को कैसे ओवरराइड कर सकता है और क्यों कुछ CDN इसे सेट करते हैं और अन्य नहीं
सामग्री-विस्थापन एक सादा `filename=` सुझाव या एक एन्कोडेड UTF-8 `filename*=` फॉर्म ले जा सकता है। ToolAcre एन्कोडेड स्टार फॉर्म को प्राथमिकता देता है और प्रतिशत डिकोडिंग का प्रयास करता है; यदि डिकोडिंग विफल हो जाती है, तो यह पूर्ण स्थानांतरण को क्रैश करने के बजाय सादे रूप में और फिर पथ तर्क में गिर जाता है।
हेडर केवल सेवारत मेज़बान का सुझाव है। एप्लिकेशन कोड इसे सत्यापित करने के लिए मीडिया मेटाडेटा का निरीक्षण नहीं करता है, और एक भ्रामक सर्वर एक भ्रामक नाम प्रदान कर सकता है। फ़ाइल खोलने से पहले असामान्य वर्णों और एक्सटेंशन की समीक्षा करें, खासकर जब स्रोत होस्ट अपरिचित हो। ऑब्जेक्ट URL अस्थायी ब्राउज़र संदर्भ हैं, दूरस्थ पते नहीं, और उनका उपयोग मीडिया निकाय के लिए कोई अन्य अपलोड या HTTP अनुरोध नहीं बनाता है।
डाउनलोड विशेषता: एक टूल स्वयं क्या सेट कर सकता है - ब्राउज़र-साइड डाउनलोडर अपने द्वारा सहेजे गए ब्लॉब के लिए एक नाम कैसे चुन सकता है
ब्लॉब तैयार होने के बाद, UI ब्लॉब और चयनित फ़ाइल नाम दोनों को साझा डाउनलोड उपयोगिता में भेज देता है। वह उपयोगिता किसी ऑब्जेक्ट URL और डाउनलोड नाम के साथ ब्राउज़र सेव व्यवहार को ट्रिगर करती है। उस अंतिम क्लिक पर सर्वर के हेडर से अब परामर्श नहीं लिया जाता क्योंकि उसका सुझाव पहले ही हल हो चुका था।
यह तंत्र किसी मौजूदा डिस्क फ़ाइल का नाम नहीं बदलता या कोई फ़ोल्डर नहीं चुनता। ब्राउज़र सेटिंग्स अभी भी यह निर्धारित करती हैं कि कोई संवाद प्रकट होता है या नहीं और डुप्लिकेट नामों को कैसे प्रबंधित किया जाता है। ToolAcre एक उम्मीदवार की आपूर्ति करता है; ब्राउज़र और विज़िटर अंतिम फ़ाइल सिस्टम परिणाम के लिए जिम्मेदार रहते हैं। उपयोगकर्ताओं को अकेले नाम बदलकर किसी बेमेल को "ठीक" करने का विरोध करना चाहिए; मेटाडेटा या सामग्री में सुधार की आवश्यकता है या नहीं, यह तय करने से पहले वास्तविक कंटेनर और कोडेक्स का निरीक्षण करें।
एक्सटेंशन और MIME प्रकार: उन्हें सुसंगत रखना - क्यों .mp4 नामक फ़ाइल जो वास्तव में WebM है, खिलाड़ियों को भ्रमित करती है
एक `.mp4` नाम के साथ जोड़ा गया `video/webm` एक्सटेंशन द्वारा रूट करने वाले सॉफ़्टवेयर को भ्रमित कर सकता है, भले ही एक सक्षम खिलाड़ी बाइट्स का निरीक्षण कर सकता है। ToolAcre सामग्री-प्रकार से मेल खाने के लिए इसके एक्सटेंशन को दोबारा लिखने के बजाय पथ या हेडर नाम को संरक्षित करता है। यह सर्वर को भी सुरक्षित रखता है MIME ब्लॉब पर मूल्य.
यदि कोई शीर्षलेख और कोई पथ खंड मौजूद नहीं है, तो फ़ॉलबैक WebM या MP4 युक्त सामग्री-प्रकार को पहचानता है और `download.webm` या `download.mp4` लौटाता है; हर दूसरा प्रकार `download.bin` हो जाता है। ऑडियो MIME मानों को वर्तमान में इस अंतिम-संकल्प शाखा के माध्यम से कोई विशेष एक्सटेंशन प्राप्त नहीं होता है। यदि कोई हस्ताक्षर HEAD और GET के बीच समाप्त हो जाता है, तो कोई फ़ाइल नाम नहीं जीतता क्योंकि मुख्य अनुरोध विफल हो जाता है; सफल पठनीय प्रतिक्रिया के बाद ही नामकरण शुरू होता है।
कारगर उदाहरण: एक हस्ताक्षरित CDN लिंक और तीन संभावित फ़ाइल नाम - कौन सा नाम जीतता है और क्यों
एक हस्ताक्षरित CDN पता लें जिसका पथ `asset` पर समाप्त होता है, जिसकी प्रतिक्रिया `filename*=UTF-8''approved%20cut.mp4` है, और जिसका प्रकार `video/mp4` है। एन्कोडेड हेडर जीतता है, `approved cut.mp4` उत्पन्न करता है। हेडर हटाएं और पथ `asset` उत्पन्न करता है; उस खंड को भी हटा दें और MIME फ़ॉलबैक से `download.mp4` प्राप्त होगा।
एक सादा `filename="review.webm"` तब जीतेगा जब कोई उपयोग योग्य सितारा मान मौजूद नहीं होगा, भले ही पथ `clip.mp4` कहता हो। उदाहरण पूर्वता दर्शाता है, सत्यापन नहीं. सामग्री-प्रकार का निरीक्षण करना और विश्वसनीय सॉफ़्टवेयर में सहेजे गए परिणाम को खोलना, नाम चुनने के बाद अलग-अलग जाँचें बनी रहती हैं। एक कैटलॉग सहेजने के बाद अतिरिक्त रूप से एक चेकसम रिकॉर्ड कर सकता है, लेकिन हैशिंग इस डाउनलोडर के बाहर है और इसकी प्रदर्शित बाइट गिनती से इसका तात्पर्य नहीं होना चाहिए।
इसमें क्या शामिल नहीं है - डाउनलोड के बाद नाम बदलना, बैच नामकरण, या नाम देने के लिए फ़ाइल के अंदर मेटाडेटा पढ़ना
डाउनलोडर फ़ाइलों को बैच-नंबर नहीं करता है, मीडिया कंटेनर से शीर्षक टैग नहीं पढ़ता है, किसी संग्रह कैटलॉग को साफ़ नहीं करता है, या सहेजने के बाद किसी भ्रामक एक्सटेंशन की मरम्मत नहीं करता है। यह यह भी वादा नहीं कर सकता कि प्रत्येक सामग्री-विस्थापन व्याकरण भिन्नता इसके केंद्रित नियमित अभिव्यक्तियों से मेल खाएगी।
बाद में नाम बदलना एक ऑपरेटिंग-सिस्टम कार्य है। यदि अभिलेखीय नामकरण मायने रखता है, तो अपने स्वयं के कैटलॉग में स्रोत URL, प्रतिक्रिया प्रकार, बाइट गिनती और अनुमोदित वर्णनात्मक नाम रिकॉर्ड करें। किसी सुविधाजनक हेडर को स्रोत या फ़ाइल नाम एक्सटेंशन को क्रिप्टोग्राफ़िक पहचान के रूप में न मानें। पथ में विकृत प्रतिशत एन्कोडिंग एक अन्य होस्ट-गुणवत्ता समस्या है; वर्तमान फ़ॉलबैक प्रत्येक ऑपरेटिंग सिस्टम के नियमों में प्रत्येक सर्वर-प्रदत्त नाम को स्वच्छ करने का दावा नहीं करता है।
टेकअवे: नाम URL, हेडर और टूल के बीच एक बातचीत है - डायरेक्ट मीडिया डाउनलोडर का उपयोग करने के बाद सहेजी गई फ़ाइल के नाम और एक्सटेंशन में क्या जांचना है
कार्यान्वित प्राथमिकता ठोस है: वैध UTF-8 स्टार फ़ाइल नाम, सादा फ़ाइल नाम, डिकोड किया गया अंतिम पथ खंड, फिर `download.webm`, `download.mp4`, या `download.bin`। क्वेरी स्ट्रिंग सहेजे गए नाम का हिस्सा बने बिना डिलीवरी को अधिकृत कर सकती हैं। यह कई "डाउनलोड" और "इंडेक्स" आश्चर्यों की व्याख्या करता है।
डायरेक्ट मीडिया डाउनलोडर का उपयोग करने के बाद, नाम, एक्सटेंशन, सामग्री-प्रकार, अपेक्षित स्रोत और वास्तविक प्लेबिलिटी की तुलना करें। ये अवलोकन विभिन्न प्रश्नों का उत्तर देते हैं। एक साफ़ फ़ाइल नाम हैंडलिंग में सुधार करता है, लेकिन केवल होस्ट के बाइट्स और प्राप्तकर्ता एप्लिकेशन ही यह निर्धारित करते हैं कि फ़ाइल में वास्तव में क्या है। फ़ाइल नाम चयन प्रयोज्यता में सुधार करता है, जबकि उद्गम अभी भी अधिकृत स्रोत, रिकॉर्ड किए गए अनुरोध और पूर्ण बाइट्स के स्वतंत्र निरीक्षण से आता है।