मैं अभी पूरी तरह से भ्रमित हूँ - ज्यादातर शब्दावली के कारण, मुझे लगता है। क्या कोई कृपया मुझे मतभेदों के माध्यम से चल सकता है, या डमी-प्रूफ सामग्री के लिए कुछ लिंक प्रदान कर सकता है? विशेष रूप से URI से URL और फ़ाइल में संसाधन? मेरे लिए, ऐसा लगता है कि उन्हें क्रमशः एक ही चीज़ होना चाहिए ...
शब्दावली भ्रामक है और कभी-कभी भ्रामक होती है, और ज्यादातर जावा से एक एपीआई के रूप में और समय के साथ एक मंच के रूप में विकसित होती है। यह समझने के लिए कि इन शर्तों का क्या मतलब है कि वे क्या करते हैं, जावा की डिजाइन को प्रभावित करने वाली दो चीजों को पहचानना महत्वपूर्ण है:
- पिछेड़ी संगतता। पुराने अनुप्रयोगों को नए प्रतिष्ठानों पर चलना चाहिए, आदर्श रूप से बिना संशोधन के। इसका मतलब है कि एक पुराने एपीआई (इसके नाम और शब्दावली के साथ) को सभी नए संस्करणों के माध्यम से बनाए रखने की आवश्यकता है।
- क्रॉस-प्लेटफॉर्म। एपीआई को अपने अंतर्निहित प्लेटफ़ॉर्म का उपयोग करने योग्य सार प्रदान करना चाहिए, चाहे वह ऑपरेटिंग सिस्टम हो या ब्राउज़र।
मैं अवधारणाओं के माध्यम से चलूँगा और वे कैसे आएंगे। मैं उसके बाद आपके अन्य, विशिष्ट प्रश्नों का उत्तर दूंगा, क्योंकि मुझे पहले भाग में कुछ का उल्लेख करना पड़ सकता है।
"संसाधन" क्या है?
डेटा का एक सार, सामान्य टुकड़ा जो स्थित और पढ़ा जा सकता है। ढीली ने कहा, जावा इसका उपयोग एक "फ़ाइल" को संदर्भित करने के लिए करता है जो एक फ़ाइल नहीं हो सकती है लेकिन एक नामित डेटा का प्रतिनिधित्व करती है। जावा में इसका प्रत्यक्ष वर्ग या इंटरफ़ेस प्रतिनिधित्व नहीं है , लेकिन इसके गुणों (नियंत्रण योग्य, पठनीय) के कारण इसे अक्सर URL द्वारा दर्शाया जाता है।
क्योंकि जावा के शुरुआती डिज़ाइन लक्ष्यों में से एक को ब्राउज़र के अंदर सैंडबॉक्स किए गए एप्लिकेशन (एप्लेट्स) के रूप में चलाया जाना था, बहुत सीमित अधिकारों / विशेषाधिकारों / सुरक्षा मंजूरी के साथ, जावा एक फ़ाइल के बीच एक स्पष्ट (सैद्धांतिक) अंतर बनाता है (स्थानीय कुछ पर) फ़ाइल सिस्टम) और एक संसाधन (कुछ इसे पढ़ने की जरूरत है)। यही कारण है कि एप्लिकेशन (आइकन, क्लास फाइलें, और इसी तरह) के सापेक्ष कुछ पढ़ना ClassLoader.getResourceफ़ाइल वर्ग के माध्यम से और नहीं के माध्यम से किया जाता है ।
दुर्भाग्य से, क्योंकि "संसाधन" भी एक उपयोगी सामान्य शब्द है बाहर इस व्याख्या के, यह भी बहुत विशिष्ट बातें (वर्ग जैसे नाम के लिए प्रयोग किया जाता है ResourceBundle , UIResource , संसाधन ) है कि नहीं कर रहे हैं, इस अर्थ में, एक संसाधन।
एक संसाधन का प्रतिनिधित्व करने वाली मुख्य कक्षाएं (एक पथ) java.nio.file.Path , java.io.File , java.net.URI और java.net.URL हैं ।
फ़ाइल (java.io, 1.0)
फ़ाइल और निर्देशिका पथनामों का एक सार प्रतिनिधित्व।
फ़ाइल वर्ग एक संसाधन का प्रतिनिधित्व करता है जो प्लेटफ़ॉर्म की मूल फ़ाइल सिस्टम के माध्यम से उपलब्ध है । इसमें केवल फ़ाइल का नाम है, इसलिए यह वास्तव में एक पथ है (बाद में देखें) जो होस्ट प्लेटफ़ॉर्म अपनी सेटिंग्स, नियमों और वाक्यविन्यास के अनुसार व्याख्या करता है।
ध्यान दें कि फ़ाइल को कुछ स्थानीय की ओर संकेत करने की आवश्यकता नहीं है , बस कुछ ऐसा है जो होस्ट प्लेटफ़ॉर्म फ़ाइल एक्सेस के संदर्भ में समझता है, जैसे विंडोज में एक यूएनसी पथ। यदि आप अपने ओएस में एक फाइल सिस्टम के रूप में जिप फाइल को माउंट करते हैं, तो फाइल इसके निहित प्रविष्टियों को ठीक पढ़ेगी।
URL (java.net, 1.0)
क्लास URL यूनिफ़ॉर्म रिसोर्स लोकेटर का प्रतिनिधित्व करता है, जो वर्ल्ड वाइड वेब पर "संसाधन" का सूचक है। एक फ़ाइल या निर्देशिका के रूप में एक संसाधन कुछ सरल हो सकता है, या यह एक अधिक जटिल वस्तु का संदर्भ हो सकता है, जैसे डेटाबेस या खोज इंजन के लिए क्वेरी।
एक संसाधन की अवधारणा के साथ मिलकर, URL उस संसाधन का प्रतिनिधित्व करता है जिस तरह से फ़ाइल वर्ग होस्ट प्लेटफ़ॉर्म में एक फ़ाइल का प्रतिनिधित्व करता है: एक संरचित स्ट्रिंग के रूप में जो एक संसाधन को इंगित करता है। URL में अतिरिक्त रूप से एक योजना होती है जो संसाधन तक पहुंचने के संकेत देती है ("फ़ाइल के साथ:" "होस्ट प्लेटफ़ॉर्म से पूछें"), और इसलिए HTTP, FTP के माध्यम से संसाधनों को JAR और व्हाट्सएप के माध्यम से इंगित करने की अनुमति देता है।
दुर्भाग्य से, URL "फ़ाइल" और "पथ" के उपयोग सहित अपने स्वयं के सिंटैक्स और शब्दावली के साथ आते हैं। यदि URL एक फ़ाइल-URL है, तो URL.getFile संदर्भित फ़ाइल के पथ स्ट्रिंग के समान स्ट्रिंग लौटाएगा।
Class.getResource एक URL लौटाता है: यह फ़ाइल को लौटाने की तुलना में अधिक लचीला है, और इसने 1990 की शुरुआत में कल्पना की गई प्रणाली की जरूरतों को पूरा किया है।
URI (java.net, 1.4)
एक समान संसाधन पहचानकर्ता (URI) संदर्भ का प्रतिनिधित्व करता है।
URI URL पर एक (मामूली) अमूर्तता है। यूआरआई और यूआरएल के बीच अंतर वैचारिक और ज्यादातर अकादमिक है, लेकिन यूआरआई को औपचारिक रूप से बेहतर परिभाषित किया गया है, और उपयोग के मामलों की एक विस्तृत श्रृंखला को शामिल किया गया है। चूँकि URL और URI समान नहीं थे / हैं, इसलिए उनका प्रतिनिधित्व करने के लिए एक नई कक्षा शुरू की गई, जिसमें URI.toURL और URL.toURI एक और दूसरे के बीच स्थानांतरित करने के तरीके हैं।
जावा में, URL और URI के बीच मुख्य अंतर यह है कि एक URL resolvable होने की अपेक्षा को वहन करता है , कुछ ऐसा अनुप्रयोग जिसे इनपुटस्ट्रीम से चाह सकते हैं; एक यूआरआई अधिक एक सार thingamajig उस तरह व्यवहार किया जाता है हो सकता है कुछ समाधान योग्य को इंगित (और आमतौर पर करता है), लेकिन क्या इसका मतलब है और कैसे तक पहुँचने के लिए यह संदर्भ और व्याख्या के लिए और अधिक खुले हैं।
पथ (java.nio.file, 1.7)
एक फाइल सिस्टम में एक फ़ाइल का पता लगाने के लिए इस्तेमाल किया जा सकता है। यह आमतौर पर एक प्रणाली पर निर्भर फ़ाइल पथ का प्रतिनिधित्व करेगा।
पथ इंटरफ़ेस में नया नया एपीआई, फ़ाइल वर्ग की तुलना में अधिक लचीलेपन की अनुमति देता है। पथ इंटरफ़ेस फ़ाइल वर्ग का एक अमूर्त है , और न्यू IO फ़ाइल एपीआई का हिस्सा है । जहाँ फ़ाइल आवश्यक रूप से एक "फ़ाइल" की ओर इशारा करती है जैसा कि होस्ट प्लेटफ़ॉर्म द्वारा समझा जाता है, पथ अधिक सामान्य है: यह एक फ़ाइल (संसाधन) को एक मनमाना फ़ाइल सिस्टम में दर्शाता है।
पथ एक फ़ाइल के होस्ट प्लेटफ़ॉर्म की अवधारणा पर निर्भरता को दूर ले जाता है। यह एक ज़िप फ़ाइल में एक प्रविष्टि हो सकती है, एफ़टीपी या एसएसएच-एफएस के माध्यम से एक फ़ाइल, जो एप्लिकेशन क्लासपाथ का एक बहु-रूट प्रतिनिधित्व है, या वास्तव में कुछ भी जो फ़ाइलसिस्टम इंटरफ़ेस और इसके चालक, फाइलस्प्रोप्राइडर के माध्यम से सार्थक रूप से प्रस्तुत किया जा सकता है। यह जावा एप्लिकेशन के संदर्भ में "बढ़ते" फ़ाइल सिस्टम की शक्ति लाता है।
होस्ट प्लेटफ़ॉर्म को "डिफ़ॉल्ट फ़ाइल सिस्टम" के माध्यम से दर्शाया गया है; जब आप कॉल करते हैं File.toPath, तो आपको डिफ़ॉल्ट फ़ाइल सिस्टम पर एक पथ मिलता है।
अब, अगर मेरे पास एक लोकेटर है जो जार फ़ाइल में एक वर्ग या पैकेज का संदर्भ देता है, तो क्या वे दो (यानी एक फ़ाइल स्ट्रिंग्स पथ) भिन्न होंगे?
संभावना नहीं है। तो जार फ़ाइल स्थानीय फाइल सिस्टम पर है, तो आप एक प्रश्न घटक होना चाहिए नहीं, तो URL.getPathऔर URL.getFileही परिणाम लौटना चाहिए। हालाँकि, आपको जो आवश्यक है उसे चुनें: फ़ाइल-URL में आमतौर पर क्वेरी घटक नहीं हो सकते हैं, लेकिन मैं निश्चित रूप से किसी को भी जोड़ सकता हूं।
अंत में - और सबसे महत्वपूर्ण बात - मुझे फ़ाइल ऑब्जेक्ट की आवश्यकता क्यों है; संसाधन (URL) पर्याप्त क्यों नहीं है?
URL पर्याप्त नहीं हो सकता है क्योंकि फ़ाइल आपको अनुमतियों (जैसे पढ़ने योग्य, लिखने योग्य, निष्पादन योग्य), फ़ाइल प्रकार (मैं एक निर्देशिका हूं?), और स्थानीय फ़ाइल सिस्टम को खोजने और हेरफेर करने की अनुमति जैसे हाउसकीपिंग डेटा तक पहुंच प्रदान करता है। यदि ये ऐसी विशेषताएं हैं जिनकी आपको आवश्यकता है, तो फ़ाइल या पथ उन्हें प्रदान करें।
यदि आपके पास पाथ तक पहुँच है, तो आपको फ़ाइल की आवश्यकता नहीं है। कुछ पुराने API को फ़ाइल की आवश्यकता हो सकती है, हालाँकि।
(और एक संसाधन वस्तु है?)
नहीं, वहाँ नहीं है। इसके नाम से कई चीजें हैं, लेकिन वे इस अर्थ में संसाधन नहीं हैं ClassLoader.getResource।
PathNIO से