HTML एंटिटी एनकोडर और डिकोडर

विशेष वर्णों को HTML एंटिटी के रूप में एनकोड करने के लिए टेक्स्ट पेस्ट करें, या उन्हें पठनीय टेक्स्ट में डिकोड करने के लिए एंटिटी वाला HTML पेस्ट करें। नामित एंटिटी (&, <, ©), दशमलव संख्यात्मक (©) या हेक्साडेसिमल (©) में से चुनें। अधिकतम संगतता के लिए सभी गैर-ASCII वर्णों को वैकल्पिक रूप से एनकोड करें।

सभी गैर-ASCII वर्ण एनकोड करें

इनपुट टेक्स्ट

एनकोडेड आउटपुट

कैसे काम करता है

HTML एंटिटी क्या हैं?

HTML एंटिटी विशेष टेक्स्ट कोड होते हैं जिनका उपयोग उन वर्णों को दर्शाने के लिए किया जाता है जिनका HTML में विशेष अर्थ होता है या जिन्हें सीधे टाइप नहीं किया जा सकता। सबसे महत्वपूर्ण HTML सिंटैक्स में आरक्षित पाँच वर्ण हैं: & (एम्परसेंड) → &, < (से कम) → <, > (से अधिक) → >, " (डबल कोट) → ", और ' (सिंगल कोट) → '। यदि ये वर्ण बिना एनकोडिंग के टेक्स्ट सामग्री में दिखाई देते हैं, तो ब्राउज़र उन्हें HTML मार्कअप के रूप में व्याख्या कर सकता है, जिससे रेंडरिंग त्रुटियाँ या सुरक्षा कमजोरियाँ हो सकती हैं।

HTML एंटिटी तीन प्रारूपों में आती हैं: नामित एंटिटी एक वर्णनात्मक नाम का उपयोग करती है (© © के लिए, € € के लिए), दशमलव संख्यात्मक वर्ण संदर्भ एक कोड पॉइंट नंबर का उपयोग करते हैं (© © के लिए), और हेक्साडेसिमल वर्ण संदर्भ हेक्स कोड का उपयोग करते हैं (© © के लिए)। तीनों प्रारूप समकक्ष हैं — ब्राउज़र किसी भी प्रारूप का उपयोग किए जाने पर एक ही वर्ण रेंडर करता है। नामित एंटिटी सबसे अधिक पठनीय होती हैं; संख्यात्मक एंटिटी सबसे सार्वभौमिक हैं क्योंकि वे किसी भी Unicode वर्ण के लिए काम करती हैं।

HTML एंटिटी कब एनकोड करें

जब भी टेक्स्ट सामग्री या विशेषता मानों में पाँच आरक्षित HTML वर्ण (&, <, >, ", ') दिखाई दें, तो कम से कम उन्हें एनकोड करना आवश्यक है। उन्हें एनकोड न करना Cross-Site Scripting (XSS) कमजोरियों का स्रोत है: यदि उपयोगकर्ता इनपुट को एनकोडिंग के बिना HTML में डाला जाता है, तो एक हमलावर स्क्रिप्ट टैग या इवेंट हैंडलर इंजेक्ट कर सकता है। React, Vue और Angular जैसे आधुनिक फ्रेमवर्क डिफ़ॉल्ट रूप से HTML को स्वतः एनकोड करते हैं — innerHTML मुख्य अपवाद है जहाँ मैन्युअल एनकोडिंग अभी भी महत्वपूर्ण है।

आवश्यक पाँच वर्णों के अलावा, आप उन वातावरणों के लिए गैर-ASCII वर्णों को भी एनकोड करना चाह सकते हैं जो UTF-8 को विश्वसनीय रूप से संभाल नहीं करते: ईमेल HTML, लीगेसी CMS सिस्टम, या अधिकतम संगतता के लिए दस्तावेज़। «सभी गैर-ASCII एनकोड करें» विकल्प कोड पॉइंट 127 से ऊपर के प्रत्येक वर्ण को एक संख्यात्मक एंटिटी में परिवर्तित करता है, यह सुनिश्चित करते हुए कि आउटपुट शुद्ध ASCII है जबकि रेंडर होने पर दृश्य स्वरूप को संरक्षित करता है। आधुनिक UTF-8 HTML फ़ाइलों के लिए, गैर-ASCII एनकोड करना वैकल्पिक है — charset को सही ढंग से घोषित करना पर्याप्त है।

HTML एंटिटी बनाम URL एनकोडिंग बनाम Base64

HTML एंटिटी, URL एनकोडिंग (प्रतिशत-एनकोडिंग), और Base64 विभिन्न संदर्भों के लिए तीन अलग-अलग एनकोडिंग योजनाएँ हैं। HTML एंटिटी (जैसे &) का उपयोग HTML दस्तावेज़ों के अंदर वर्णों को सुरक्षित रूप से दर्शाने के लिए किया जाता है। URL एनकोडिंग (& के लिए %26 जैसे) का उपयोग क्वेरी स्ट्रिंग और URL में उन वर्णों को एनकोड करने के लिए किया जाता है जिनका URL में विशेष अर्थ होता है। Base64 मनमाने बाइनरी डेटा को ASCII टेक्स्ट के रूप में एनकोड करता है, डेटा URIs और ईमेल अटैचमेंट के लिए उपयोग किया जाता है।

एक सामान्य गलती इन्हें मिलाना है: HTML सामग्री के लिए URL-एनकोडिंग या URL के लिए HTML-एनकोडिंग का उपयोग करना। उदाहरण के लिए, URL क्वेरी स्ट्रिंग में एम्परसेंड को प्रतिशत-एनकोडिंग (%26) की आवश्यकता होती है, न कि HTML एंटिटी एनकोडिंग (&) की। यदि आप एक URL बनाते हैं जो बाद में HTML विशेषता में एम्बेड किया जाता है, तो आपको दोनों की आवश्यकता है: URL-एनकोडेड फ़ॉर्म विशेषता में जाती है, और विशेषता मान स्वयं HTML-एनकोड किया जाता है। यह समझना कि कौन सी एनकोडिंग किस संदर्भ में लागू होती है, डबल-एनकोडिंग बग और सुरक्षा समस्याओं को रोकता है।

अक्सर पूछे जाने वाले प्रश्न

›एम्परसेंड (&) के लिए HTML एंटिटी क्या है?

एम्परसेंड के लिए HTML एंटिटी & है — शाब्दिक रूप से &, a, m, p और सेमीकोलन वर्ण। जब आप HTML स्रोत में & लिखते हैं, तो ब्राउज़र एक एकल & वर्ण प्रदर्शित करता है। यह एनकोडिंग आवश्यक है जब भी एम्परसेंड टेक्स्ट सामग्री या विशेषता मानों में दिखाई दे, क्योंकि एक अन-एनकोडेड & एक एंटिटी अनुक्रम शुरू करता है जिसे पार्सर व्याख्या करने की कोशिश करता है।

›कॉपीराइट (©) के लिए HTML एंटिटी क्या है?

कॉपीराइट © के तीन समकक्ष HTML एंटिटी हैं: नामित ©, दशमलव संख्यात्मक ©, और हेक्साडेसिमल ©। सभी एक ही © वर्ण रेंडर करते हैं। नामित एंटिटी उपलब्ध होने पर सबसे अधिक पठनीय विकल्प है। आधुनिक UTF-8 HTML के लिए, आप © वर्ण सीधे भी टाइप कर सकते हैं — कोई एंटिटी आवश्यक नहीं — जब तक आपकी HTML फ़ाइल charset=utf-8 घोषित करती है।

›क्या मुझे HTML में उद्धरण चिह्नों को एनकोड करना होगा?

डबल उद्धरण चिह्नों (") को डबल उद्धरण चिह्नों द्वारा सीमांकित HTML विशेषताओं के अंदर " के रूप में एनकोड किया जाना चाहिए: <input value=""">। सिंगल उद्धरण चिह्नों (') को सिंगल-क्वोटेड विशेषताओं के अंदर ' या ' के रूप में एनकोड किया जाना चाहिए। एलिमेंट टेक्स्ट सामग्री के अंदर (टैग के बीच), दोनों उद्धरण चिह्न अन-एनकोडेड दिखाई दे सकते हैं, लेकिन उन्हें एनकोड करना हानिरहित है। सभी संदर्भों में दोनों को लगातार एनकोड करना सबसे सुरक्षित दृष्टिकोण है।

›नामित और संख्यात्मक एंटिटी में क्या अंतर है?

नामित एंटिटी एक वर्णनात्मक शब्द का उपयोग करती हैं (©, €, &hearts;) और HTML स्पेसिफिकेशन में परिभाषित होती हैं — हर Unicode वर्ण की नामित एंटिटी नहीं होती। संख्यात्मक एंटिटी Unicode कोड पॉइंट का उपयोग करती हैं, या तो दशमलव (€ के लिए €) या हेक्साडेसिमल (€ के लिए €) के रूप में। संख्यात्मक एंटिटी किसी भी Unicode वर्ण के लिए काम करती हैं, जबकि नामित एंटिटी केवल एक सबसेट को कवर करती हैं। दोनों ब्राउज़र में एक समान रेंडर होती हैं।

›क्या मुझे HTML में गैर-ASCII वर्णों को एनकोड करना चाहिए?

आमतौर पर नहीं। यदि आपका HTML दस्तावेज़ UTF-8 एनकोडिंग (meta charset=utf-8) घोषित करता है और UTF-8 के रूप में सहेजा गया है, तो आप गैर-ASCII वर्ण सीधे लिख सकते हैं: é, ñ, 中, 🎉। उन्हें एंटिटी के रूप में एनकोड करना वैकल्पिक है और स्रोत को पढ़ना मुश्किल बनाता है। अपवाद तब होता है जब ऐसे संदर्भों में HTML भेजा जाता है जो एनकोडिंग को संरक्षित नहीं कर सकते: ईमेल संदेश, लीगेसी API, या सिस्टम जो गैर-ASCII बाइट्स को दूषित करते हैं। उन मामलों में, सभी गैर-ASCII को संख्यात्मक एंटिटी के रूप में एनकोड करना सुनिश्चित करता है कि आउटपुट शुद्ध सुरक्षित ASCII है।

›XSS क्या है और HTML एंटिटी इसे कैसे रोकती हैं?

Cross-Site Scripting (XSS) एक सुरक्षा कमजोरी है जहाँ एक हमलावर एक वेबपेज में दुर्भावनापूर्ण JavaScript इंजेक्ट करता है ऐसे टेक्स्ट को सम्मिलित करके जिसे सर्वर बिना एनकोडिंग के HTML में परावर्तित करता है। उदाहरण के लिए, यदि उपयोगकर्ता इनपुट <script>alert('xss')</script> को सीधे एक पेज में डाला जाता है, तो ब्राउज़र स्क्रिप्ट निष्पादित करता है। यदि आप इनपुट को ठीक से एनकोड करते हैं — < को < और > को > में बदलते हैं — तो ब्राउज़र टेक्स्ट को शाब्दिक रूप से प्रदर्शित करता है बजाय इसे टैग के रूप में पार्स करने के। HTML एंटिटी एनकोडिंग रिफ्लेक्टेड और स्टोर्ड XSS के खिलाफ प्राथमिक रक्षा है।

›इस टूल की सूची में   क्यों नहीं दिखाई देता?

यह टूल उन वर्णों को एनकोड करता है जिनकी नामित एंटिटी होती हैं। नॉन-ब्रेकिंग स्पेस (Unicode U+00A0) को   के रूप में एनकोड किया जाता है जब आप वास्तविक नॉन-ब्रेकिंग स्पेस वर्ण टाइप करते हैं (जिसे कुछ सिस्टम पर Alt+Space से डाला जा सकता है या वर्ण मानचित्रों से कॉपी किया जा सकता है)। सामान्य स्पेस (U+0020, स्पेसबार) एनकोड नहीं होता क्योंकि यह एक सुरक्षित ASCII वर्ण है। यदि आपको विशेष रूप से आउटपुट में   की आवश्यकता है, तो इनपुट में एक नॉन-ब्रेकिंग स्पेस वर्ण टाइप करें या पेस्ट करें।

›क्या मैं उपयोगकर्ता इनपुट में HTML इंजेक्शन रोकने के लिए इसका उपयोग कर सकता हूँ?

हाँ — HTML में डालने से पहले उपयोगकर्ता द्वारा प्रदान किए गए टेक्स्ट को एनकोड करना HTML इंजेक्शन और XSS के खिलाफ मुख्य सुरक्षा में से एक है। न्यूनतम, पाँच आरक्षित वर्णों को एनकोड करें: &, <, >, ", '। यह टूल पाँचों को एनकोड करता है। हालाँकि, एनकोडिंग अकेले एक पूर्ण सुरक्षा समाधान नहीं है: आपको उचित Content Security Policy हेडर, विशेषताओं में javascript: URL की सावधानीपूर्वक हैंडलिंग, और फ्रेमवर्क-स्तरीय सुरक्षा की भी आवश्यकता है। प्रोडक्शन एप्लिकेशन के लिए, मैन्युअल एनकोडिंग के बजाय सुरक्षा के लिए डिज़ाइन किए गए सर्वर-साइड लाइब्रेरी (OWASP Java Encoder, क्लाइंट-साइड के लिए DOMPurify, आदि) का उपयोग करें।