फ़ॉरवर्ड स्लैश (/) और बैकस्लैश (\) के बीच फ़ाइल पथ में अंतर

Question

मैं के बीच अंतर के बारे में सोच रहा था \और /फ़ाइल पथ में। मैंने देखा है कि कभी-कभी एक रास्ता होता है /और कभी-कभी यह साथ होता है \।

यह बहुत अच्छा होगा अगर कोई भी समझा सकता है कि कब उपयोग करना है \और /।

Comments

किस संदर्भ में अंतर? एक वेबी संदर्भ? सी # तारों में बचना? इसे ASP.NET के साथ टैग किया गया है।

— पीटर मोर्टेंसन

आगे और पीछे

— पीटर मोर्टेंसन

@Peter मैं इसे पुराने के रूप में बंद कर दूंगा, क्योंकि इससे बेहतर उत्तर मिले हैं।

— निकेल

प्रश्न से संबंधित c # और asp.net कैसे हैं ?

— ओरोल

@zzzzBov क्यों यह केवल पुराने एक को पुनर्निर्देशित नहीं किया गया था और बेहतर उत्तर वहां रखा गया था? मुझे ऐसी प्रणाली पसंद नहीं है, जहां मैं जो सवाल पूछता हूं, वह भविष्य में किसी चीज़ के "डुप्लिकेट" के रूप में बंद हो जाए। कम से कम इसे कुछ अधिक वर्णनात्मक कहें, जैसे डुप्लिकेट के बजाय "सुपरडेड"। मूल "एक" किसी भी चीज़ का डुप्लिकेट नहीं हो सकता है, यह केवल एक ही है।

Answer 1

/यूनिक्स और यूनिक्स जैसी प्रणालियों पर पथ विभाजक है। आधुनिक विंडोज आम तौर पर दोनों का उपयोग कर सकते \हैं और /एक दूसरे के स्थान filepaths के लिए है, लेकिन माइक्रोसॉफ्ट के उपयोग के लिए वकालत की है \दशकों के लिए पथ विभाजक के रूप में।

यह उन ऐतिहासिक कारणों के लिए किया जाता है जो 1970 के दशक की तारीख तक आते हैं, एक दशक से अधिक विंडोज की भविष्यवाणी करते हुए। शुरुआत में, MS-DOS (प्रारंभिक विंडोज की नींव) ने निर्देशिकाओं का समर्थन नहीं किया। /शुरुआत से ही चरित्र का उपयोग करते हुए यूनिक्स को डायरेक्टरी सपोर्ट था । हालाँकि, जब निर्देशिकाओं को MS-DOS 2.0 में जोड़ा गया था, तो Microsoft और IBM पहले से ही कमांड स्विच के/ लिए वर्ण का उपयोग कर रहे थे , और DOS के हल्के पार्सर ( QDOS से उतारे जाने के कारण , जिसे लोअर एंड हार्डवेयर पर चलाने के लिए डिज़ाइन किया गया था), वे एक नहीं ढूँढ सके! अपने मौजूदा अनुप्रयोगों के साथ संगतता को तोड़ने के बिना चरित्र का उपयोग करने के लिए संभव तरीका ।/

इसलिए, जब फ़ाइलपथों को इन जैसे आदेशों के लिए तर्क के रूप में पारित किया जाता है, तो "एक स्विच लापता" या "अमान्य स्विच" के बारे में त्रुटियों से बचने के लिए:

cd/                        <---- no switch specified
dir folder1/folder2        <---- /folder2 is not a switch for dir

यह तय किया गया था कि \चरित्र का उपयोग किया जाएगा, इसलिए आप उन आदेशों को इस तरह लिख सकते हैं

cd\
dir folder1\folder2

बिना किसी त्रुटि के।

बाद में, माइक्रोसॉफ्ट और आईबीएम ने ओएस / 2 नामक डीओएस से संबंधित एक ऑपरेटिंग सिस्टम पर सहयोग किया । ओएस / 2 में दोनों विभाजकों का उपयोग करने की क्षमता थी, शायद अधिक यूनिक्स डेवलपर्स को आकर्षित करने के लिए। जब 1990 में Microsoft और IBM ने तरीके बनाए, तो Microsoft ने कौन सा कोड लिया और Windows NT बनाया , जिस पर विंडोज के सभी आधुनिक संस्करण आधारित हैं, इस विभाजक अज्ञेयवाद को अपने साथ लेकर चलते हैं।

---

जैसा कि बैकवर्ड कम्पैटिबिलिटी माइक्रोसॉफ्ट के सभी प्रमुख OS बदलावों से खेल का नाम है, जो उन्होंने (Win16 / DOS को Win16 / Win32 को, Win32 / WinNT को) किया है, यह ख़ासियत अटक गई, और यह शायद थोड़ी देर के लिए मौजूद है।

यह इस कारण से है कि यह विसंगति मौजूद है। यह वास्तव में आप क्या कर रहे हैं पर कोई प्रभाव नहीं होना चाहिए क्योंकि, जैसा कि मैंने कहा, WinAPI आम तौर पर उन्हें परस्पर उपयोग कर सकते हैं। हालाँकि, /जब आप \निर्देशिका नामों के बीच उम्मीद करते हैं , तो 3 पार्टी एप्लिकेशन संभवतः टूट जाएंगे । यदि आप विंडोज का उपयोग कर रहे हैं, तो साथ रहें \। यदि आप यूनिक्स या यूआरआई का उपयोग कर रहे हैं (जिनका यूनिक्स पथ में आधार है, लेकिन यह पूरी तरह से एक और कहानी है), तो उपयोग करें /।

---

सी # के संदर्भ में: यह ध्यान दिया जाना चाहिए, क्योंकि यह है तकनीकी रूप से एक सी # सवाल है, कि आप और अधिक "पोर्टेबल" सी # कोड लिखने के लिए चाहते हैं, तो लगता है कि दोनों यूनिक्स और विंडोज (भले ही सी # मुख्य रूप से एक Windows भाषा है) पर काम करता है, तो आप Path.DirectorySeparatorCharफ़ील्ड का उपयोग करना चाह सकते हैं, इसलिए आपका कोड उस सिस्टम पर पसंदीदा विभाजक का उपयोग करता है, और Path.Combine()पथ को ठीक से जोड़ने के लिए उपयोग करता है।

Comments

और हमेशा रास्तों का उपयोग करके संयोजित करें Path.Combine।

— चेंग चेन

दिलचस्प। इसलिए डॉस या विंडोज के तहत, foo.exe /barकमांड-लाइन स्विच के foo.exe \barरूप में व्याख्या की जा सकती है , जबकि उदाहरण के लिए वर्तमान "ड्राइव" barकी रूट डायरेक्टरी में स्थित फ़ाइल / फ़ोल्डर के संदर्भ में व्याख्या की जा सकती है । \C:\

— जेपी स्टिग नील्सन

ऐसा नहीं है कि इस सामान्य ध्यान दिया जाना चाहिए /करने के लिए \ परत compat Win32 में किया जाता है, जिसका अर्थ है कि यदि आप इसे दरकिनार, वहाँ एक अंतर हो जाएगा। इसका सबसे प्रसिद्ध उदाहरण विस्तारित लंबाई पथ हैं: \\?\C:\ NTFS पर अपेक्षित रूप से काम करेंगे, लेकिन \\?\C:/नहीं करेंगे।

— वू

@PC लुडाईट: वह विनैपी दोनों को संभाल सकता है /और ` is not entirely true. For network path you have to use '(जैसे। \\ <servername> bot not // <servername>)

— raznagul

@raznagul सच। मैंने वास्तव में अपने उत्तर में नेटवर्क पथों का उल्लेख नहीं किया है। मैं मुख्य रूप से आम फ़ाइलपथ प्रकार के साथ फंस गया। मैं जोड़ दूंगा।

— पीसी लुडाइट

Answer 2

MS-DOS 1.0 ने CP / M से '/' के कमांड लाइन विकल्प (या स्विच) वर्ण सम्मेलन को बनाए रखा। उस समय फ़ाइल सिस्टम में कोई निर्देशिका संरचना नहीं थी और कोई संघर्ष नहीं था।

जब Microsoft ने MS-DOS (और PC-DOS) 2.0 के साथ पर्यावरण जैसे अधिक यूनिक्स को विकसित किया, तो उन्हें मौजूदा विभाजक रेखा विकल्पों के साथ संघर्ष नहीं करने वाली चीज़ का उपयोग करके पथ विभाजक का प्रतिनिधित्व करने की आवश्यकता थी। आंतरिक रूप से, सिस्टम '' / 'या' \ 'के साथ समान रूप से अच्छी तरह से काम करता है। कमांड प्रोसेसर (और कई एप्लिकेशन) स्विच चरित्र के रूप में '/' का उपयोग करना जारी रखता है।

एक CONFIG.SYSप्रविष्टि SWITCHAR=-का उपयोग /यूनिक्स संगतता में सुधार करने के लिए डिफ़ॉल्ट को ओवरराइड करने के लिए किया जा सकता है । यह कमांड में निर्मित होता है और मानक उपयोगिताओं वैकल्पिक चरित्र का उपयोग करते हैं। यूनिक्स पथ विभाजक को तब फ़ाइल और निर्देशिका नामों के लिए स्पष्ट रूप से उपयोग किया जा सकता है। इस प्रविष्टि को बाद के संस्करणों में हटा दिया गया था, लेकिन बूटिंग के बाद मान सेट करने के लिए एक डॉस कॉल को प्रलेखित किया गया था।

यह बहुत कम इस्तेमाल किया गया था और अधिकांश तीसरे पक्ष के उपकरण अपरिवर्तित रहे। भ्रम बना रहता है। यूनिक्स उपकरणों के कई पोर्ट '-' स्विच चरित्र को बनाए रखते हैं जबकि कुछ दोनों सम्मेलनों का समर्थन करते हैं।

फॉलो-ऑन पावरशेल कमांड प्रोसेसर कठोर भागने और स्विच मापदंडों को लागू करता है और बड़े पैमाने पर भ्रम से बचा जाता है जहां विरासत उपकरण का उपयोग किया जाता है।

न तो प्रश्न और न ही उत्तर C # से संबंधित है।

Comments

एक ऐतिहासिक नोट के /रूप में, विभिन्न पीडीपी -11 ऑपरेटिंग सिस्टम जैसे आरएसटीएस (1970) और आरएसएक्स (1972) में एक विकल्प परिचयकर्ता के रूप में उपयोग सीपी / एम (1973) में है।

— PJTraill

Answer 3

यूनिक्स-आधारित सिस्टम \एक एस्केप कैरेक्टर है, जो कि \पार्सर को बताता है कि यह एक स्पेस है न कि स्टेटमेंट का अंत। यूनिक्स सिस्टम पर /निर्देशिका विभाजक है।

Windows \निर्देशिका विभाजक है, लेकिन /फ़ाइल या निर्देशिका नामों में उपयोग नहीं किया जा सकता है।

Comments

\ और /(साथ ही कई अन्य प्रतीकों) का उपयोग फ़ाइल नाम में नहीं किया जा सकता है क्योंकि डॉस के पास एक ही जटिल पार्सर नहीं है जो यूनिक्स उपयोगकर्ताओं के लिए उपयोग किया जाता है। एक अच्छे पार्सर की कमी MS-DOS के QDOS ("क्विक एंड डर्टी ऑपरेटिंग सिस्टम") से उतरने का परिणाम थी। इसका मतलब चीजों को जल्दी और सीमित हार्डवेयर पर चलाना था। यह सब निश्चित रूप से वर्तमान समय में पिछड़ी अनुकूलता के लिए मौजूद है।

— पीसी लुडाइट

यह ध्यान देने योग्य है कि बाद में विंडोज के संस्करणों को /"अल्टरनेट_डायरेरी_सेपरेटर" के रूप में जोड़ा गया था

— तोमर डब्ल्यू

@PCLuddite शायद हमें इसके बजाय आगे संगतता के बारे में सोचना चाहिए?

@nocomprende फ़ाइलपथ के बारे में क्या असंगत हैं? क्या साथ असंगत? और जैसा कि मैंने पहले कहा था, "कुछ डीओएस ऐप" (जो वास्तव में हजारों की तरह अधिक था) को बचाने से बचाना उस समय उपभोक्ताओं के लिए वास्तव में महत्वपूर्ण था। यह वही है जो आज माइक्रोसॉफ्ट सफल हुआ और यूनिक्स (और अन्य सभी वास्तव में) गिरावट पर शुरू होते हैं (भले ही पिछले दशक में पुनरुत्थान हुआ हो)। मैं यह देखने में विफल हूं कि यह सामान्य ज्ञान के साथ कैसे नहीं देख रहा है।

— पीसी लुडाइट

@nocomprende और फ़ाइलपैथ के मानकीकृत नहीं होने के बारे में आपका तर्क पूरी तरह से शून्य है। वे विंडोज पर मानकीकृत हैं, और वे यूनिक्स पर मानकीकृत हैं। यदि आप क्रॉस-प्लेटफ़ॉर्म मानक के बारे में बात कर रहे हैं, तो यह वास्तव में उपयोगी या लागू करने में आसान नहीं है। कौन कहता है कि एक मानक दूसरे की तुलना में वास्तव में "बेहतर" है?

— पीसी लुडाइट

Answer 4

• एक URL, जो RFC 1738 में मानकीकृत है, हमेशा प्लेटफ़ॉर्म की परवाह किए बिना आगे की स्लैश का उपयोग करता है।
• एक फ़ाइल पथ और एक URI भिन्न होते हैं। \एक Windows फ़ाइल पथ /में सही है और एक URI में सही है।
• कई ब्राउज़र (जैसे, फ़ायरफ़ॉक्स और ओपेरा) जब आपस में बैकस्लैश के साथ URI से भिड़ते हैं, तो बहुत ज्यादा असफल होते हैं।
• System.IO.Path.DirectorySeparatorChar वर्तमान पथ विभाजक पाने के लिए

यह प्रासंगिक संसाधन हो सकता है।

Comments

विपत्तिपूर्ण रूप से विफल? फ़ायरफ़ॉक्स स्वचालित रूप से अनुवाद \​​करता है /। मेरी पुस्तक में इसे "मूल रूप से काम करता है" कहा जाता है।

— क्रोल्टन

मेरे घर ने फ़ायरफ़ॉक्स में अंतिम बार आग लगने पर पकड़ा

— user3163495

@CarstenS, फ़ायरफ़ॉक्स बैकस्लैश को URL ऑटोमैटिक में स्लैश में परिवर्तित नहीं करता है और लिंक को नहीं खोलता है। यह ऐड-ऑन URL को बैकस्लैश और ओपन पेज के साथ सही करता है। addons.mozilla.org/en-US/seamonkey/addon/…

— सामी

"असफल प्रलय" से आपका वास्तव में क्या मतलब है? क्या होता है? क्या ब्राउज़र क्रैश और बाहर निकलता है?

— पीटर मोर्टेंसन

Answer 5

दिए गए उत्तरों के अलावा, यह उल्लेखनीय है कि प्रोग्रामिंग भाषाओं, पाठ संपादकों और सामान्य प्रणालियों में \विशेष वर्ण (जैसे \n \t) के लिए व्यापक रूप से उपयोग किया जाता है जो शाब्दिक विश्लेषण लागू करते हैं।

यदि आप उदाहरण के लिए प्रोग्रामिंग कर रहे हैं, तो \\इसे ठीक से उपयोग करने के लिए किसी अन्य ( ) के साथ बैकस्लैश से बचने की आवश्यकता के लिए कई बार असुविधाजनक है - या भागने के तार का उपयोग करने की आवश्यकता है, जैसे कि सी # @"\test"।

बेशक, जैसा कि पहले उल्लेख किया गया है, वेब यूआरआई मानक द्वारा आगे स्लैश का उपयोग करते हैं लेकिन दोनों स्लैश नवीनतम और सबसे सामान्य कमांड लाइन टूल में काम करते हैं।

UPDATE: थोड़ी खोज करने के बाद, यह पूरी कहानी के बीच का लगता है /और \उस समय के "कंप्यूटर इतिहास" में वापस चला जाता है, उस समय के डॉस और यूनिक्स-आधारित प्रणालियों में। HowToGeek में इस कहानी के बारे में एक दिलचस्प लेख है ।

संक्षेप में, डॉस 1.0 को शुरू में आईबीएम ने बिना डायरेक्टरी सपोर्ट के जारी किया /था , और इसे दूसरे ("स्विचिंग") कमांड कार्यक्षमता के लिए उपयोग किया गया था। जब निर्देशिकाओं को 2.0 संस्करण में पेश किया /गया था, तो पहले से ही उपयोग में था, इसलिए आईबीएम ने नेत्रहीन निकटतम प्रतीक चुना, जो था \। दूसरी ओर, यूनिक्स मानक रूप /से निर्देशिकाओं के लिए उपयोग किया जाता है।

जब उपयोगकर्ताओं ने कई अलग-अलग प्रणालियों का उपयोग करना शुरू कर दिया, तो वे भ्रमित होने लगे, ओएस डेवलपर्स को सिस्टम को दोनों मामलों में काम करने का प्रयास करने के लिए बना दिया - यह URL के हिस्से में भी लागू होता है, क्योंकि कुछ ब्राउज़र http: \\ www.test का समर्थन करते हैं । com \ go प्रारूप। यह सामान्य रूप से कमियां थीं, लेकिन पूरी बात आज भी पिछड़े हुए कम्पार्टेबिलिटी कारणों के लिए है, विंडोज पर दोनों स्लैश के समर्थन के प्रयास के साथ, भले ही वे अब डॉस पर आधारित नहीं हैं।

Comments

"दोनों स्लैश फ़ाइल सिस्टम पथों में काम करते हैं।" यह गलत है, क्योंकि जब आप ` as well as many मेक 'शेल का उपयोग करते हैं तो यूनिक्स बहुत क्रोधित होता है ... आप सही हैं कि हाल ही में विंडोज ने ALTERNATE_PATH_SEPARATOR पर्यावरण चर को परिभाषित किया है जो /इसलिए कि शायद विंडोज दोनों को स्वीकार कर सकता है।

— तोमर डब्ल्यू

@ टॉमरडब्ल्यू विंडोज एनटी हमेशा पॉसिक्स-संगत रहा है (हालांकि शुरुआती पॉसिक्स वैसे भी एक गड़बड़ था, और इसमें से कुछ विंडोज में पीछे की ओर संगतता के लिए अटक गए थे)। /सिस्टम में हर जगह सहायक रास्तों को शामिल किया गया है - ज़ाहिर है, अनुप्रयोग उन रास्तों को उनके अवकाश पर गलत समझ सकते हैं, इसलिए इसका बहुत अधिक उपयोग नहीं किया गया था। गैर-सीएलआई अनुप्रयोग जो अपने स्वयं के (टूटे हुए) रास्तों का सत्यापन करने की कोशिश नहीं करते थे, वे ठीक हो जाते हैं।

— लुआँ

@ Luaan विंडोज में कई POSIX सुविधाओं का समर्थन करने की क्षमता थी, लेकिन मैं शायद ही कहूंगा कि यह "POSIX- संगत" था। निश्चित रूप से, कुछ POSIX उपप्रणालियों का उपयोग किया जा सकता है जो वर्षों से उपयोग किए जा रहे थे, लेकिन वे आदर्श से बहुत दूर थे। विंडोज 10 उबंटू बैश का समर्थन करेगा हालांकि बाद में इस गर्मी में उबंटू के साथ आने वाले लिनक्स टूल्स के लिए देशी समर्थन के साथ, ताकि आप भविष्य में यह तर्क देने में सक्षम हो सकें, लेकिन आप निश्चित रूप से "हमेशा" नहीं कह सकते।

— पीसी लुडाइट

"संगत" के बिना @Luaan का अर्थ है "साइबरविन वर्क"।

— पीसी लुडाइट

@PCLuddite नहीं, यह 100% POSIX.1c संगत था। इसका मतलब यह नहीं है कि सभी यूनिक्स अनुप्रयोग इस पर काम करते हैं - अधिकांश यूनिक्स अनुप्रयोग पॉसिक्स अनुपालन नहीं हैं :)

— लूआन

Answer 6

आपको C # का उपयोग नहीं करना चाहिए। आपको हमेशा Pathक्लास का इस्तेमाल करना चाहिए । इसमें एक विधि शामिल है Path.Combineजिसका उपयोग विभाजक को निर्दिष्ट किए बिना पथ बनाने के लिए किया जा सकता है।

उदाहरण उपयोग:

string fullPath = System.IO.Path.Combine("C:", "Folder1", "Folder2", "file.txt");

Answer 7

\ विंडोज स्थानीय फ़ाइल पथ और नेटवर्क पथ के लिए उपयोग किया जाता है:

C:\Windows\Temp\ या \\NetworkSharedDisk\Documents\Archive\

/ मानक URI द्वारा निम्न के रूप में क्या आवश्यक है:

http://www.stackoverflow.com/

Comments

@ निखिलवार्तक, मैंने उदाहरण जोड़े हैं, हालांकि मुझे लगा कि मेरे प्रारंभिक उत्तर ने ओपी के सभी प्रश्नों को संबोधित किया है।

— ऐश

विंडोज़ /पथ में भी पहचानता है (कम से कम 7 करता है)।

— केनेथ के।

यह उत्तर पूर्ण से बहुत दूर है।

— रीइनियरिएपोस्ट

क्या आप केवल स्टैक ओवरफ्लो मुख्य पृष्ठ के अलावा कुछ संसाधनों से जुड़े थे?

— तस

@reinierpost, मेरा उत्तर ओपी के प्रश्न और संबंधित टैग पर आधारित है। यहाँ कुछ अन्य उत्तरों की तरह, मैं stackoverflow.com/questions/1589930/… से कुछ कॉपी कर सकता हूँ और यहाँ पेस्ट कर सकता हूँ लेकिन यह अत्यधिक लग रहा था। @tas, मैंने स्टैण्डओवरफ़्लो पेज या किसी भी वेबसाइट हाइपरलिंक से लिंक करने का इरादा किया है, /जैसा कि मैंने उत्तर में कहा है कि स्टैंडरैड यूआरआई के उपयोग को स्पष्ट करने के लिए।

— ऐश