HTML entity encoding کیسے کام کرتی ہے
ایک HTML entity ایک character reference ہے جسے براؤزر ایک واحد حرف میں واپس تبدیل کرتا ہے۔ پانچ محفوظ HTML حروف (<، >، &، "، ') کو ہمیشہ encoding کی ضرورت ہوتی ہے جب متن HTML کے طور پر render ہو؛ باقی سب اختیاری ہیں اور document encoding پر منحصر ہیں۔
- موڈ اور دائرہ منتخب کریں. Encode موڈ آپ کے ان پٹ کو حرف بہ حرف چلاتا ہے۔ Decode موڈ entity patterns کی تلاش میں ان پٹ کو اسکین کرتا ہے۔ Scope ٹوگل یہ فیصلہ کرتا ہے کہ صرف پانچ HTML-safe حروف انکوڈ ہوں یا ہر non-ASCII code point بھی۔
- Entity کی قسم منتخب کریں. Named entities (
©) source میں واضح نظر آتی ہیں۔ Decimal references (©) اور hex references (©) بغیر نام کے ہر Unicode code point کو cover کرتے ہیں۔ پرانے email clients اور XML parsers numeric شکلوں کو ترجیح دیتے ہیں۔ - ان پٹ کو پروسیس کریں. encode پر ہم ہر code point پڑھ کر اسے تقریباً 200 common named entities کی built-in table سے ملاتے ہیں۔ نہ ملنے پر numeric fallback۔ decode پر ہم ایک regex سے
&name;،&#NNN;، اور&#xHH;ایک ہی پاس میں scan کرتے ہیں۔ - حروف میں تبدیلی. Named matches ایک reverse table سے resolve ہوتے ہیں۔ Numeric matches
String.fromCodePointسے base 10 یا base 16 میں جاتے ہیں۔ نامعلوم named entities بغیر تبدیلی کے رہتی ہیں تاکہ جزوی ان پٹ بغیر نقصان کے round-trip کرے۔ - لائیو موڈ. لائیو موڈ آن کریں اور ہر keystroke 150 ms debounce کے ساتھ conversion دوبارہ چلاتی ہے۔ یہ تب مفید ہے جب آپ کوئی snippet ٹھیک کر رہے ہوں اور template میں paste کرنے سے پہلے فوری feedback چاہتے ہوں۔
HTML entities کیوں encode کریں
- صارف کے ان پٹ کو layout توڑنے سے روکیں. جب کوئی صارف comment box میں غلطی سے
<ٹائپ کرے تو وہ متن HTML میں ڈالنے سے باقی صفحہ بدل جاتا ہے۔ پہلے محفوظ حروف encode کرنے سے براؤزر اسے tag کی شروعات کی بجائے حرف کے طور پر render کرتا ہے۔ - attribute values کو درست رکھیں. HTML attribute کے اندر quoted string embed کرنے کے لیے embedded quote کو
"(double-quoted attrs کے لیے) یا'(single-quoted کے لیے) سے بدلنا ضروری ہے۔ ورنہ parser attribute جلد بند کر دیتا ہے اور باقی سطر stray markup بن جاتی ہے۔ - stored data میں حادثاتی HTML کو غیر فعال کریں. Logs، bug reports، اور chat exports میں اکثر real angle brackets اور ampersands ہوتے ہیں۔ documentation page میں paste کرنے سے پہلے dump کو entity-encode کرنے سے وہ copy متن کے طور پر نظر آتی ہے بجائے renderer یا link auto-detector trigger کرنے کے۔
- code snippets محفوظ طریقے سے شیئر کریں. blog post، email، یا Slack message میں
<script>alert(1)</script>جیسا مثالی tag post کرنے کے لیے brackets encode کرنا ضروری ہے تاکہ snippet run ہونے کی بجائے display ہو۔ یہی تکنیک RSS feed bodies اور JSON-LD `description` fields پر بھی لاگو ہوتی ہے۔
عام استعمال
Entity encoding ہر جگہ نظر آتی ہے جہاں خام متن runtime پر HTML میں compose ہوتا ہے — یہاں تک کہ جب framework عام طور پر اسے سنبھالتا ہو، جب وہ نہ سنبھالے تو manual ٹول مفید ہے۔
- Server-rendered templates: Jinja2، ERB، Twig، اور Handlebars by default auto-escape کرتے ہیں، لیکن raw blocks اور `safe` markers اسے بند کر دیتے ہیں — codec آپ کو confirm کرنے دیتا ہے کہ escape کیا produce کرتا۔
- Email اور newsletter authoring: بہت سے ESP templating engines merge fields کو auto-escape نہیں کرتے، اس لیے user-supplied names میں smart quotes اور copyright glyphs کو pre-encode کرنا پڑتا ہے۔
- Documentation اور code samples: Markdown blog post یا static-site snippet میں example HTML tag paste کرنے کے لیے brackets encode کرنے ضروری ہیں تاکہ renderer اسے visible text سمجھے۔
ایک عملی مثال
ان پٹ میں <script>alert('hi')</script> paste کریں، mode Encode، style Named، scope Minimal رکھیں۔ آؤٹ پٹ ہوگا <script>alert('hi')</script>۔ style کو Numeric hex میں بدلیں تو وہی ان پٹ <script>alert('hi')</script> produce کرتا ہے۔ mode کو Decode میں بدلیں، encoded string واپس paste کریں، اور اصل tag بحال ہو جاتا ہے۔
FAQ
HTML entities کیا ہیں؟
HTML entities وہ character references ہیں جنہیں براؤزر page parse کرتے وقت واحد حروف میں واپس تبدیل کرتا ہے۔ یہ تین شکلوں میں آتے ہیں: named (جیسے & برائے &)، decimal numeric (&)، اور hex numeric (&)۔ پانچ محفوظ HTML حروف (<، >، &، "، ') کو جب بھی متن HTML میں ڈالا جائے encoding کی ضرورت ہوتی ہے۔ باقی تقریباً 2,225 named entities symbols، accents، اور Greek حروف cover کرتے ہیں لیکن UTF-8 encoding ہونے پر اختیاری ہیں۔
Named بمقابلہ numeric entities کب استعمال کریں؟
Named entities اس وقت استعمال کریں جب آپ چاہتے ہیں کہ source واضح پڑھا جائے (template میں © دیکھنے والا انسان فوری سمجھ جاتا ہے)۔ Numeric (decimal یا hex) اس وقت جب consumer پرانا یا سخت ہو — XML parsers، legacy email clients، اور کچھ feed readers صرف HTML5 named entities کا ایک چھوٹا subset پہچانتے ہیں، اور سب numeric شکلیں پہچانتے ہیں۔ Hex security-focused سیاق و سباق میں فوقیت رکھتا ہے کیونکہ یہ spec documents میں Unicode code-point notation سے ہم آہنگ ہے۔
کیا decoding & جیسی hex entities handle کرتی ہے؟
جی ہاں۔ decoder ایک single regex استعمال کرتا ہے جو تینوں entity شکلیں ایک پاس میں match کرتا ہے: &name;، &#NNN;، اور &#xHH;۔ Numeric matches String.fromCodePoint سے base 10 یا base 16 میں resolve ہوتے ہیں۔ Mixed ان پٹ (ایک ہی string میں named اور numeric) صحیح decode ہوتا ہے، اور نامعلوم names literal text کے طور پر رہتے ہیں تاکہ جزوی ان پٹ بغیر نقصان کے round-trip کرے۔
کیا یہ untrusted ان پٹ کے ساتھ محفوظ ہے؟
codec خود browser-only ہے اور آپ کا ان پٹ کہیں نہیں بھیجتا۔ آؤٹ پٹ embed کرنا محفوظ ہے یا نہیں، یہ سیاق و سباق پر منحصر ہے۔ Entity encoding HTML body اور attribute-value contexts handle کرتی ہے، جو OWASP Rule #1 case cover کرتا ہے۔ JavaScript contexts (inline event handlers، `<script>` blocks)، CSS contexts، اور URL contexts — ہر ایک کے لیے الگ encoding rules ہیں — وہاں صرف entity encoding کافی نہیں۔ Server-side defence in depth کے لیے اسے DOMPurify یا آپ کے framework کے auto-escape کے ساتھ pair کریں۔
Browser-side entity encoding صارف کے ان پٹ اور rendered HTML کے درمیان سرحد پر ہوتی ہے۔ تبدیلی locally کرنے کا مطلب ہے کہ آپ یہ جانچ سکتے ہیں کہ آپ کا framework کیا emit کرتا، بغیر اصل متن کسی third-party ٹول کو بھیجے۔