html - हरण - एचटीएमएल<बेस> टैग के लिए सिफारिशें क्या हैं?




एचटीएमएल परिभाषा (11)

बेस टैग के प्रभावों का टूटना:

बेस टैग में कुछ गैर-सहज प्रभाव पड़ता है, और मैं परिणामों के बारे में जागरूक होने और <base> पर भरोसा करने से पहले स्वयं के लिए परीक्षण करने की सलाह देता हूं! चूंकि मैंने अलग-अलग यूआरएल के साथ स्थानीय साइटों को संभालने के लिए बेस टैग का उपयोग करने के बाद उन्हें खोज लिया है और मेरी निराशा के बाद केवल समस्याग्रस्त प्रभावों को पता चला है, इसलिए मुझे दूसरों के लिए इन संभावित नुकसानों का सारांश बनाने के लिए मजबूर होना पड़ता है।

मैं नीचे दिए गए मामलों में अपना उदाहरण के रूप में: <base href="http://www.example.com/other-subdirectory/"> मूल टैग का उपयोग करूंगा, और यह दिखाऊंगा कि कोड जिस पृष्ठ पर है http://localsite.com/original-subdirectory

मेजर:

कोई लिंक या नाम एंकर या खाली href मूल उपनिर्देशिका को इंगित नहीं करेंगे, जब तक यह स्पष्ट नहीं किया जाता है: बेस टैग सब कुछ अलग-अलग लिंक बनाता है, जिसमें बेस टैग के यूआरएल के समान पृष्ठ एंकर लिंक शामिल हैं, उदाहरण के लिए:

  • <a href='#top-of-page' title='Some title'>A link to the top of the page via a named anchor</a>
    हो जाता है
    <a href='http://www.example.com/other-subdirectory/#top-of-page' title='Some title'>A link to an #named-anchor on the completely different base page</a>

  • <a href='?update=1' title='Some title'>A link to this page</a>
    हो जाता है
    <a href='http://www.example.com/other-subdirectory/?update=1' title='Some title'>A link to the base tag's page instead</a>

कुछ कामों के साथ, आप इन समस्याओं को उन लिंक पर ठीक कर सकते हैं जिन पर आप नियंत्रण रखते हैं, स्पष्ट रूप से यह निर्दिष्ट करते हुए कि ये लिंक उस पृष्ठ से लिंक हैं जो वे हैं, लेकिन जब आप मानक व्यवहार पर निर्भर मिश्रण में तीसरे पक्ष के पुस्तकालय जोड़ते हैं, यह आसानी से एक बड़ी गड़बड़ी का कारण बन सकता है।

माइनर:

आईई 6 फिक्स जिसके लिए सशर्त टिप्पणियों की आवश्यकता होती है: डोम पदानुक्रम को खराब करने से बचने के लिए यानी 6 के लिए सशर्त टिप्पणियों की आवश्यकता होती है, यानी <base href="http://www.example.com/"><!--[if lte IE 6]></base><![endif]--> जैसा कि BalusC ने उपरोक्त उत्तर में उल्लेख किया है।

तो कुल मिलाकर, बड़ी समस्या तब तक मुश्किल बनाती है जब तक कि आपके पास प्रत्येक लिंक पर पूर्ण संपादन नियंत्रण न हो, और जैसा कि मुझे मूल रूप से डर था, इससे यह अधिक मूल्यवान हो जाता है। अब मुझे जाना है और इसके सभी उपयोगों को फिर से लिखना है! : p

"टुकड़े" / हैश का उपयोग करते समय समस्याओं के परीक्षण के संबंधित लिंक:

http://www.w3.org/People/mimasa/test/base/

http://www.w3.org/People/mimasa/test/base/results

Izzy द्वारा संपादित करें: आप सभी के बारे में टिप्पणी के विषय में एक ही भ्रम में चल रहा है:

मैंने निम्नलिखित परिणामों के साथ इसे स्वयं परीक्षण किया है:

  • पिछला स्लैश या नहीं, यहां दिए गए उदाहरणों में कोई फर्क नहीं पड़ता है ( #anchor और ?query को निर्दिष्ट <BASE> ) में जोड़ा जाएगा।
  • हालांकि यह सापेक्ष लिंक के लिए एक फर्क पड़ता है: पिछला स्लैश, अन्य. other.html और dir/other.html को dir/other.html दिए गए उदाहरण के साथ DOCUMENT_ROOT पर शुरू होगा [प्रति ब्राउज़र?] , /other-subdirectory (सही ढंग से) फ़ाइल के रूप में माना जाता है और इस प्रकार छोड़ा गया [प्रति ब्राउज़र कौन सा?]

तो रिश्तेदार लिंक के लिए, BASE स्थानांतरित पृष्ठ के साथ ठीक काम करता है - जबकि एंकर और ?queries को फ़ाइल नाम की स्पष्ट रूप से निर्दिष्ट करने की आवश्यकता होगी ( BASE पीछे एक ट्रेलिंग स्लैश होता है, या अंतिम तत्व फ़ाइल के नाम से संबंधित नहीं है) ।

इसके बारे में सोचें <BASE> फ़ाइल को पूर्ण यूआरएल को प्रतिस्थापित करें (और निर्देशिका में यह नहीं है), और आपको चीजें सही मिल जाएंगी। इस उदाहरण में उपयोग की गई फ़ाइल को other-subdirectory/test.html (इसे नए स्थान पर ले जाने के बाद), सही विनिर्देश होना चाहिए था:

<base href="http://www.example.com/other-subdirectory/test.html ">

- et voila, सबकुछ अपेक्षित काम करता है: #anchor ?query , other.html , very/other.html , /completely/other.html

मैंने कभी भी <base> एचटीएमएल टैग वास्तव में कहीं भी नहीं देखा है। क्या इसके उपयोग के लिए नुकसान हैं जिसका मतलब है कि मुझे इससे बचना चाहिए?

तथ्य यह है कि मैंने इसे कभी भी आधुनिक उत्पादन साइट (या किसी भी साइट) पर उपयोग में नहीं देखा है, मुझे यह पसंद है, हालांकि ऐसा लगता है कि मेरी साइट पर लिंक को सरल बनाने के लिए उपयोगी अनुप्रयोग हो सकते हैं।

संपादित करें

कुछ हफ्तों के लिए बेस टैग का उपयोग करने के बाद, मैंने आधार टैग का उपयोग करने के साथ कुछ प्रमुख गॉथस ढूंढने को समाप्त कर दिया जो इसे पहले दिखाई देने से बहुत कम वांछनीय बनाता है। अनिवार्य रूप से, आधार टैग के तहत href='#topic' और href='' परिवर्तन उनके डिफ़ॉल्ट व्यवहार के साथ बहुत असंगत हैं, और डिफ़ॉल्ट व्यवहार से यह परिवर्तन आसानी से आपके नियंत्रण के बाहर तीसरे पक्ष के पुस्तकालयों को अप्रत्याशित तरीके से अविश्वसनीय बना सकता है , क्योंकि वे तर्कसंगत रूप से डिफ़ॉल्ट व्यवहार पर निर्भर करेंगे। अक्सर परिवर्तन सूक्ष्म होते हैं और बड़े कोडबेस से निपटने पर तत्काल-स्पष्ट समस्याओं का कारण बनते हैं। मैंने तब से उन मुद्दों का विवरण देने का उत्तर दिया है जिन्हें मैंने नीचे अनुभव किया था। तो <base> की व्यापक तैनाती के लिए प्रतिबद्ध होने से पहले अपने लिए लिंक परिणामों का परीक्षण करें, मेरी नई सलाह है!


AngularJS के साथ काम करना BASE टैग ने $ कुकी को तोड़ दिया चुपचाप और मुझे यह पता लगाने में थोड़ी देर लग गई कि मेरा ऐप अब और क्यों नहीं लिख सकता था। चेतावनी दी...


खैर, एक मिनट प्रतीक्षा करें। मुझे नहीं लगता कि बेस टैग इस बुरी प्रतिष्ठा का हकदार है।

बेस टैग के बारे में अच्छी बात यह है कि यह आपको कम परेशानी के साथ जटिल यूआरएल पुनर्लेखन करने में सक्षम बनाता है।

यहां एक उदाहरण दिया गया है। आप http://example.com/product/category/thisproduct को http://example.com/product/thisproduct पर ले जाने का निर्णय लेते हैं। आप दूसरे URL पर पहले यूआरएल को फिर से लिखने के लिए अपनी .htaccess फ़ाइल बदलते हैं।

बेस टैग के साथ, आप अपना .htaccess फिर से लिखते हैं और यही वह है। कोई बात नहीं। लेकिन बेस टैग के बिना, आपके सभी रिश्तेदार लिंक टूट जाएंगे।

यूआरएल रीराइट अक्सर आवश्यक होते हैं, क्योंकि उन्हें ट्वीक करने से आपकी साइट के आर्किटेक्चर और सर्च इंजन दृश्यता में मदद मिल सकती है। सच है, आपको "#" और "समस्याओं" के लिए वर्कअराउंड की आवश्यकता होगी। लेकिन बेस टैग टूलकिट में एक जगह का हकदार है।


ड्रूपल ने शुरुआत में <base> टैग पर भरोसा किया, और बाद में HTTP क्रॉलर और कैश के साथ समस्याओं के कारण उपयोग करने का निर्णय लिया।

मैं आम तौर पर लिंक पोस्ट करना पसंद नहीं करता हूं। लेकिन यह वास्तव में साझा करने लायक है क्योंकि इससे <base> टैग के साथ वास्तविक दुनिया के अनुभव के विवरण की तलाश करने वालों को लाभ हो सकता है:

http://drupal.org/node/13148


पृष्ठ में उल्लिखित एसवीजी छवियों के मामले में एक और महत्वपूर्ण मुद्दा उत्पन्न होता है जब base टैग का उपयोग किया जाता है:

चूंकि base टैग (जैसा कि पहले से ऊपर बताया गया है) के साथ आप रिश्तेदार हैश यूआरएल जैसे उपयोग करने की क्षमता को प्रभावी रूप से खो देते हैं

<a href="#foo">

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

<a href="/path/to/this/page/name.html#foo">

तो base टैग के प्रतीत होता है कि सकारात्मक टैग पहलुओं में से एक है (जो लंबे यूआरएल उपसर्गों को एंकर टैग से दूर ले जाना है और अच्छे, छोटे एंकर) प्राप्त करना है, स्थानीय हैश यूआरएल के लिए पूरी तरह से पीछे हटता है।

यह आपके पृष्ठ में एसवीजी को रेखांकित करते समय विशेष रूप से परेशान है, चाहे यह स्थिर एसवीजी या गतिशील रूप से जेनरेट किया गया एसवीजी हो क्योंकि एसवीजी में ऐसे कई संदर्भ हो सकते हैं और जैसे ही base टैग का उपयोग किया जाता है, वे सभी टूट जाएंगे, लेकिन सभी नहीं उपयोगकर्ता एजेंट कार्यान्वयन (लिखने के समय क्रोम कम से कम इन परिदृश्यों में काम करता है)।

यदि आप एक टेम्पलेटिंग सिस्टम या किसी अन्य टूल-चेन का उपयोग कर रहे हैं जो आपके पृष्ठों को संसाधित / उत्पन्न करता है, तो मैं हमेशा base टैग से छुटकारा पाने की कोशिश करता हूं, क्योंकि जैसा कि मैंने इसे देखा है, यह तालिका से हल होने की तुलना में अधिक समस्याएं लाता है।


मुझे <base> और एंकर आधारित लिंक का उपयोग करने का एक तरीका मिला है। आप जावास्क्रिप्ट का उपयोग #contact काम करने जैसे लिंक रखने के लिए कर सकते हैं जैसा कि उन्हें करना है। मैंने इसे कुछ लंबन पृष्ठों में इस्तेमाल किया और यह मेरे लिए काम करता है।

<base href="http://www.mywebsite.com/templates/"><!--[if lte IE 6]></base><![endif]-->

...content...

<script>
var link='',pathname = window.location.href;
$('a').each(function(){
    link = $(this).attr('href');
    if(link[0]=="#"){
        $(this).attr('href', pathname + link);
    }
});
</script>

आपको पृष्ठ के अंत में उपयोग करना चाहिए


यह ऑफ़लाइन देखने के लिए पृष्ठों को आसान बनाता है; आप बेस टैग में पूरी तरह से योग्य यूआरएल डाल सकते हैं और फिर आपके रिमोट संसाधन ठीक से लोड हो जाएंगे।


यह तय करने के लिए कि इसका उपयोग किया जाना चाहिए या नहीं, आपको अवगत होना चाहिए कि यह क्या करता है और इसकी आवश्यकता है या नहीं। यह पहले ही आंशिक रूप से इस उत्तर में उल्लिखित है, जिस पर मैंने भी योगदान दिया था। लेकिन इसे समझने और पालन करने में आसान बनाने के लिए, यहां एक दूसरा स्पष्टीकरण। सबसे पहले हमें समझने की जरूरत है:

ब्राउजर द्वारा <BASE> उपयोग किए बिना लिंक कैसे संसाधित किए जाते हैं?

कुछ उदाहरणों के लिए, मान लीजिए कि हमारे पास ये यूआरएल हैं:

ए) http://www.example.com/index.html
बी) http://www.example.com/
सी) http://www.example.com/page.html
डी) http://www.example.com/subdir/page.html

ए + बी दोनों एक ही फ़ाइल ( index.html ) में परिणामस्वरूप ब्राउज़र पर भेजे जाते हैं, सी निश्चित रूप से /subdir/page.html . page.html भेजता है, और डी भेजता है /subdir/page.html

आइए आगे मान लें, दोनों पृष्ठों में लिंक का एक सेट है:

1) पूरी तरह से योग्य पूर्ण लिंक ( http://www... )
2) स्थानीय पूर्ण लिंक ( /some/dir/page.html )
3) फ़ाइल नाम ( dir/page.html ) सहित सापेक्ष लिंक, और
4) केवल "सेगमेंट" के साथ सापेक्ष लिंक ( #anchor ?foo=bar )।

ब्राउज़र पृष्ठ प्राप्त करता है, और HTML प्रस्तुत करता है। अगर इसे कुछ यूआरएल मिल जाए, तो उसे यह पता होना चाहिए कि इसे कहां इंगित करना है। यह लिंक 1 के लिए हमेशा स्पष्ट है), जिसे लिया जाता है। अन्य सभी प्रस्तुत पृष्ठ के यूआरएल पर निर्भर करते हैं:

URL     | Link | Result
--------+------+--------------------------
A,B,C,D |    2 | http://www.example.com/some/dir/page.html
A,B,C   |    3 | http://www.example.com/dir/page.html
D       |    3 | http://www.example.com/subdir/dir/page.html
A       |    4 | http://www.example.com/index.html#anchor
B       |    4 | http://www.example.com/#anchor
C       |    4 | http://www.example.com/page.html#anchor
D       |    4 | http://www.example.com/subdir/page.html#anchor

अब <BASE> साथ क्या परिवर्तन किया जा रहा है?

<BASE> यूआरएल को प्रतिस्थापित करना है जैसा कि यह ब्राउज़र में दिखाई देता है । इसलिए यह सभी लिंक प्रस्तुत करता है जैसे उपयोगकर्ता ने <BASE> में निर्दिष्ट यूआरएल को बुलाया था। जो कई अन्य उत्तरों में भ्रम की कुछ व्याख्या करता है:

  • फिर, "पूरी तरह से योग्य पूर्ण लिंक" ("प्रकार 1") के लिए कुछ भी नहीं बदलता है
  • स्थानीय पूर्ण लिंक के लिए, लक्षित सर्वर बदल सकता है (यदि <BASE> में निर्दिष्ट एक जिसे उपयोगकर्ता से प्रारंभ में कहा जाता है)
  • सापेक्ष यूआरएल यहां महत्वपूर्ण हो जाते हैं, इसलिए आपको विशेष देखभाल करना होगा कि आपने <BASE> कैसे सेट किया है:
    • एक निर्देशिका में इसे स्थापित करने से बेहतर बेहतर है। ऐसा करने से, "टाइप 3" के लिंक काम करना जारी रख सकते हैं, लेकिन यह निश्चित रूप से "टाइप 4" ("केस बी" को छोड़कर) को तोड़ देता है।
    • इसे पूरी तरह से योग्य फ़ाइल नाम पर सेट करें , ज्यादातर मामलों में, वांछित परिणाम।

एक उदाहरण यह सबसे अच्छा बताता है

मान लें कि आप mod_rewrite का उपयोग करके कुछ यूआरएल "सुंदर" करना चाहते हैं:

  • वास्तविक फ़ाइल: <DOCUMENT_ROOT>/some/dir/file.php?lang=en
  • असली यूआरएल: http://www.example.com/some/dir/file.php?lang=en
  • उपयोगकर्ता के अनुकूल यूआरएल: http://www.example.com/en/file

आइए मान लें कि mod_rewrite का प्रयोग वास्तविक रूप से उपयोगकर्ता के अनुकूल यूआरएल को पारदर्शी रूप से फिर से लिखने के लिए किया जाता है (कोई बाहरी री-डायरेक्ट नहीं, इसलिए "उपयोगकर्ता के अनुकूल" ब्राउजर एड्रेस बार में रहता है, जबकि वास्तविक-लोड होता है)। अब क्या करे?

  • नहीं <BASE> निर्दिष्ट: सभी सापेक्ष लिंक तोड़ता है (क्योंकि वे अब http://www.example.com/en/file पर आधारित होंगे)
  • <BASE HREF='http://www.example.com/some/dir> : बिल्कुल गलत। dir निर्दिष्ट यूआरएल का फाइल हिस्सा माना जाएगा, फिर भी, सभी रिश्तेदार लिंक टूटे हुए हैं।
  • <BASE HREF='http://www.example.com/some/dir/> : बेहतर पहले से ही। लेकिन "टाइप 4" के सापेक्ष लिंक अभी भी टूटे हुए हैं ("केस बी" को छोड़कर)।
  • <BASE HREF='http://www.example.com/some/dir/file.php> : बिल्कुल। सब कुछ इस के साथ काम करना चाहिए।

एक अंतिम नोट

ध्यान रखें कि यह आपके दस्तावेज़ में सभी यूआरएल पर लागू होता है:

  • <A HREF=
  • <IMG SRC=
  • <SCRIPT SRC=
  • ...

यह शायद बहुत लोकप्रिय नहीं है क्योंकि यह अच्छी तरह से ज्ञात नहीं है। मैं इसका उपयोग करने से डर नहींूंगा क्योंकि सभी प्रमुख ब्राउज़र इसका समर्थन करते हैं।

यदि आपकी साइट AJAX का उपयोग करती है तो आप यह सुनिश्चित करना चाहेंगे कि आपके सभी पृष्ठों ने इसे सही तरीके से सेट किया है या आप उन लिंक के साथ समाप्त हो सकते हैं जिन्हें हल नहीं किया जा सकता है।

बस HTML 4.01 सख्त पृष्ठ में target विशेषता का उपयोग न करें।


साथ ही, आपको याद रखना चाहिए कि यदि आप गैर-मानक पोर्ट पर अपना वेब सर्वर चलाते हैं तो आपको बेस href पर पोर्ट नंबर भी शामिल करना होगा:

<base href="//localhost:1234" />  // from base url
<base href="../" />  // for one step above

बेस href उदाहरण

लिंक के साथ एक ठेठ पृष्ठ कहो:

<a href=home>home</a> <a href=faq>faq</a> <a href=etc>etc</a>

एक diff फ़ोल्डर के लिए लिंक।

..<a href=../p2/home>Portal2home</a> <a href=../p2/faq>p2faq</a> <a href=../p2/etc>p2etc</a>..

बेस href के साथ, हम मूल फ़ोल्डर को repeat से बच सकते हैं:

<base href=../p2/>
<a href=home>Portal2-Home</a> <a href=faq>P2FAQ</a> <a href=contact>P2Contact</a>

तो यह एक जीत है .. फिर भी पेजों में अक्सर diff अड्डों के लिए यूआरएल होते हैं और वर्तमान वेब प्रति पृष्ठ केवल एक आधार href का समर्थन करता है, इसलिए जीत को बेस के रूप में जल्दी से खो दिया जाता है जो आधार ∙ hrefed repeats, उदाहरण के लिए:

<a href=../p1/home>home</a> <a href=../p1/faq>faq</a> <a href=../p1/etc>etc</a>
<!--.. <../p1/> basepath is repeated -->

<base href=../p2>
<a href=home>Portal2-Home</a> <a href=faq>P2FAQ</a> <a href=contact>P2Contact</a>

निष्कर्ष

( आधार लक्ष्य उपयोगी हो सकता है।) बेस href बेकार है:

  • पृष्ठ समान रूप से WET है:
    • डिफ़ॉल्ट आधार [-पक्षीय फ़ोल्डर] और rlhar; सही (जब तक अनावश्यक / दुर्लभ अपवाद &Cscr;1 &Cscr;2 )।
    • वर्तमान वेब और र्लाहर; एकाधिक आधार href असमर्थित

सम्बंधित

  • Apache ∙ फिर से लिखने के आधार के साथ तुलना




base-tag