HTML Entity Pengkode / Pengdekode
Konversi karakter khusus ke entitas HTML dan sebaliknya.
Entitas HTML umum
| Karakter | Entitas | Numerik | Deskripsi |
|---|---|---|---|
| & | & | & | Ampersand |
| < | < | < | Lebih kecil dari |
| > | > | > | Lebih besar dari |
| " | " | " | Tanda kutip ganda |
| ' | ' | ' | Tanda kutip tunggal |
| |   | Spasi tak terputus | |
| © | © | © | Hak cipta |
| ® | ® | ® | Merek terdaftar |
| ™ | ™ | ™ | Merek dagang |
| € | € | € | Tanda Euro |
Mengapa menggunakan entitas HTML?
Karakter seperti <, >, dan & memiliki makna khusus di HTML. Jika Anda menyertakannya secara harfiah dalam HTML Anda, browser menafsirkannya sebagai kode, bukan sebagai konten. Mengenkode karakter-karakter ini sebagai entitas mencegah masalah rendering dan kerentanan cross-site scripting (XSS).
Pertanyaan umum
Apa perbedaan antara entitas bernama dan numerik?
Entitas bernama menggunakan nama deskriptif (&, ©) sedangkan entitas numerik menggunakan titik kode Unicode (&, ©). Keduanya ditampilkan secara identik. Entitas bernama lebih mudah dibaca; entitas numerik berfungsi untuk karakter Unicode apa pun.
Apakah saya harus mengenkode semua karakter khusus?
Setidaknya, Anda harus mengenkode &, <, >, dan " dalam konten HTML dan nilai atribut. Browser modern menangani sebagian besar karakter lainnya secara native jika dokumen Anda menggunakan pengkodean UTF-8.
Tiga bentuk, satu karakter
«Entitas» HTML, secara formal disebut referensi karakter: adalah urutan escape yang merepresentasikan satu karakter menggunakan urutan karakter ASCII biasa. HTML Living Standard mendefinisikan tiga bentuk sintaktis konkret:
- Bernama:
&diikuti nama dari tabel referensi karakter bernama WHATWG, diakhiri dengan titik koma. Contoh:©untuk ©. - Numerik desimal:
&#diikuti code point Unicode dalam basis 10, diakhiri dengan titik koma. Contoh:©. - Numerik heksadesimal:

iikuti code point dalam basis 16, diakhiri dengan titik koma. Contoh:©.
Ketiga bentuk dapat dipertukarkan saat dirender: ©, ©, dan © semuanya menghasilkan karakter terlihat © karena semuanya menyelesaikan ke code point Unicode U+00A9. Pilihan di antara mereka adalah masalah keterbacaan kode sumber, bukan perilaku browser. Heks cenderung cocok dengan bagan Unicode yang diterbitkan (yang menggunakan notasi U+XXXX), sehingga ♥ lebih dekat ke notasi resmi U+2665 daripada ♥. Referensi numerik berfungsi untuk karakter Unicode apa pun, termasuk emoji astral-plane, 😀 merender sebagai 😀 (U+1F600 GRINNING FACE).
Mengapa entitas ada
Tiga alasan historis dan praktis yang berbeda:
- Untuk meng-escape karakter yang memiliki arti sintaktis dalam HTML. Parser menggunakan karakter ASCII tertentu sebagai simbol kontrol.
<membuka tag,>menutupnya,&memperkenalkan referensi, dan karakter kutipan membatasi nilai atribut. Jika Anda ingin salah satu dari itu muncul sebagai teks literal, Anda harus meng-escape-nya. - Untuk merepresentasikan karakter yang tidak tersedia dalam encoding dokumen. Sebelum UTF-8 menjadi universal di web (baru melampaui tanda 50% sekitar 2010), sebagian besar HTML disajikan sebagai US-ASCII, ISO-8859-1, atau Windows-1252. Dalam encoding satu-byte tersebut, karakter seperti ©, €, ≈, atau α sama sekali tidak bisa diekspresikan dalam satu byte literal. Menulis
©,€, atau≈adalah satu-satunya cara untuk mencapai code point tersebut. - Untuk menandai maksud penulis untuk karakter yang tidak terlihat atau ambigu. Bahkan di halaman UTF-8, spasi non-breaking literal (U+00A0) secara visual identik dengan spasi biasa, menulis
membuat maksudnya jelas bagi siapa pun yang membaca sumbernya.
W3C kini merekomendasikan menggunakan karakter Unicode literal di mana pun memungkinkan daripada entitas, «untuk aksesibilitas dan keterbacaan». Entitas tetap berguna untuk lima escape yang diperlukan, ditambah karakter yang benar-benar tak terlihat atau ambigu.
Lima Besar
Lima karakter yang mutlak harus di-escape saat menyisipkan konten yang tidak tepercaya ke HTML adalah <, >, &, ", dan '. Cheat Sheet Pencegahan Cross-Site Scripting OWASP menyebutkannya sebagai set escape minimum yang diperlukan:
| Karakter | Bernama | Desimal | Heks |
|---|---|---|---|
| < | < | < | < |
| > | > | > | > |
| & | & | & | & |
| " | " | " | " |
| ' | ' / ' | ' | ' |
Aturan praktis: setiap kali Anda menempatkan teks yang tidak tepercaya ke keluaran HTML, escape kelima karakter ini terlebih dahulu. Kegagalan melakukannya adalah akar penyebab dari mayoritas besar kerentanan XSS yang tersimpan dan terefleksikan.
Perangkap apostrof
' bukan bagian dari HTML 4, awalnya hanya didefinisikan oleh XML 1.0 dan diwarisi ke XHTML 1.0. Internet Explorer sebelum versi 9 (dirilis 2011) menolak merendernya sebagai ' dan akan menampilkan teks literal '. Entitas tersebut ditambahkan ke HTML5 secara khusus dan kini aman di setiap browser modern, tetapi untuk kompatibilitas lintas-browser dan lintas-spec maksimum OWASP dan sebagian besar library sanitisasi enterprise masih merekomendasikan memancarkan ' alih-alih ' saat meng-escape kutipan tunggal, terutama dalam kode yang kritis keamanan.
Kapan harus meng-encode) dan kapan tidak
Keputusan encoding bergantung pada di mana teks akan mendarat di keluaran, bukan apa isinya. Ini adalah poin yang paling sering disalahpahami dalam keamanan HTML. Panduan OWASP membedakan konteks:
- Konten elemen HTML: escape
< > & "(dan'untuk paranoia). - Nilai atribut HTML: escape hal yang sama ditambah karakter kutipan; selalu gunakan atribut yang dikutip.
- Konteks JavaScript: gunakan escape JavaScript, bukan escape HTML:
\xHHatau\uHHHH. - Konteks CSS: gunakan escape CSS:
\HHdiikuti spasi. - Konteks URL / URI parameter: gunakan persen-encoding (
%HH), bukan encoding HTML.
Setiap konteks memiliki aturan escape-nya sendiri. Mencampurkannya sendiri merupakan kerentanan, misalnya, persen-encoding < menjadi %3C tidak melindungi terhadap XSS dalam konteks elemen HTML, di mana %3C hanyalah teks literal %3C.
Hindari double-encoding. Bug umum adalah meng-escape data saat dibaca ke sistem, lagi saat disimpan, lagi saat dibaca keluar, dan lagi saat dirender. Hasilnya: pengguna mengetik 5 < 10, database menyimpan 5 &lt; 10, halaman merender 5 < 10 alih-alih yang asli. Disiplinnya adalah: simpan Unicode mentah, encode sekali, pada saat keluaran, untuk konteks tertentu.
Encoding HTML vs encoding URL
Dua sistem escape yang berbeda untuk dua konteks yang berbeda, sering tertukar:
| Entitas HTML | URL / persen | |
|---|---|---|
| Standar | HTML Living Standard | RFC 3986 |
| Format | &name; atau &#NN; | %HH (byte heks) |
| Konteks | Markup HTML, body elemen dan atribut | URL, string query, body request yang di-form-encode |
| Spasi | (non-breaking), jangan gunakan spasi biasa | %20 atau + |
| Fungsi JS | - (ditangani parser) | encodeURIComponent() / encodeURI() |
URL di dalam nilai atribut HTML mendapat keduanya berlapis: persen-encoding untuk karakter yang tidak diizinkan URL terlebih dahulu, kemudian encoding HTML untuk & < > " apa pun dalam URL yang dihasilkan. Inilah mengapa ampersand dalam string query di dalam atribut href menjadi & dalam serialisasi HTML.
Sejarah singkat
HTML 2.0 (RFC 1866, 1995) mewarisi mekanisme entitas SGML dengan sekitar 50 entitas bernama untuk ISO Latin 1. HTML 3.2 (W3C, Januari 1997) menambahkan entitas matematika dan simbol. HTML 4.01 (W3C, Desember 1999) menyelesaikan tiga set entitas (Latin-1, Khusus, dan Simbol) dengan total 252 entitas bernama, yang merupakan sumber angka «252» yang masih terlihat dalam tutorial lama. HTML5 / WHATWG (Living Standard, sedang berlangsung) menyerap dan secara dramatis memperluas tabel ke lebih dari 2.000 entri, terutama untuk mencakup MathML dan set Unicode yang lebih luas. XML 1.0 (1998) mendefinisikan set minimal sendiri hanya Lima Besar (< > & " '), set minimal tersebut adalah asal dari '.
Pertanyaan lainnya
Dalam kode modern, apa yang seharusnya saya gunakan?
Kode produksi umumnya tidak membuat encoding entitas secara manual, ia memanggil library. DOMPurify untuk sanitisasi HTML sisi klien. html.escape() di library standar Python. htmlspecialchars() di PHP. html/template di Go (auto-escape aktif secara default). OWASP Java Encoder untuk Java. Di React, menulis <div>{userInput}</div> meng-escape secara otomatis; escape hatch dangerouslySetInnerHTML dinamai untuk mencegah penggunaan sembarangan. Encoder mandiri seperti ini berguna sebagai alat sanity-check / debugging, bukan pengganti library tersebut.
Bagaimana dengan tag di dalam template email?
Klien email lama (Outlook khususnya) menginterpretasikan & yang tidak di-encode sebagai atribut yang salah format dan dapat menghapus markup di sekitarnya. Developer email HTML belajar meng-encode-entitas setiap karakter khusus secara defensif. Hal yang sama berlaku untuk sistem BBCode-style forum yang menulis ulang konten sebelum menyimpannya; round-trip dapat memperkenalkan entitas literal yang tidak diharapkan.
Apa perbedaan textContent vs innerHTML di JavaScript?
Aturan pencegahan XSS terpenting dalam vanilla JavaScript: gunakan element.textContent = userInput daripada element.innerHTML = userInput. Menyetel textContent menulis string sebagai teks literal, browser menangani semua escaping secara internal. Menyetel innerHTML mem-parse string sebagai HTML, mengeksekusi tag <script> atau atribut event-handler yang dikandungnya. Jika markup benar-benar diperlukan, gunakan library seperti DOMPurify untuk sanitisasi terlebih dahulu.
Bisakah encoder menangani emoji?
Ya, melalui referensi numerik. Tidak ada entitas bernama untuk emoji, semuanya menggunakan bentuk numerik. 😀 merender sebagai 😀, ❤️ sebagai hati merah ❤️ (code point hati ditambah selector presentasi emoji). Browser menangani konversi surrogate-pair UTF-16 implisit secara internal; Anda tidak boleh menulis setengah surrogate secara manual.
Apakah ada yang dikirim ke server?
Tidak. Encoding dan decoding adalah transformasi string fungsi-murni yang berjalan sepenuhnya di browser Anda melalui JavaScript. Tidak ada tentang input Anda yang diunggah; halaman bekerja secara offline setelah dimuat. Ini penting karena encoder berbasis cloud yang membolak-balik payload pengujian Anda sendiri dapat menjadi vektor XSS jika situs pengujian dikompromi.