लेखक: सर टिम बर्नर्स-ली, URIs, URLs, HTTP, HTML र वर्ल्ड वाइड वेबका आविष्कारक, र W3C को वर्तमान प्रमुख। 1998 मा लेखिएको लेख

कुन URI लाई "कूल" मानिन्छ?
परिवर्तन नहुने एउटा।
URI कसरी परिवर्तन हुन्छ?
URI हरू परिवर्तन गर्दैनन्: मानिसहरूले तिनीहरूलाई परिवर्तन गर्छन्।

सिद्धान्तमा, त्यहाँ मानिसहरूले URIs परिवर्तन गर्ने कुनै कारण छैन (वा कागजातहरूलाई समर्थन गर्न बन्द गर्न), तर व्यवहारमा त्यहाँ लाखौं छन्।

सिद्धान्तमा, डोमेन नेमस्पेसको नाममात्र मालिकले वास्तवमा डोमेन नेमस्पेसको स्वामित्व लिन्छ र त्यसैले यसमा सबै URI हरू छन्। दिवालियापन बाहेक, कुनै पनि कुराले डोमेन नामको मालिकलाई नाम राख्नबाट रोक्दैन। र सिद्धान्तमा, तपाईंको डोमेन नाम अन्तर्गतको URI स्पेस पूर्ण रूपमा तपाईंको नियन्त्रणमा छ, त्यसैले तपाईंले यसलाई आफूले चाहेजस्तो स्थिर बनाउन सक्नुहुन्छ। इन्टरनेटबाट कागजात हराउनको लागि धेरै राम्रो कारण भनेको डोमेन नामको स्वामित्वमा रहेको कम्पनी व्यवसायबाट बाहिर गएको छ वा अब सर्भर चलाउनको लागि खर्च गर्न सक्दैन। त्यसोभए संसारमा किन यति धेरै हराइरहेको लिङ्कहरू छन्? यी मध्ये केही केवल पूर्वविचारको कमी हो। यहाँ तपाईंले सुन्न सक्ने केही कारणहरू छन्:

हामीले भर्खरै यसलाई राम्रो बनाउन साइटलाई पुन: संगठित गर्यौं।

के तपाई साँच्चै सोच्नुहुन्छ कि पुरानो URI ले अब काम गर्न सक्दैन? यदि त्यसो हो भने, तपाईंले तिनीहरूलाई धेरै खराब छनौट गर्नुभयो। अर्को रिडिजाइनको लागि नयाँ राख्ने विचार गर्नुहोस्।

हामीसँग यति धेरै सामानहरू छन् कि हामीले के पुरानो छ, के गोप्य छ, र के अझै सान्दर्भिक छ भनेर ट्र्याक राख्न सक्दैनौं, त्यसैले हामीले यो सबै बन्द गर्नु राम्रो ठान्यौं।

म सहानुभूति मात्र गर्न सक्छु। W3C एक अवधि मार्फत गयो जहाँ हामीले अभिलेखीय सामग्रीहरूलाई सार्वजनिक गर्नु अघि गोपनीयताका लागि सावधानीपूर्वक छान्नुपर्थ्यो। निर्णय पहिले नै सोच्नु पर्छ - सुनिश्चित गर्नुहोस् कि प्रत्येक कागजातको साथ तपाईंले स्वीकार्य पाठकहरू, सिर्जना मिति र आदर्श रूपमा, म्याद समाप्ति मिति रेकर्ड गर्नुहोस्। यो मेटाडेटा बचत गर्नुहोस्।

ठीक छ, हामीले पत्ता लगायौं कि हामीले फाइलहरू सार्न आवश्यक छ ...

यो सबैभन्दा दयनीय बहाना मध्ये एक हो। धेरै मानिसहरूलाई थाहा छैन कि वेब सर्भरहरूले तपाईंलाई वस्तुको URI र फाइल प्रणालीमा यसको वास्तविक स्थान बीचको सम्बन्धलाई नियन्त्रण गर्न अनुमति दिन्छ। URI स्पेसलाई एब्स्ट्र्याक्ट स्पेसको रूपमा सोच्नुहोस्, पूर्ण रूपमा व्यवस्थित। त्यसोभए तपाईले वास्तवमा यसलाई महसुस गर्न प्रयोग गर्नुहुने जुनसुकै वास्तविकतामा म्यापिङ गर्नुहोस्। त्यसपछि यसलाई वेब सर्भरमा रिपोर्ट गर्नुहोस्। तपाइँ यसलाई सही प्राप्त गर्न तपाइँको आफ्नै सर्भर स्निपेट पनि लेख्न सक्नुहुन्छ।

जोनले अब यो फाइल राख्दैन, जेनले अब गर्छ।

यूआरआईमा जोनको नाम थियो? होइन, फाइल उनको डाइरेक्टरीमा मात्र थियो? ठीक छ, ठीक छ।

पहिले हामीले यसको लागि CGI स्क्रिप्ट प्रयोग गर्यौं, तर अब हामी बाइनरी प्रोग्राम प्रयोग गर्छौं।

त्यहाँ एक पागल विचार छ कि स्क्रिप्टहरू द्वारा सिर्जना गरिएका पृष्ठहरू "cgibin" वा "cgi" क्षेत्रमा अवस्थित हुनुपर्छ। यसले तपाइँ कसरी तपाइँको वेब सर्भर चलाउने मेकानिक्सलाई उजागर गर्दछ। तपाइँ संयन्त्र परिवर्तन गर्नुहुन्छ (सामग्री बचत गर्दा पनि), र उफ् - तपाइँका सबै URI परिवर्तन।

उदाहरणका लागि राष्ट्रिय विज्ञान प्रतिष्ठान (NSF) लिनुहोस्:

NSF अनलाइन कागजातहरू

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

कागजातहरू हेर्न सुरु गर्ने पहिलो पृष्ठ स्पष्ट रूपमा केही वर्षहरूमा उस्तै रहनेछैन। cgi-bin, oldbrowse и pl - यो सबैले कसरी-हामी-यो-अब-को बारेमा जानकारीको बिट्स दिन्छ। यदि तपाइँ कागजात खोज्नको लागि पृष्ठ प्रयोग गर्नुहुन्छ भने, तपाइँले प्राप्त गर्नुभएको पहिलो परिणाम समान रूपमा खराब छ:

क्रिप्टोलोजी र कोडिङ सिद्धान्तमा कार्य समूहको रिपोर्ट

http://www.nsf.gov/cgi-bin/getpub?nsf9814

कागजात अनुक्रमणिका पृष्ठको लागि, यद्यपि html कागजात आफैंमा धेरै राम्रो देखिन्छ:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

यहाँ pubs/1998 हेडरले कुनै पनि भविष्यको अभिलेख सेवालाई पुरानो 1998 कागजात वर्गीकरण योजना प्रभावमा रहेको राम्रो संकेत दिनेछ। यद्यपि कागजात नम्बरहरू 2098 मा फरक देखिन सक्छ, म कल्पना गर्छु कि यो URI अझै पनि मान्य हुनेछ र NSF वा कुनै अन्य संस्थामा हस्तक्षेप गर्दैन जसले अभिलेखलाई कायम राख्छ।

मलाई लाग्दैन कि URL हरू निरन्तर हुनुपर्छ - त्यहाँ URN हरू थिए।

यो सायद URN बहसको सबैभन्दा खराब साइड इफेक्ट हो। केही मानिसहरू सोच्छन् कि अधिक स्थायी नेमस्पेसमा अनुसन्धानको कारण, तिनीहरू झुन्ड्याउने लिङ्कहरूको बारेमा लापरवाह हुन सक्छन् किनभने "URN ले ती सबै ठीक गर्नेछ।" यदि तपाइँ यी व्यक्तिहरू मध्ये एक हुनुहुन्छ भने, मलाई तपाइँलाई निराश गर्न दिनुहोस्।

धेरै जसो URN योजनाहरू मैले देखेको छु कि त मिति र तपाईंले चयन गर्नुभएको स्ट्रिङ, वा तपाईंले चयन गर्नुभएको स्ट्रिङले पछ्याएको प्राधिकरण पहिचानकर्ता जस्तो देखिन्छ। यो HTTP URI सँग धेरै मिल्दोजुल्दो छ। अर्को शब्दमा, यदि तपाइँ सोच्नुहुन्छ कि तपाइँको संगठन लामो समयसम्म URN हरू सिर्जना गर्न सक्षम छ, त्यसपछि तपाइँको HTTP URI हरू प्रयोग गरेर यसलाई अहिले प्रमाणित गर्नुहोस्। तपाईको URI अस्थिर बनाउने HTTP मा केहि पनि छैन। केवल तपाईंको संगठन। हालको फाइल नाममा कागजात URN लाई नक्सा गर्ने डाटाबेस सिर्जना गर्नुहोस्, र वेब सर्भरलाई फाइलहरू पुन: प्राप्त गर्न प्रयोग गर्न दिनुहोस्।

यदि तपाइँ यस बिन्दुमा पुग्नुभएको छ भने, यदि तपाइँसँग केहि सफ्टवेयर विकास गर्न समय, पैसा र जडानहरू छैनन् भने, तपाइँ निम्न बहाना बताउन सक्नुहुन्छ:

हामी चाहन्छौं, तर हामीसँग सही उपकरणहरू छैनन्।

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

तपाईंले URI परिवर्तन नगरी URI स्थानमा स्वामित्व, कागजात पहुँच, अभिलेख स्तर सुरक्षा, आदि परिवर्तन गर्न सक्षम हुन आवश्यक छ।

यो सबै धेरै नराम्रो छ। तर हामी स्थिति सुधार गर्नेछौं। W3C मा, हामी संस्करणहरू ट्र्याक गर्ने Jigedit (Jigsaw सम्पादन सर्भर) कार्यक्षमता प्रयोग गर्छौं, र हामी कागजात उत्पादन लिपिहरू प्रयोग गर्छौं। यदि तपाइँ उपकरणहरू, सर्भरहरू र ग्राहकहरू विकास गर्नुहुन्छ भने, यो समस्यामा ध्यान दिनुहोस्!

यो बहाना धेरै W3C पृष्ठहरूमा पनि लागू हुन्छ, जसमा यो पनि समावेश छ: त्यसैले मैले भनेझैं गर, मैले गरेझैं होइन।

मैले किन ख्याल गर्नुपर्छ?

जब तपाइँ तपाइँको सर्भरमा URI परिवर्तन गर्नुहुन्छ, तपाइँ पुरानो URI को लिङ्कहरू कसलाई हुनेछ भनेर तपाइँ कहिल्यै पूर्ण रूपमा भन्न सक्नुहुन्न। यी नियमित वेब पृष्ठहरूबाट लिङ्कहरू हुन सक्छन्। आफ्नो पृष्ठ बुकमार्क गर्नुहोस्। URI मित्रलाई पत्रको मार्जिनमा स्क्रोल गरिएको हुन सक्छ।

जब कसैले लिङ्क पछ्याउँछ र यो तोडिएको छ, तिनीहरू सामान्यतया सर्भर मालिकमा विश्वास गुमाउँछन्। आफ्नो लक्ष्य हासिल गर्न नसक्दा उहाँ भावनात्मक र शारीरिक दुवै रूपमा निराश हुनुहुन्छ।

धेरै मानिसहरूले टुटेको लिङ्कहरूको बारेमा सबै समय गुनासो गर्छन्, र मलाई आशा छ कि क्षति स्पष्ट छ। मलाई आशा छ कि कागजात गायब भएको सर्भरको मर्मतकर्तालाई प्रतिष्ठाको क्षति पनि स्पष्ट छ।

त्यसोभए मैले के गर्नुपर्छ? URI डिजाइन

2 वर्षमा, 20 वर्षमा, 200 वर्षमा प्रयोग गर्न सकिने URI हरू आवंटित गर्ने जिम्मेवारी वेबमास्टरको हो। यसका लागि सोच, संगठन र दृढ संकल्प चाहिन्छ।

URI परिवर्तन हुन्छ यदि तिनीहरूमा कुनै जानकारी परिवर्तन हुन्छ। तपाइँ तिनीहरूलाई कसरी डिजाइन गर्नुहुन्छ यो धेरै महत्त्वपूर्ण छ। (के, यूआरआई डिजाइन? के मलाई यूआरआई डिजाइन गर्न आवश्यक छ? हो, तपाईंले यसको बारेमा सोच्नुपर्छ)। मूलतः डिजाइन भनेको URI मा कुनै पनि जानकारी छोड्नु हो।

कागजात सिर्जना भएको मिति - URI जारी गरिएको मिति - यस्तो चीज हो जुन कहिल्यै परिवर्तन हुँदैन। पुरानो प्रणाली प्रयोग गर्नेहरूबाट नयाँ प्रणाली प्रयोग गर्ने प्रश्नहरू अलग गर्न यो धेरै उपयोगी छ। यो URI सँग सुरु गर्नको लागि राम्रो ठाउँ हो। यदि कागजात मिति छ भने, कागजात भविष्यमा सान्दर्भिक हुनेछ भने, यो एक राम्रो सुरुवात हो।

केवल अपवाद एक पृष्ठ हो जुन जानाजानी "नयाँ" संस्करण हो, उदाहरणका लागि सम्पूर्ण संगठन वा यसको ठूलो भागको लागि।

http://www.pathfinder.com/money/moneydaily/latest/

यो मनी पत्रिकाको पछिल्लो मनी डेली स्तम्भ हो। यस URI मा कुनै मितिको आवश्यकता नहुनुको मुख्य कारण यो हो कि लग भन्दा बाहिर रहने URI भण्डारण गर्ने कुनै कारण छैन। पैसा हराएपछि मनी डेलीको अवधारणा हराउनेछ। यदि तपाइँ सामग्रीमा लिङ्क गर्न चाहनुहुन्छ भने, तपाइँ यसलाई अभिलेखमा छुट्टै लिङ्क गर्नुपर्छ:

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(राम्रो देखिन्छ। pathfinder.com को जीवनभर "पैसा" को अर्थ एउटै हुनेछ भन्ने मान्छ। त्यहाँ एक नक्कल "98" र अनावश्यक ".html" छ, तर अन्यथा बलियो URI जस्तो देखिन्छ।

के छोड्ने हो

सबै! सिर्जना मिति बाहेक, URI मा कुनै पनि जानकारी राख्नाले कुनै न कुनै तरिकाले समस्याको लागि सोधिरहेको छ।

• लेखकको नाम। नयाँ संस्करणहरू उपलब्ध हुँदा लेखकत्व परिवर्तन हुन सक्छ। मानिसहरू संगठनहरू छोड्छन् र चीजहरू अरूलाई हस्तान्तरण गर्छन्।
• बिषय। यो धेरै गाह्रो छ। यो सधैं सुरुमा राम्रो देखिन्छ, तर आश्चर्यजनक रूपमा छिटो परिवर्तन हुन्छ। म तल यस बारे थप कुरा गर्नेछु।
• स्थिति। "पुरानो", "ड्राफ्ट" र यस्तै अन्य डाइरेक्टरीहरू, "पछिल्लो" र "कूल" उल्लेख नगर्ने, सबै फाइल प्रणालीहरूमा देखा पर्दछ। कागजातहरूले स्थिति परिवर्तन गर्दछ - अन्यथा मस्यौदाहरू सिर्जना गर्ने कुनै मतलब हुनेछैन। कागजातको पछिल्लो संस्करणलाई यसको स्थिति जस्तोसुकै भए पनि निरन्तर पहिचानकर्ता चाहिन्छ। नाम बाहिर स्थिति राख्नुहोस्।
• पहुँच। W3C मा, हामीले साइटलाई कर्मचारीहरू, सदस्यहरू र जनताका लागि खण्डहरूमा विभाजन गरेका छौं। यो राम्रो सुनिन्छ, तर निस्सन्देह, कागजातहरू स्टाफबाट टोली विचारहरूका रूपमा सुरु हुन्छन्, सदस्यहरूसँग छलफल गरिन्छ, र त्यसपछि सार्वजनिक ज्ञान हुन्छ। यो साँच्चै लाजमर्दो हुनेछ यदि प्रत्येक पटक व्यापक छलफलको लागि कागजात खोलिएको छ, यसमा सबै पुराना लिङ्कहरू तोडिएको छ! अब हामी एक साधारण मिति कोडमा जान्छौं।
• फाइल विस्तार। एक धेरै सामान्य घटना। "cgi", पनि ".html" भविष्यमा परिवर्तन हुनेछ। तपाईंले 20 वर्षमा यस पृष्ठको लागि HTML प्रयोग नगर्नु भएको हुन सक्छ, तर आजका लिङ्कहरूले अझै पनि काम गर्नुपर्छ। W3C साइटमा क्यानोनिकल लिङ्कहरू विस्तार प्रयोग गर्दैनन् (यो कसरी गरियो).
• सफ्टवेयर संयन्त्र। URI मा, "cgi", "exec" र अन्य सर्तहरू खोज्नुहोस् जुन "हामीले कुन सफ्टवेयर प्रयोग गरिरहेका छौं" भनेर चिच्याउछ। के कोही आफ्नो सम्पूर्ण जीवन Perl CGI स्क्रिप्ट लेख्न बिताउन चाहन्छ? होइन? त्यसपछि .pl विस्तार हटाउनुहोस्। यो कसरी गर्ने भनेर सर्भर म्यानुअल पढ्नुहोस्।
• डिस्क नाम। आउनुहोस्! तर मैले यो देखेको छु।

त्यसैले हाम्रो साइटबाट उत्तम उदाहरण सरल छ

http://www.w3.org/1998/12/01/chairs

... W3C अध्यक्षहरूको बैठकको मिनेटमा रिपोर्ट।

विषयवस्तु र विषय अनुसार वर्गीकरण

म यस खतराको बारेमा थप विवरणमा जानेछु, किनकि यो ती चीजहरू मध्ये एक हो जुन बेवास्ता गर्न धेरै गाह्रो छ। सामान्यतया, तपाईंले आफ्ना कागजातहरूलाई उनीहरूले गर्ने कामद्वारा वर्गीकरण गर्दा विषयहरू URI मा समाप्त हुन्छन्। तर यो विघटन समय संग परिवर्तन हुनेछ। क्षेत्रहरूको नाम परिवर्तन हुनेछ। W3C मा हामी खण्डको वास्तविक सामग्री प्रतिबिम्बित गर्न MarkUP लाई मार्कअप र त्यसपछि HTML मा परिवर्तन गर्न चाहन्थ्यौं। थप रूपमा, त्यहाँ प्रायः फ्ल्याट नेमस्पेस हुन्छ। 100 वर्षमा, के तपाइँ निश्चित हुनुहुन्छ कि तपाइँ केहि पनि पुन: प्रयोग गर्न चाहनुहुन्न? हाम्रो छोटो जीवनमा हामीले उदाहरणका लागि "इतिहास" र "शैली पानाहरू" पुन: प्रयोग गर्न चाहेका छौं।

यो वेबसाइट संगठित गर्न को लागी एक आकर्षक तरीका हो - र सम्पूर्ण वेब सहित केहि संगठित गर्न को लागी एक साँच्चै लोभ्याउने तरीका हो। यो एक उत्कृष्ट मध्यम-अवधि समाधान हो तर दीर्घकालीन रूपमा गम्भीर कमीहरू छन्।

कारणको अंश अर्थको दर्शनमा निहित छ। भाषामा प्रत्येक शब्द क्लस्टरिङको लागि सम्भावित लक्ष्य हो, र प्रत्येक व्यक्तिसँग यसको अर्थ के हो भनेर फरक विचार हुन सक्छ। संस्थाहरू बीचको सम्बन्ध रूख भन्दा वेब जस्तै भएकोले, वेबसँग सहमत हुनेहरूले पनि रूखको फरक प्रतिनिधित्व रोज्न सक्छन्। यी मेरा (धेरै बारम्बार) सामान्य समाधानको रूपमा पदानुक्रमिक वर्गीकरणको खतराहरूको बारेमा सामान्य अवलोकनहरू हुन्।

वास्तवमा, जब तपाइँ URI मा शीर्षकको नाम प्रयोग गर्नुहुन्छ, तपाइँ आफैलाई केहि प्रकारको वर्गीकरण गर्न प्रतिबद्ध हुनुहुन्छ। सायद भविष्यमा तपाईले फरक विकल्प रोज्नुहुनेछ। URI त्यसपछि उल्लङ्घनको लागि संवेदनशील हुनेछ।

URI को भागको रूपमा विषय क्षेत्र प्रयोग गर्नुको कारण यो हो कि URI स्पेसको उपखण्डहरूको लागि जिम्मेवारी सामान्यतया प्रत्यायोजित हुन्छ, र त्यसपछि तपाईंलाई संगठनात्मक निकायको नाम चाहिन्छ - विभाग, समूह, वा जुनसुकै - त्यो सबस्पेसको लागि जिम्मेवार छ। यो संगठनात्मक संरचनाको लागि बाध्यकारी URI हो। यो सामान्यतया सुरक्षित हुन्छ यदि अर्को (बायाँ) URI लाई मितिद्वारा सुरक्षित गरिएको छ: 1998/pics ले तपाईंको सर्भरलाई "हामीले 1998 मा चित्रहरू सहित के भन्यौं" भन्ने सट्टा "हामीले 1998 मा के गर्यौं जसलाई हामी अहिले चित्रहरू भन्छौं।"

डोमेन नाम नबिर्सनुहोस्

याद गर्नुहोस् कि यो URI मा रहेको पथमा मात्र नभई सर्भर नाममा पनि लागू हुन्छ। यदि तपाईंसँग विभिन्न चीजहरूको लागि छुट्टै सर्भरहरू छन् भने, याद गर्नुहोस् कि यो विभाजन धेरै, धेरै लिङ्कहरू नष्ट नगरी परिवर्तन गर्न असम्भव हुनेछ। केहि क्लासिक "हामीले आज प्रयोग गर्ने सफ्टवेयरमा हेर्नुहोस्" गल्तीहरू डोमेन नामहरू "cgi.pathfinder.com", "secure", "lists.w3.org" हुन्। तिनीहरू सर्भर प्रशासन सजिलो बनाउन डिजाइन गरिएको हो। डोमेनले तपाइँको कम्पनीको डिभिजन, कागजात स्थिति, पहुँच स्तर, वा सुरक्षा स्तरको प्रतिनिधित्व गर्दछ वा छैन, धेरै कागजात प्रकारहरूको लागि एक भन्दा बढी डोमेन नाम प्रयोग गर्नु अघि धेरै सावधान रहनुहोस्। याद गर्नुहोस् कि तपाईले एकल दृश्यात्मक वेब सर्भर भित्र रिडिरेक्शन र प्रोक्सी प्रयोग गरेर धेरै वेब सर्भरहरू लुकाउन सक्नुहुन्छ।

ओह, र तपाईको डोमेन नामको बारेमा पनि सोच्नुहोस्। तपाईंले उत्पादन लाइनहरू परिवर्तन गरेपछि र साबुन बनाउन बन्द गरेपछि तपाईं soap.com को रूपमा उल्लेख गर्न चाहनुहुन्न (यस क्षणमा soap.com को मालिक जो कोहीलाई माफ गर्नुहोस्)।

निष्कर्षमा

2, 20, 200, वा 2000 वर्षको लागि URI सुरक्षित गर्नु स्पष्ट रूपमा जस्तो देखिन्छ जस्तो सजिलो छैन। जे होस्, सम्पूर्ण इन्टरनेटमा, वेबमास्टरहरूले निर्णयहरू लिइरहेका छन् जसले भविष्यमा यो कार्यलाई साँच्चै गाह्रो बनाउँदैछ। प्रायः यो किनभने तिनीहरू उपकरणहरू प्रयोग गर्छन् जसको काम केवल यस क्षणमा सबैभन्दा राम्रो साइट प्रस्तुत गर्न हो - र कसैले पनि मूल्याङ्कन गरेको छैन जब सबै कुरा परिवर्तन हुन्छ लिङ्कहरूमा के हुन्छ। जे होस्, यहाँ बिन्दु यो हो कि धेरै, धेरै चीजहरू परिवर्तन हुन सक्छन्, र तपाईंको URI हरू उस्तै रहन सक्छन् र रहनु पर्छ। यो तब मात्र सम्भव छ जब तपाइँ तिनीहरूलाई कसरी सिर्जना गर्नुहुन्छ भन्ने बारे सोच्नुहुन्छ।

यो पनि हेर्नुहोस्:

• जेकब निल्सेनको उही विषयमा टायरेड

थप

फाइल एक्सटेन्सन कसरी हटाउने...

... हालको फाइल-आधारित वेब सर्भरमा URI बाट?

यदि तपाइँ Apache प्रयोग गर्नुहुन्छ भने, उदाहरणका लागि, तपाइँ यसलाई सामग्री वार्ता गर्न कन्फिगर गर्न सक्नुहुन्छ। फाइल एक्सटेन्सन (जस्तै. png) फाइलमा बचत गर्नुहोस् (जस्तै। mydog.png), तर तपाइँ बिना वेब स्रोतमा लिङ्क गर्न सक्नुहुन्छ। Apache त्यसपछि त्यो नाम र कुनै पनि एक्सटेन्सन भएका सबै फाइलहरूको लागि डाइरेक्टरी जाँच गर्दछ, र सेटबाट सबै भन्दा राम्रो छनौट गर्न सक्छ (उदाहरणका लागि, GIF र PNG)। र त्यहाँ विभिन्न डाइरेक्टरीहरूमा विभिन्न प्रकारका फाइलहरू राख्न आवश्यक छैन, वास्तवमा सामग्री मिलानले काम गर्दैन यदि तपाईंले त्यसो गर्नुभयो भने।

• सामग्री वार्ता गर्न आफ्नो सर्भर सेट अप गर्नुहोस्
• सँधै विस्तार बिना URI लाई लिङ्क गर्नुहोस्

विस्तारहरू भएका लिङ्कहरूले अझै काम गर्नेछन्, तर तपाईंको सर्भरलाई हाल र भविष्यमा उपलब्ध उत्तम ढाँचा छनोट गर्नबाट रोक्नेछ।

(वास्तबमा, mydog, mydog.png и mydog.gif - वैध वेब स्रोतहरू, mydog सार्वभौमिक सामग्री प्रकारको स्रोत हो, र mydog.png и mydog.gif - एक विशिष्ट सामग्री प्रकार को स्रोतहरू)।

निस्सन्देह, यदि तपाइँ आफ्नो वेब सर्भर लेख्दै हुनुहुन्छ भने, यो एक राम्रो विचार हो डाटाबेस प्रयोग गर्न को लागी उनीहरूको हालको फारममा निरन्तर पहिचानकर्ताहरू बाँध्न, यद्यपि असीमित डाटाबेस वृद्धिबाट सावधान रहनुहोस्।

शर्मको बोर्ड - कथा 1: च्यानल 7

1999 को समयमा, मैले पृष्ठमा हिउँको कारण विद्यालय बन्द भएको ट्र्याक गरें http://www.whdh.com/stormforce/closings.shtml। सूचना टिभी स्क्रिनको तल देखा पर्नको लागि पर्खनुहोस्! मैले यसलाई मेरो गृह पृष्ठबाट लिङ्क गरेको छु। 2000 को पहिलो ठूलो हिउँ आँधी आउछ र म पृष्ठ जाँच गर्छु। त्यहाँ लेखिएको छ:

- को रूपमा।
हाल केहि पनि बन्द छैन। कृपया मौसम चेतावनीको अवस्थामा फर्कनुहोस्।

यो यस्तो शक्तिशाली आँधी हुन सक्दैन। मिति छुटेको कुरा रमाइलो छ । तर यदि तपाइँ साइटको मुख्य पृष्ठमा जानुहुन्छ भने, त्यहाँ ठूलो बटन "बन्द विद्यालयहरू" हुनेछ, जुन पृष्ठमा जान्छ। http://www.whdh.com/stormforce/ बन्द विद्यालयहरूको लामो सूचीको साथ।

हुनसक्छ तिनीहरूले सूची प्राप्त गर्न प्रणाली परिवर्तन गरे - तर तिनीहरूले URI परिवर्तन गर्न आवश्यक थिएन।

बोर्ड अफ शेम - स्टोरी २: माइक्रोसफ्ट नेटमिटिङ

इन्टरनेटमा बढ्दो निर्भरताको साथ, एक चतुर विचार आयो कि निर्माताको वेबसाइटमा लिङ्कहरू अनुप्रयोगहरूमा इम्बेड गर्न सकिन्छ। यो धेरै प्रयोग र दुरुपयोग गरिएको छ, तर तपाइँ URL लाई परिवर्तन गर्न सक्नुहुन्न। अर्को दिन मैले वेब/फ्री सामान मेनुमा मद्दत/माइक्रोसफ्टमा Microsoft Netmeeting 2/something क्लाइन्टबाट एउटा लिङ्क प्रयास गरें र 404 त्रुटि प्राप्त भयो - सर्भरबाट कुनै प्रतिक्रिया फेला परेन। सायद तिनीहरूले पहिले नै यसलाई ठीक गरिसकेका छन् ...

© 1998 टिम बीएल

ऐतिहासिक नोट: 20 औं शताब्दीको उत्तरार्धमा, जब यो लेखिएको थियो, "कूल" अनुमोदन को एक विशेषण थियो, विशेष गरी युवाहरु माझ, फैशनेबलता, गुणस्तर, वा उपयुक्तता को संकेत गर्दछ। हतारमा, URI मार्ग अक्सर उपयोगिता वा स्थायित्वको सट्टा "शीतलता" को लागी छनोट गरिएको थियो। यो पोष्ट कूलको खोजी पछाडिको ऊर्जालाई पुन: निर्देशित गर्ने प्रयास हो।

स्रोत: www.habr.com