HTML एन्टिटी एन्कोडर / डिकोडर

HTML एन्टिटी कैसे काम करती हैं

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

मुझे कौन-सा मोड इस्तेमाल करना चाहिए?

• केवल HTML-विशेष — केवल & < > " ' एस्केप करता है। HTML में टेक्स्ट को सुरक्षित रूप से दिखाने या डालने के लिए आपको यही चाहिए; बाक़ी सब कुछ (उच्चारण-चिह्न, इमोजी, स्पेस) पठनीय छोड़ दिया जाता है।
• सभी नॉन-ASCII — नामित — सादे ASCII से ऊपर के हर वर्ण को भी एन्कोड करता है, जहाँ कोई नाम मौजूद हो वहाँ पठनीय नामित एन्टिटी (é, —) का उपयोग करके और अन्यथा दशमलव संख्यात्मक एन्टिटी पर वापस जाकर। मानव-पठनीय बने रहते हुए अधिकतम ईमेल/लेगेसी संगतता के लिए अच्छा।
• सभी नॉन-ASCII — दशमलव / हेक्स — हर नॉन-ASCII वर्ण को शुद्ध रूप से एक संख्यात्मक एन्टिटी (© या ©) के रूप में एन्कोड करता है। कहीं भी रेंडर होना गारंटीशुदा, और उन वर्णों के लिए सबसे सुरक्षित विकल्प जिनका कोई नाम नहीं है।

डिकोड किसी भी चीज़ पर काम करता है: यह हर नामित एन्टिटी (पूरी HTML5 सूची) और दशमलव तथा हेक्साडेसिमल दोनों संख्यात्मक एन्टिटी को — एस्ट्रल वर्ण और इमोजी सहित — वापस सादे टेक्स्ट में हल कर देता है, आपके इनपुट को कभी लाइव मार्कअप के रूप में डाले बिना।

सामान्य HTML एन्टिटी

सुझाव: ' HTML5 में मान्य है पर पुराने HTML में नहीं, इसलिए एन्कोड करते समय यह टूल एपॉस्ट्रॉफ़ी के लिए सार्वभौमिक रूप से सुरक्षित ' इस्तेमाल करता है।

HTML एन्टिटी का एक संक्षिप्त इतिहास

एन्टिटी उस वेब से भी पुरानी हैं जिसे अधिकांश लोग जानते हैं। HTML दरअसल SGML (ISO 8879) का एक अनुप्रयोग है, और इसने मूल स्मरक (mnemonic) नामों के साथ SGML का एन्टिटी सिंटैक्स विरासत में लिया। इन्हें औपचारिक बनाने वाला पहला वेब मानक, HTML 2.0 (RFC 1866, नवंबर 1995), दस्तावेज़ों को ISO-8859-1 (Latin-1) वर्ण-समुच्चय तक सीमित रखता था और SGML का "Added Latin 1" एन्टिटी सेट उधार लेता था ताकि लेखक © और é जैसे वर्ण केवल सादे ASCII से लिख सकें — उस दौर में यह ज़रूरी था जब ASCII से परे कुछ भी भरोसेमंद ढंग से भेजना एक जुआ था।

हर बाद के संशोधन ने सूची का विस्तार किया। आज WHATWG HTML मानक नामित वर्ण संदर्भों (named character references) की एक बहुत बड़ी तालिका परिभाषित करता है — 2,000 से अधिक (मशीन-पठनीय entities.json सूची, आम तौर पर 2,231 प्रविष्टियों के रूप में उद्धृत), जो मुद्रा, गणित, ग्रीक अक्षर, तीर, विराम-चिह्न और अन्य को कवर करती है। दूसरी ओर, संख्यात्मक संदर्भ किसी भी यूनिकोड वर्ण तक पहुँच सकते हैं चाहे उसका कोई नाम हो या न हो, इसीलिए दोनों प्रणालियाँ साथ-साथ मौजूद हैं।

वर्ण संदर्भ के तीन प्रकार

"एन्टिटी" रोज़मर्रा का शब्द है, पर स्पेसिफ़िकेशन का व्यापक शब्द वर्ण संदर्भ (character reference) है, और इसके तीन रूप हैं जो सब एक ही वर्ण उत्पन्न करते हैं:

• नामित वर्ण संदर्भ — &name;, एक पठनीय उपनाम जैसे &,   या ©। पढ़ने में सबसे आसान, पर केवल उन्हीं वर्णों के लिए काम करता है जिनका कोई परिभाषित नाम है।
• दशमलव संख्यात्मक संदर्भ — &#NN;, वर्ण का यूनिकोड कोड पॉइंट आधार 10 में (© = ©)।
• हेक्साडेसिमल संख्यात्मक संदर्भ — &#xNN;, वही कोड पॉइंट आधार 16 में (© = ©)। x बड़ा या छोटा अक्षर हो सकता है।

महत्वपूर्ण बात यह है कि HTML4 और HTML5 में एक संख्यात्मक संदर्भ किसी यूनिकोड कोड पॉइंट को नाम देता है, न कि किसी लेगेसी एन्कोडिंग में किसी बाइट को। इसीलिए यह टूल इमोजी और किसी भी लिपि का राउंड-ट्रिप कर सकता है — 😀 बस 😀 (दशमलव) या 😀 (हेक्स) है — और इसीलिए जब किसी वर्ण का कोई नाम न हो तो संख्यात्मक संदर्भ रेंडर-होने-की-गारंटी वाला विकल्प होते हैं।

पाँच पूर्वनिर्धारित एन्टिटी (और एपॉस्ट्रॉफ़ी वाला जाल)

XML — और इसलिए सख़्त XHTML, RSS और Atom फ़ीड — ठीक पाँच एन्टिटी पूर्वनिर्धारित करता है: &, <, >, " और '। HTML में हज़ारों नाम हैं, पर ये पाँच ही भार उठाने वाले हैं, क्योंकि ये उन वर्णों को एस्केप करते हैं जो वास्तव में मार्कअप को नियंत्रित करते हैं। एक मशहूर पेच है: ' XML और HTML5 में परिभाषित है, पर यह HTML4 का कभी हिस्सा नहीं था। कोई पुराना ब्राउज़र या सख़्त HTML4 पार्सर ' को शाब्दिक टेक्स्ट के रूप में दिखाएगा। संख्यात्मक ' हर जगह काम करता है, और ठीक इसीलिए यह टूल एपॉस्ट्रॉफ़ी के लिए सुंदर नाम के बजाय हमेशा ' उत्सर्जित करता है।

एस्केपिंग XSS के विरुद्ध पहली रक्षा-पंक्ति है

मात्र एक < दिखाने से आगे, HTML एस्केपिंग क्रॉस-साइट स्क्रिप्टिंग (XSS) के विरुद्ध प्राथमिक बचाव है। OWASP XSS Prevention Cheat Sheet का नियम यह है कि अविश्वसनीय डेटा को ठीक उसी क्षण एन्कोड करें जब उसे किसी पेज में लिखा जाता है, ताकि <script>…</script> जैसा कोई मान किसी निष्पादित टैग के बजाय निष्क्रिय टेक्स्ट बन जाए। पेच यह है कि एस्केपिंग संदर्भ-संवेदनशील (context-sensitive) है — HTML एन्टिटी एन्कोडिंग केवल एक ही जगह सही है:

इसीलिए " और ' वर्ण इतने मायने रखते हैं: किसी बिना-कोट या एकल-कोट वाले एट्रिब्यूट में, एक बिना-एस्केप किया कोट किसी हमलावर को एट्रिब्यूट जल्दी बंद करके onmouseover= जैसा कोई इवेंट हैंडलर इंजेक्ट करने देता है। HTML एन्टिटी एन्कोडिंग किसी स्क्रिप्ट, CSS नियम या URL में रखे डेटा की रक्षा नहीं करती — उन्हें अपनी अलग एन्कोडिंग चाहिए, जो भेद्यताओं का एक आम स्रोत है।

आपको वास्तव में एन्टिटी की ज़रूरत कब है (और कब नहीं)

एक व्यापक ग़लतफ़हमी है कि आपको हर उच्चारण-चिह्न वाले या ग़ैर-लैटिन वर्ण को एन्टिटी-एन्कोड करना ही पड़ता है। एक सही UTF-8 दस्तावेज़ के साथ आम तौर पर ऐसा नहीं है: é, 日本語 और 😀 अपने शाब्दिक रूप में बिल्कुल सही दिखते हैं। एन्टिटी मार्कअप सुरक्षा और लेगेसी संगतता के बारे में हैं, यूनिकोड का प्रतिनिधित्व करने के बारे में नहीं। इन्हें इस्तेमाल करने के असली कारण ये हैं:

• कोड को टेक्स्ट के रूप में दिखाना — <div> छापना ताकि पाठक ब्राउज़र द्वारा टैग रेंडर करने के बजाय शाब्दिक टैग देखे।
• XML / RSS / Atom फ़ीड, जो सख़्त होते हैं और नंगे &, < या > को अस्वीकार करते हैं।
• ईमेल और पुराने सिस्टम जिन पर UTF-8 होने का भरोसा नहीं किया जा सकता।
• इंजेक्शन रोकथाम, जैसा ऊपर बताया गया।
• स्मार्ट विराम-चिह्न — कर्ली कोट, एम डैश, © और ™ — उन वातावरणों के लिए जो ASCII से बाहर की किसी भी चीज़ को बिगाड़ देते हैं।

दो बातों से सावधान रहें। डबल-एन्कोडिंग तब होती है जब कोई एस्केप फ़ंक्शन दो बार चलता है, & को & और फिर & बना देता है, जिससे उपयोगकर्ता को पेज पर शाब्दिक & दिखता है — इसे सुलझाने के लिए इस टूल के Decode का उपयोग करें। Mojibake वह गड़बड़ टेक्स्ट है (é जहाँ é होना चाहिए) जो UTF-8 बाइट्स को Latin-1 की तरह पढ़ने से होता है; इसका असली समाधान एक सही charset घोषणा है, न कि कोई एन्टिटी टूल। और   — नॉन-ब्रेकिंग स्पेस, U+00A0 — "10 km" या "Mr. Smith" जैसी चीज़ों को पंक्ति-विराम पर टूटने से रोकता है; इसका उपयोग उसी के लिए करें, किसी लेआउट सहारे के रूप में नहीं (स्पेसिंग CSS बेहतर करता है)।

ब्राउज़र असल में एन्टिटी को कैसे पार्स करता है

डिकोडिंग में कुछ पेच जानने लायक हैं, जिन्हें यह टूल सब संभालता है। पश्च-संगतता (backward compatibility) के लिए, HTML5 पार्सर अब भी लेगेसी नामों के एक निश्चित समुच्चय को अंतिम अर्धविराम के बिना पहचानता है — &copy, &amp, &lt — जो ?x&copy=1 जैसे किसी URL के ?x©=1 बन जाने के पीछे का क्लासिक जाल है। अधिकांश नए नामों को अर्धविराम की ज़रूरत होती है। पार्सर जान-बूझकर कुछ संख्यात्मक संदर्भों को फिर से मैप भी करता है: एक NULL संदर्भ � प्रतिस्थापन वर्ण U+FFFD (�) बन जाता है; €–Ÿ श्रेणी के संख्यात्मक संदर्भ शाब्दिक C1 नियंत्रण कोड के बजाय उनके Windows-1252 वर्णों में मैप कर दिए जाते हैं (इसलिए “ और ” कर्ली कोट बन जाते हैं); और सरोगेट या श्रेणी-से-बाहर कोड पॉइंट के संदर्भ भी U+FFFD से बदल दिए जाते हैं। ये नियम स्पेसिफ़िकेशन में इसलिए पके हुए हैं ताकि गंदा वास्तविक-दुनिया का HTML भी अनुमानित ढंग से रेंडर हो।

वर्ण एन्कोडिंग बनाम वर्ण संदर्भ

दो चीज़ों को भ्रमित करना आसान है जो दोनों "वर्णों" से निपटती हैं। वर्ण एन्कोडिंग — आज लगभग हमेशा UTF-8 — यह है कि वर्णों को किसी फ़ाइल में संग्रहित और नेटवर्क पर भेजे जाने वाले असल बाइट्स में कैसे बदला जाता है। वर्ण संदर्भ (एन्टिटी) HTML/XML टेक्स्ट की एक विशेषता है, केवल ASCII का उपयोग करके किसी वर्ण को लिखने का तरीक़ा। ये अलग-अलग समस्याएँ हल करते हैं, और इनके संबंध को ग़लत समझना बहुत सारे गड़बड़ टेक्स्ट का स्रोत है।

मुख्य अंतर्दृष्टि: सही ढंग से घोषित <meta charset="utf-8"> के साथ, आपके दस्तावेज़ में असली वर्ण सीधे रह सकते हैं — café, €20, →, यहाँ तक कि 😀 — और वे एक भी एन्टिटी के बिना बिल्कुल सही दिखेंगे। एन्टिटी यूनिकोड को "समर्थन" देने का तरीक़ा नहीं हैं; UTF-8 यह पहले से कर देता है। एन्टिटी का सहारा केवल तभी लें जब आपको मार्कअप-महत्वपूर्ण वर्णों को निष्क्रिय करना हो, या जब कोई अनुगामी सिस्टम (कोई पुराना ईमेल गेटवे, कोई सख़्त XML पार्सर) UTF-8 संभालने के लायक भरोसेमंद न हो। एन्टिटी को charset के विकल्प की तरह मानना अति-एन्कोडेड, अपठनीय स्रोत की ओर ले जाता है; UTF-8 को वैकल्पिक मानना é की ओर ले जाता है जहाँ é होना चाहिए। हर काम के लिए सही उपकरण इस्तेमाल करें।

उन एन्टिटी की सैर जिन्हें आप वास्तव में इस्तेमाल करेंगे

हज़ारों नामित संदर्भों में से मुट्ठी भर ही लगभग सारा असल काम करते हैं। हर एक किसके लिए है यह जानना बहुत सारी अटकलबाज़ी बचा देता है:

•   (नॉन-ब्रेकिंग स्पेस) — दो शब्दों को एक ही पंक्ति पर रखता है, ताकि "10 km" या "Mr. Smith" कभी बेढंगे न टूटें। यह HTML को दोहराए गए स्पेस समेटने से भी रोकता है। इसे सोच-समझकर इस्तेमाल करें, किसी लेआउट हैक के रूप में नहीं।
• – और — — एन डैश (–, 2010–2020 जैसी श्रेणियों के लिए) और लंबा एम डैश (—, किसी वाक्य में विराम के लिए)। कई सिस्टम इन्हें बिगाड़ देते हैं, इसलिए एन्टिटी इन्हें भरोसेमंद बनाती हैं।
• स्मार्ट कोट — कर्ली सिंगल कोट के लिए ‘ ’ और कर्ली डबल के लिए “ ”। किसी वर्ड प्रोसेसर से कॉपी करने पर ये mojibake का एक क्लासिक स्रोत हैं, इसलिए इन्हें एन्कोड करने से टाइपोग्राफ़ी बरक़रार रहती है।
• क़ानूनी और वाणिज्यिक — © (©), ® (®) और ™ (™) कॉपीराइट, रजिस्टर्ड-ट्रेडमार्क और ट्रेडमार्क चिह्नों के लिए।
• गणित और इकाइयाँ — × (×), ÷ (÷), ° (°), ± (±) और तीर ← / →।

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

यह टूल सुरक्षित रूप से कैसे डिकोड करता है

डिकोडिंग सरल दिखती है पर एक असली जोखिम छिपाती है: अगर कोई टूल आपके टेक्स्ट को किसी लाइव HTML एलिमेंट में डालकर एन्टिटी हल करता, तो कोई दुर्भावनापूर्ण स्ट्रिंग कोई स्क्रिप्ट चला सकती थी। यह टूल इससे पूरी तरह बचता है। संख्यात्मक संदर्भ गणितीय रूप से हल होते हैं — कोड पॉइंट पढ़ा जाता है और सटीक वर्ण पुनर्निर्मित किया जाता है, बिल्कुल बिना किसी HTML के। नामित संदर्भ एक बार में एक साफ़ &name; टोकन के रूप में एक अलग एलिमेंट के माध्यम से हल होते हैं, और चूँकि ऐसा कोई टोकन ख़ुद कभी < या > नहीं रख सकता, इसलिए मार्कअप या स्क्रिप्ट के फिसल आने का कोई तरीक़ा नहीं है। उस तरीक़े का यह भी मतलब है कि डिकोडर पूरी HTML5 नामित तालिका का समर्थन करता है — उन 2,000-से-अधिक नामों में से हर एक — न कि बस कुछ चुने हुए, और वह भी पूरी तरह आपके डिवाइस पर रहते हुए। जो कुछ भी कोई मान्य, समाप्त एन्टिटी नहीं है उसे बस अछूता छोड़ दिया जाता है, इसलिए आपके टेक्स्ट में कोई आवारा & बिगड़ने के बजाय डिकोडिंग से बरक़रार बच निकलता है। परिणाम एक ऐसा डिकोडर है जो व्यापक और निर्माण से ही सुरक्षित दोनों है।

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

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

HTML एन्टिटी एक ऐसा कोड है जो किसी ऐसे वर्ण का प्रतिनिधित्व करता है जो HTML में आरक्षित है या जिसे टाइप करना मुश्किल है — इसे या तो नाम से (© के लिए &copy;) या संख्या से (&#169; या &#xA9;) लिखा जाता है। एन्टिटी आपको < > & जैसे वर्ण शाब्दिक रूप में दिखाने देती हैं, बजाय इसके कि ब्राउज़र उन्हें मार्कअप की तरह समझे।

मुझे & < > " और ' को कब एन्कोड करना चाहिए?

जब भी आप टेक्स्ट को HTML के अंदर रखते हैं। < और > टैग शुरू और ख़त्म करते हैं, & एक एन्टिटी शुरू करता है, और " तथा ' एट्रिब्यूट सीमांकित करते हैं — इसलिए उन्हें शाब्दिक रूप में दिखाना (या यूज़र टेक्स्ट को पेज में सुरक्षित रूप से डालना) मतलब उन्हें &lt; &gt; &amp; &quot; और &#39; से बदलना। “केवल HTML-विशेष वर्ण” मोड ठीक यही करता है।

नामित बनाम संख्यात्मक एन्टिटी — मुझे कौन-सी इस्तेमाल करनी चाहिए?

दोनों समतुल्य हैं। नामित एन्टिटी (&copy;, &mdash;) अधिक पठनीय हैं; संख्यात्मक एन्टिटी (&#169;, &#8212; या हेक्स &#xA9;) उन वर्णों के लिए भी काम करती हैं जिनका कोई नाम नहीं है और इनका रेंडर होना गारंटीशुदा है। दशमलव और हेक्स संख्यात्मक एन्टिटी परस्पर विनिमेय हैं — &#169; और &#xA9; दोनों © उत्पन्न करते हैं।

क्या यह इमोजी और ग़ैर-लैटिन लिपियों को संभालता है?

हाँ। एन्कोडिंग यूनिकोड कोड पॉइंट के हिसाब से चलती है, इसलिए इमोजी और एस्ट्रल-प्लेन वर्ण (जैसे 😀 = &#128512; / &#x1F600;) और 日本語 या हिंदी जैसी लिपियाँ बिलकुल सही एन्कोड और वापस डिकोड होती हैं, बिना किसी टूटे सरोगेट पेयर के।

क्या डिकोडिंग सुरक्षित है — क्या यह कोई स्क्रिप्ट चला सकती है?

नहीं। डिकोडिंग आपके टेक्स्ट को कभी लाइव HTML के रूप में नहीं डालती। संख्यात्मक एन्टिटी उनके कोड पॉइंट से गणितीय रूप से हल होती हैं, और नामित एन्टिटी एक बार में एक साफ़ &name; टोकन के रूप में हल होती हैं, इसलिए मार्कअप या स्क्रिप्ट के चलने का कोई तरीक़ा नहीं है। सब कुछ आपके डिवाइस पर ही रहता है।

क्या कुछ भी किसी सर्वर पर अपलोड होता है?

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

संबंधित टूल

• URL एन्कोड / डिकोड
• Base64 एन्कोडर / डिकोडर
• JSON फ़ॉर्मैटर और वैलिडेटर
• Regex टेस्टर
• केस कन्वर्टर
• टेक्स्ट से हेक्स

सभी डेवलपर और डेटा रूपांतरण देखें →