Mag-encode o mag-decode ng HTML entity _

Paano gumagana ang HTML entity encoding

Ang HTML entity ay isang character reference na pina-parse ng browser pabalik sa isang character. Ang limang naka-reserbang HTML character (<, >, &, ", ') ay palaging kailangan ng encoding kapag ang teksto ay nire-render bilang HTML; ang lahat ng iba pa ay opsyonal at depende sa encoding ng dokumento.

1. Pumili ng mode at scope. Ang encode mode ay nagta-traverse ng iyong input character-by-character. Ang decode mode ay nagtataglay ng input na naghahanap ng mga entity pattern. Tinutukoy ng scope toggle kung ang lima lamang na HTML-safe na character ang iko-convert, o kung ang bawat non-ASCII code point ay mure-rewrite din.
2. Pumili ng entity style. Ang mga named entity (©) ay madaling basahin sa source. Ang mga decimal reference (©) at hex reference (©) ay nagdadala ng bawat Unicode code point nang hindi nangangailangan ng pangalan. Ang mga mas lumang email client at XML parser ay mas gusto ang numeric na form.
3. I-traverse ang input. Sa pag-encode, binabasa namin ang bawat code point at hina-hanap ito sa isang built-in na talahanayan ng humigit-kumulang 200 karaniwang named entity. Ang mga hindi natagpuan ay bumabalik sa numeric. Sa pag-decode, nag-i-scan kami gamit ang isang regex na tumutugma sa &name;, &#NNN;, at &#xHH; sa isang pass.
4. I-map sa mga character. Ang mga named match ay nire-resolve sa pamamagitan ng isang reverse na talahanayan. Ang mga numeric match ay dinadaan sa String.fromCodePoint na may base 10 o base 16. Ang mga hindi kilalang named entity ay iniiwanan nang hindi nababago para ang partial na input ay mag-round-trip nang walang pagkawala.
5. Live mode. I-toggle ang live mode at ang bawat keystroke ay muling nagpapatakbo ng conversion na may 150 ms debounce. Kapaki-pakinabang kapag nag-a-adjust ka ng snippet at gusto mo ng agarang feedback bago ito i-paste sa isang template.

Bakit mag-encode ng HTML entity

• Pigilan ang user input na masira ang layout. Kapag nag-type ang isang user ng isang stray na < sa isang comment box, ang pag-drop ng tekstong iyon direkta sa HTML ay nagsusulat muli ng natitirang bahagi ng page. Ang pag-encode ng mga naka-reserbang character muna ay nangangahulugang iri-render ng browser ang character sa halip na i-parse ito bilang simula ng isang tag.
• Panatilihing valid ang mga attribute value. Ang pag-embed ng isang quoted na string sa loob ng isang HTML attribute ay nangangailangan na ang embedded na quote ay mapalitan ng " (para sa double-quoted na attr) o ' (para sa single-quoted). Kung hindi man, ang parser ay maaga na isinasara ang attribute at ang natitirang bahagi ng linya ay nagiging stray markup.
• Alisin ang aksidental na HTML sa nakaimbak na data. Ang mga log, bug report, at chat export ay madalas na naglalaman ng tunay na angle bracket at ampersand. Ang entity-encoding ng dump bago ito i-paste sa isang documentation page ay nagpapanatiling visible ang kopyang iyon bilang teksto sa halip na mag-trigger ng renderer o ng link auto-detector.
• Ibahagi ang mga code snippet nang ligtas. Ang pag-post ng isang halimbawang tag tulad ng <script>alert(1)</script> sa isang blog post, email, o Slack message ay nangangailangan na ang mga bracket ay iko-encode para ang snippet ay magpakita sa halip na tumakbo. Ang parehong technique ay sumasaklaw sa mga RSS feed body at JSON-LD `description` field.

Mga karaniwang paggamit

Ang entity encoding ay lumalabas saanman ang raw na teksto ay nai-compose sa HTML sa runtime — kahit kapag ang framework ay karaniwang humahawak nito para sa iyo, ang manual na tool ay kapaki-pakinabang para sa mga sandaling hindi ito ginagawa.

• Mga server-rendered na template: ang Jinja2, ERB, Twig, at Handlebars ay awtomatikong nag-e-escape bilang default, ngunit ang mga raw block at `safe` marker ay nakakaalis niyon — pinapayagan ng codec na kumpirmahin mo kung ano ang gagawin ng escape.
• Email at newsletter authoring: maraming ESP templating engine ang hindi awtomatikong nag-e-escape ng merge field, kaya ang mga smart quote at copyright glyph sa mga user-supplied na pangalan ay nangangailangan ng pre-encoding.
• Dokumentasyon at mga code sample: ang pag-paste ng isang halimbawang HTML tag sa isang Markdown blog post o isang static-site snippet ay nangangailangan na ang mga bracket ay iko-encode para ang renderer ay ituturing itong visible na teksto.

Isang halimbawang trabaho

Mag-paste ng <script>alert('hi')</script> sa input na may mode na nakatakda sa I-encode, style Named, scope Minimal. Ang output ay nagbabasa ng <script>alert('hi')</script>. Palitan ang style sa Numeric hex at ang parehong input ay gumagawa ng <script>alert('hi')</script>. I-flip ang mode sa I-decode, i-paste pabalik ang encoded na string, at ang orihinal na tag ay bumabalik nang buo.

FAQ

Ano ang mga HTML entity?

Ang mga HTML entity ay mga character reference na pinapalitan ng browser pabalik sa mga single character kapag pina-parse nito ang page. Ang mga ito ay may tatlong form: named (tulad ng & para sa &), decimal numeric (&), at hex numeric (&). Ang limang naka-reserbang HTML character (<, >, &, ", ') ay nangangailangan ng encoding sa tuwing ang teksto ay idin-drop sa HTML. Ang iba pang humigit-kumulang 2,225 named entity ay sumasaklaw sa mga simbolo, accent, at Greek na letra ngunit opsyonal kapag ang encoding ng dokumento ay UTF-8.

Kailan dapat gumamit ng named kumpara sa numeric na entity?

Gumamit ng named entity kapag gusto mong mabasa nang malinaw ang source (ang isang tao na nagrerebyu ng © sa isang template ay naiintindihan agad ito). Gumamit ng numeric (decimal o hex) kapag ang consumer ay mas luma o mas mahigpit — ang mga XML parser, legacy email client, at ilang feed reader ay kinikilala lamang ang isang maliit na subset ng mga named entity ng HTML5, at lahat sila ay nakikilala ang mga numeric na form. Ang hex ay karaniwang nananalo sa mga security-focused na konteksto dahil ito ay tumutugma nang isa-isa sa Unicode code-point notation na ginagamit sa mga spec document.

Ginagamit ba ng decoding ang mga hex entity tulad ng &?

Oo. Ginagamit ng decoder ang isang regex na tumutugma sa lahat ng tatlong entity form sa isang pass: &name;, &#NNN;, at &#xHH;. Ang mga numeric match ay nire-resolve gamit ang String.fromCodePoint gamit ang base 10 o base 16. Ang mixed na input (named at numeric sa parehong string) ay nag-de-decode nang tama, at ang mga hindi kilalang pangalan ay iniiiwan bilang literal na teksto para ang partial na input ay mag-round-trip nang walang pagkawala.

Ligtas ba ito para gamitin sa hindi pinagkakatiwalaang input?

Ang codec mismo ay browser-only at hindi ipinapadala ang iyong input kahit saan. Kung ang output ay ligtas na i-embed ay depende sa konteksto. Ang entity encoding ay humahawak ng HTML body at attribute-value na konteksto, na sumasaklaw sa OWASP Rule #1 na kaso. Ang mga JavaScript konteksto (inline event handler, `<script>` block), CSS konteksto, at URL konteksto ay bawat isa ay nangangailangan ng sariling encoding na panuntunan — ang entity encoding lamang ay hindi sapat doon. Para sa isang server-side defence in depth, ipares ito sa isang context-aware na templating engine tulad ng DOMPurify o ang auto-escape ng iyong framework.

Ang browser-side entity encoding ay nasa hangganan ng pagitan ng user input at ng rendered na HTML. Ang paggawa ng conversion nang lokal ay nangangahulugang maaari mong ma-sanity-check kung ano ang inilabas ng iyong framework, nang hindi kailanman ipinapadala ang orihinal na teksto sa isang third-party na tool.