Which characters must be escaped in HTML?

Five: the ampersand, less-than, greater-than, double quote, and single quote — written as &, <, >, ", and '. Ampersand, because it starts entities; the angle brackets, because they delimit tags; the quotes, because they delimit attribute values. In element body text you can get away with just the first three, but escaping all five everywhere is the habit that never bites you. Everything else — accents, dashes, emoji — can be raw UTF-8 on a properly declared page.

What is the difference between < written as a named entity and <?

Nothing, once the browser parses them — both produce a less-than sign. The named form is a lookup in the WHATWG standard's table of named references; < addresses Unicode code point 60 directly, and < is the same code point in hex. Named entities are easier for humans to read; numeric references work for all characters, including thousands that have no name. For the common specials, pick whichever your team finds more readable — browsers do not care.

Why does my page show & instead of an ampersand?

Double escaping. Some layer of your stack escaped an already-escaped string, turning & into &. The browser decodes one level and displays the leftover. It usually means two components both think escaping is their job — a CMS on save plus a template on render is the classic pair. Decode the string one pass at a time in a decoder; the number of passes until it reads clean equals the number of layers escaping it. Then make exactly one layer responsible, at output time.

Does escaping HTML prevent XSS?

In HTML body and attribute contexts, yes — entity-encoding untrusted input there is the core defense, because the payload renders as inert text. But it is not sufficient everywhere. The OWASP XSS Prevention Cheat Sheet is explicit that JavaScript strings, URLs, and CSS each need their own context-specific encoding; entity encoding inside a script block does nothing. Escape at output, in the context you are outputting into, using that context's encoder. Entity encoding is one tool in that kit, not the whole kit.

What is the difference between htmlspecialchars and htmlentities in PHP?

htmlspecialchars() escapes only the markup-significant characters — and you should pass ENT_QUOTES so it covers the single quote. htmlentities() converts every character that has a named entity, so accented letters become things like the uuml reference. On UTF-8 pages, htmlspecialchars() is almost always what you want; htmlentities() bloats output and causes mojibake when charsets are misconfigured. WordPress developers mostly avoid the question by using esc_html() and esc_attr(), which apply the right flags per context.

Should I use the apos named entity for apostrophes?

Prefer '. The apos name is valid in HTML5 but was never part of HTML4, so older parsers — including the rendering engines inside some email clients — do not recognize it and will display it literally. The numeric form ' means the same character and works in everything ever shipped. It is an ugly-but-safe choice, which is usually the right trade-off for escaping. If you know your output only ever hits modern browsers, apos is fine; email templates are exactly where you cannot know that.

Is it safe to paste user data into an online entity converter?

Only if the tool processes text in your browser. User-generated content and email templates routinely contain names, emails, and other PII, and a converter that posts your input to a server has just received that data with no agreement in place. The toolz.dev HTML Entities Encoder/Decoder runs 100% client-side — no upload, no logging, and it works offline once the page has loaded. If you cannot verify how a tool handles input, do not paste production data into it.

מפענח מקודד ישות HTML: בריחה, ביטול בריחה והפסקת משלוח ומגבר; מגבר; לייצור

Q: What is an HTML entity?

An HTML entity is a text sequence that represents a character instead of writing the character directly. It starts with an ampersand and ends with a semicolon. There are named references like & and ©, and numeric references like © (decimal) or © (hex) that point at a Unicode code point. Browsers resolve them while parsing, so < displays as a less-than sign instead of opening a tag. They exist so you can show characters that would otherwise be interpreted as markup.

Q: What is the difference between < written as a named entity and <?

Nothing, once the browser parses them — both produce a less-than sign. The named form is a lookup in the WHATWG standard's table of named references; < addresses Unicode code point 60 directly, and < is the same code point in hex. Named entities are easier for humans to read; numeric references work for all characters, including thousands that have no name. For the common specials, pick whichever your team finds more readable — browsers do not care.

Q: Why does my page show &amp; instead of an ampersand?

Double escaping. Some layer of your stack escaped an already-escaped string, turning & into &amp;. The browser decodes one level and displays the leftover. It usually means two components both think escaping is their job — a CMS on save plus a template on render is the classic pair. Decode the string one pass at a time in a decoder; the number of passes until it reads clean equals the number of layers escaping it. Then make exactly one layer responsible, at output time.

Q: Does escaping HTML prevent XSS?

In HTML body and attribute contexts, yes — entity-encoding untrusted input there is the core defense, because the payload renders as inert text. But it is not sufficient everywhere. The OWASP XSS Prevention Cheat Sheet is explicit that JavaScript strings, URLs, and CSS each need their own context-specific encoding; entity encoding inside a script block does nothing. Escape at output, in the context you are outputting into, using that context's encoder. Entity encoding is one tool in that kit, not the whole kit.

Q: What is the difference between htmlspecialchars and htmlentities in PHP?

htmlspecialchars() escapes only the markup-significant characters — and you should pass ENT_QUOTES so it covers the single quote. htmlentities() converts every character that has a named entity, so accented letters become things like the uuml reference. On UTF-8 pages, htmlspecialchars() is almost always what you want; htmlentities() bloats output and causes mojibake when charsets are misconfigured. WordPress developers mostly avoid the question by using esc_html() and esc_attr(), which apply the right flags per context.

Q: Should I use the apos named entity for apostrophes?

Prefer '. The apos name is valid in HTML5 but was never part of HTML4, so older parsers — including the rendering engines inside some email clients — do not recognize it and will display it literally. The numeric form ' means the same character and works in everything ever shipped. It is an ugly-but-safe choice, which is usually the right trade-off for escaping. If you know your output only ever hits modern browsers, apos is fine; email templates are exactly where you cannot know that.

Q: Is it safe to paste user data into an online entity converter?

Only if the tool processes text in your browser. User-generated content and email templates routinely contain names, emails, and other PII, and a converter that posts your input to a server has just received that data with no agreement in place. The toolz.dev HTML Entities Encoder/Decoder runs 100% client-side — no upload, no logging, and it works offline once the page has loaded. If you cannot verify how a tool handles input, do not paste production data into it.

בסביבות 2021, כרטיס תמיכה של WP Adminify נחת עם צילום מסך שעדיין גורם לי להתכווץ. משתמש קבע טקסט כותרת תחתונה מותאם אישית של מנהל מערכת - שורת זכויות יוצרים תמימה לחלוטין עם א © וקישור לסוכנות שלהם על המסך שלהם זה מוצג כ &copy; 2021 &mdash; Bright &amp; Co. שלוש ישויות גלויות, אפס תווים מעובדים האשם היה אני שגרת השמירה שלי ברחה מהטקסט, שגרת הרינדור שלי ברחה ממנו שוב, ואיפשהו בין לבין מסנן ברח ממנו בפעם השלישית. עד שזה פגע בדפדפן, האמפרסנד המסכן הזה נמלט ארבע פעמים. ספרתי.

התיקון לקח עשר דקות מציאתו לקח שני ערבים, כי נמלט טקסט נראה כמעט ימין. אתה מרפרף &copy; במזבלה של מסד נתונים והמוח שלך מתקן אותו אוטומטית ל ©. בסופו של דבר הדבקתי מחרוזות בקובץ HTML שריטה שוב ושוב רק כדי לראות מה הדפדפן באמת יעבד בכל שכבה. That's זרימת עבודה אומללה, וזה's בדיוק למה מפענח מקודד ישות HTML הוא אחד הכלים הראשונים שבניתי ב-Toolz.dev.

הצד ההפוך של אותו מטבע מפחיד יותר כמה חודשים לפני הכרטיס הזה, במהלך סקירת קוד של התוסף שלי, מצאתי שדה הגדרות שהדהד קלט משתמש להודעת מנהל ללא esc_html(). כל מי שיש לו גישה לשדה זה יכול היה לאחסן <script> והפעיל אותו עבור כל מנהל שטען את הדף. מאוחסן XSS, בקוד שלי, במרחק קריאת פונקציה אחת חסרה. אף אחד לא ניצל את זה - התמזל מזלי. אבל זה שינה לצמיתות את איך שאני חושב לברוח: it's לא מטלת עיצוב, it's הגבול בין "text" ו-"code."

אז המדריך הזה מכסה את שני הכיוונים. קידוד, אז טקסט לא מהימן נשאר טקסט. פענוח, כדי שתוכל לקרוא מה התבלבל איזה צינור להוט מדי. ומספיק תיאוריה - שם לעומת הפניות מספריות, חמשת התווים החשובים למעשה, מדוע סדר הפעולות גורם לבריחה כפולה - שתוכל לנפות באגים בדברים האלה במקום לנחש.

TL;DR: הדבק את הטקסט שלך לתוך Toolz.dev HTML Entities מקודד/מפענח כדי להמיר בין תווים גולמיים וישויות בכל כיוון - בשם, עשרוני או משושה. הוא פועל ב-100% בצד הלקוח, כך שתוכן המשתמש וה-PII לעולם לא עוזבים את הדפדפן שלך. כלל אצבע: תמיד לברוח מחמשת המבצעים (& < > " ') בקלט לא מהימן, וקודד & קודם או אתה'll בריחה כפולה.

תכונות מפתח

קידוד ופענוח בשני הכיוונים

חצי מהזמן אני צריך לפנות <script> לתוך <script> אז זה מוצג כטקסט בפוסט בבלוג. החצי השני I' אני הולך בכיוון ההפוך - הופך מגורד &#8217;s חזרה לתוך אפוסתרוף קריא הכלי מטפל בשניהם הדבק טקסט, בחר קידוד או פענוח, בוצע אין ציד מצבים, אין כלים נפרדים לכל כיוון זה נשמע טריוויאלי עד שאתה & #39; השתמשת בכלים שמפענחים רק, ואתה מוצא את עצמך פותח כרטיסייה שנייה כדי לקודד דגימת קוד עבור המסמכים שלך. נסיעה הלוך ושוב היא גם בדיקת שפיות נהדרת: מקודד, מפענח ומאשר שאתה מקבל את המחרוזת המקורית שלך בחזרה. אם אתה עושה 't, משהו בקלט שלך כבר נמלט חלקית - וזה עצמו מידע שימושי.

ישויות בשם: &amp;, &lt;, &copy; וחברים

הפניות לדמויות בשם הן אלו הניתנות לקריאה על ידי אדם - & עבור &, < עבור <, © עבור ©, — עבור em-dash. הכלי נושא טבלה אוצרת של 147 שמות, לא רק חמשת המפורסמים: טיפוגרפיה ( , …, ’, “), מטבע, מתמטיקה וחצים, אותיות יווניות, הטווח המלא של מבטא לטיני-1, וכמה סיכויים כמו חליפות קלפים. הטווח הזה הוא מה שתוכן בעולם האמיתי צריך בפועל - וורדפרס פולטת  , …, ו ’ באמצעות wptexturize ללא הרף, ומפענח שיודע רק תריסר שמות משאיר חצי מהטקסט שלך זרוע הפניות לא פתורות.

היה ברור מה זה 147 לא: ה WHATWG תקן HTML מגדיר למעלה מ-2,200 הפניות עם שם, כך שזו תת-קבוצה מעשית ולא הטבלה השלמה. אם שם הוא 't בו, פענוח משאיר את ההפניה ללא נגיעה במקום לנחש - &bogus; יוצא כמו &bogus;. לקידוד יש את ההתנהגות המשלימה, והוא ' החצי השימושי יותר: כל תו ללא שם בטבלה נופל בחזרה להפניה מספרית עשרונית באופן אוטומטי, כך ששום דבר לעולם לא נשמט בשקט. אימוג'י מקודד כ 🌍, טקסט סיני כמו 你好. שמות היכן שהם קיימים, מספרים בכל מקום אחר.

סטייה נוספת מהתנהגות הדפדפן שכדאי לדעת: המפענח רגיש לאותיות גדולות ודורש נקודה-פסיק. דפדפנים יפתרו &COPY; ואפילו חשוף &amp ללא נקודה-פסיק נגררת בהקשרי ניתוח מסוימים, הודות לכללי תאימות מדור קודם; המפענח הזה לא פותר אף אחד מהם. בפועל ' בסדר - כל דבר הוא כלי מודרני מייצר הוא אותיות קטנות ומסתיים - אבל אם אתה ' מפענחים HTML מגורד מ-CMS עתיק, זה 's הקצה שאתה 'll פגע.

הפניות מספריות: עשרוני והקסדצימלי

כל יוניקוד ניתן לכתוב תו כהפניה לתו מספרי - דמוי עשרוני — או hex כמו — (שניהם הם em-dash) המפענח פותר את שתי הצורות זהו פתח המילוט לדמויות שאין להן שם בתקן, וזה 's הטופס you' ייפגש ללא הרף בתגובות API והזנות RSS, שם ’ (ציטוט יחיד ימני) הוא למעשה חתימה.Hex מפנה מפה ישירות לנקודות קוד Unicode - U+2014 הוא —- וזו הסיבה שאני מעדיף אותם כאשר I'm מצליב מול תרשים Unicode.

מגבלה כנה, מכיוון שאתה ' תבחין בכך תוך דקה מהשימוש בכלי: המספרי לקודד מצב פולט עשרוני בלבד. There's אין אפשרות פלט משושה. פִּענוח — עובד בסדר; לבקש מהמקודד לייצר אותו doesn't. שתי הצורות זהות מבחינה סמנטית לכל דפדפן, כך שזה לא עולה לך כלום מבחינה פונקציונלית, אבל אם בסיס הקוד שלך מתקנן ב-hex אתה' תמיר ביד. It's ברשימה שלי. הפניות מחוץ לטווח נתפסות ולא מעוותות - &#1114112; נמצא מעל המקסימום של Unicode ומחזיר שגיאה מפורשת במקום תו חלופי.

כיסוי Unicode מלא

Emoji, CJK תווים, ערבית, שילוב diacritics, העבודות אם יש לו נקודת קוד, הכלי יכול לבטא אותו כישות ולפתור אותו בחזרה זה משנה יותר ממה שאתה & #39;d חושב לעבודה לוקליזציה - I & #39;ve ניפוי באגים אומלאוטים גרמניים מגיעים כ ü מספק תרגום אחד וכ-UTF-8 גולמי ü מאחר, באותו קובץ ייבוא כלי שנחנק מחוץ ללטינית-1 הוא חסר תועלת בשביל זה תווים מעל U+FFFF (אימוג'י חי שם למעלה) מטופלים בצורה נכונה כנקודות קוד בודדות, לא זוגות פונדקאים מעוותים.

מבטל טקסט בעל בריחה כפולה

ה &amp; בְּעָיָה. כאשר שתי שכבות של צינור בורחות שתיהן, & הופך &amp;- ושלוש שכבות נותן לך &amp;amp;. פענוח פעם אחת מתקלף בדיוק שכבה אחת, כך שתוכל להפעיל את המפענח שוב ושוב ולראות את הבצל מתפרק: &amp;amp; → &amp; → & → &. ספירת המעברים אומרת לך כמה שכבות מהערימה שלך בורחות, וזה בדיוק האבחון שהייתי צריך במהלך אותו באג תחתון WP Adminify שנמלט פי ארבעה. פענוח אחד לכל שכבה. זה ' הדרך המהירה ביותר שאני מכיר למקם היכן בצינור מתרחשת הבריחה הנוספת.

חלונות זה לצד זה עם ספירת דמויות

קלט משמאל, פלט מימין, תו סופר מעל שניהם צמד הספירות הזה עושה יותר עבודה ממה שזה נשמע: בריחה היא פעולה מתרחבת, אז אם אתה מקודד 40 תווים ומקבל 44 בחזרה, בדיוק תו אחד מיוחד נגע. כאשר I'm אודיטינג אם תבנית כבר ברחה ממשהו, הדלתא אומרת לי לפני I' קראתי תו בודד של פלט. קידוד, פענוח, החלפה ו-Clear הם כפתורים - שם' אין המרה חיה כפי שאתה מקליד, מה ש-I' אני מודה שהוא פשרה מכוונת שלפעמים אני מתחרט עליה. פעולות מפורשות אומרות שאתה תמיד יודע באיזה כיוון הפיק את הטקסט שאתה ' מסתכלים עליו, ועם באגים נמלטים שעמימות היא כל הבעיה. אבל עבור חיטוט חקרני, גרסה מונעת הקשות תהיה באמת נחמדה יותר.

100% צד לקוח - שום דבר לא הועלה

הכל פועל בדפדפן שלך אין בקשה, אין שרת, אין יומנים. This isn't a nice-to-have: הטקסט שאתה 're escape הוא לעתים קרובות בדיוק הטקסט שאתה צריך 't להדביק לתוך אתרים אקראיים - הערות שנוצרו על ידי משתמשים עם שמות אמיתיים, תבניות דואל עם כתובות לקוחות, תוכן כרטיס תמיכה. I'כתבתי בעבר על למה זה חשוב ב מדריך פרטיות הנתונים שלנו; הגרסה הקצרה היא שממיר שמעלה את הקלט שלך הוא מעבד נתונים שמעולם לא בדקת. ה כלי ישות Toolz.dev עובד במצב לא מקוון לאחר הטעינה מצב מטוס הוא בדיקה חוקית - נסה זאת.

כיצד להשתמש במקודד ובמפענח ישות HTML

שלב 1: פתח את הכלי והדבק את הטקסט שלך

עבור אל Toolz.dev/tools/html-entities והדבק את הקלט שלך - קטע קוד, קטע RSS מעוות, קטע תבנית דואל, מה שלא יהיה. There' אין תקרת גודל ששווה לדאוג לגביה לשימוש רגיל; I' הדבקתי יומני שינוי תוספים שלמים מעובדים. מכיוון שהעיבוד הוא בצד הלקוח, תוכן רגיש בסדר כאן.

שלב 2: בחר קידוד או פענוח

קידוד הופך תווים גולמיים לישויות (< → <) - השתמש בו כאשר אתה רוצה שהסימון יוצג כטקסט. פענוח פותר ישויות בחזרה לתווים (& → &) - השתמש בו כאשר אתה'קורא מחדש תוכן נמלט. אם אתה'לא בטוח באיזה מצב הטקסט שלך נמצא, פענח תחילה וראה אילו שינויים. פלט ללא שינוי אומר שהוא כבר היה פשוט.

שלב 3: בחר את סגנון ההתייחסות (בעת קידוד)

לנפילת המצב יש בדיוק שלוש אפשרויות, והבחירה חשובה יותר ממה שהיא נראית. בשם מקודד את כל מה שיש לו שם ונופל חזרה לעשרוני עבור השאר - קריא במקור ובפערים, אבל הוא גם בורח ©, —, é וכל תו אחר שאינו ASCII, שמנפח את הפלט אם אתה' נמצאים ב-UTF-8 בכל מקרה. מספרי עושה את אותו כיסוי בעשרוני טהור. תווים מיוחדים בלבד לא נוגע בשום דבר מלבד & < > " ' ומשאיר את המבטאים, מקפי ה-em והאימוג'י שלך כ-UTF-8 גולמי - זה המצב שבו אני משתמש לתוכן אמיתי, וזה ' המצב שמתאים למה htmlspecialchars() עושה ב PHP שים לב ש ' תמיד יוצא כמו ', לעולם לא ', בכל שלושת המצבים; that's מכוון, מאז ' אינו מוגדר ב-HTML 4 ולקוחות אימייל ישנים יותר עדיין נחנקים ממנו.

שלב 4: בדוק את הפלט ולאחר מכן העתק

לחץ על קידוד או פענוח וקרא את החלונית הימנית. עבור עבודות פענוח, חפש במיוחד שאריות & רצפים - ניצול פירושו שהטקסט נמלט כפול, אז לחץ על Swap ופענח שוב. כאשר הוא קורא נקי, העתק את התוצאה לתבנית, CMS או קוד. עבור עבודות חוזרות, הלוך ושוב פעם אחת (קוד ואז פענוח) כדי לאשר ששום דבר אובדן לא קרה; עם מצב מיוחד-chars בלבד הנסיעה הלוך ושוב מדויקת.

שמות לעומת ישויות מספריות - וחמש התווים שבעצם חשובים

Let's מקבלים את המינוח ישר, כי "HTML entity" מתרגל באופן רופף.WHATWG HTML Standard - המפרט החי שמגדיר כיצד דפדפנים מנתחים HTML בפועל - מציין טבלה של הפניות לתווים בשם: למעלה מ-2,200 שמות כמו  , —, …, →, כל מיפוי לנקודת קוד אחת או שתיים של Unicode. בנפרד, הפניות לתווים מספריים תן לך להתייחס ישירות לכל נקודת קוד: עשרונית (—) או הקסדצימלי (—). אותו em-dash, שלושה איותים.

Here's הטייק הדעתני שלי, מחודד על ידי שנים של עבודה בוורדפרס: מתוך 2,200+ השמות הללו, רק חמישה תווים חשובים למעשה לנכונות ולבטיחות. כל השאר הוא טיפוגרפיה, ובדף UTF-8 - שהוא כל עמוד שאתה אמור לשלוח בשנת 2026 - אתה יכול פשוט להקליד את הדמות האמיתית. אתה לא צריך ' לא צריך —; אתה צריך - . החמישה החשובים הם אלה בעלי משמעות תחבירית ב-HTML:

אופי	ישות	למה זה משנה
`&`	`&`	מתחיל כל ישות - דמות הבריחה עצמה
`<`	`<`	פותח תגיות
`>`	`>`	סוגר תגיות
`"`	`"`	תוחם תכונות בציטוט כפול
`'`	`'`	תוחם תכונות מצוטטות בודדות

שימו לב לשורה האחרונה: ', לא '. השם ' תקף ב-HTML5, אבל זה היה ' חלק מ-HTML4, וכלי עבודה ישנים (ולקוחות דואל ישנים - עוד על אלה מאוחר יותר) יכולים למעוד בו. הטופס המספרי עובד בכל מקום. זה סוג הפדנטיות שחוסך לך דיווח באג מבלבל.

סדר פעולות הוא כל המשחק. בעת קידוד, & חייבים לברוח ראשון. אם תברח < ל < ואז לברוח מ-ampersands, you' ימיר את הפלט שלך ל &lt;- מזל טוב, אתה'נמלט פעמיים. פענוח הוא תמונת המראה: & חייב להיפתר אחרון, או &lt; הופך < הופך < ואתה ' פענחת פחות (או גרוע מכך, הצגת מחדש סימון חי מטקסט שנמלט בכוונה). כמעט כל באג בורח מגולגל ביד I' סקר - כולל שלי - הוא באג הזמנה.

ההקשר חשוב, וכאן בריחה פוגשת אבטחה. גיליון ה-Cheat Prevention Scripting Cross-Site של OWASP בוטה לגביו: קידוד ישות HTML הוא ההגנה הנכונה עבור ה-HTML גוף body ו תכונה הקשרים, אבל זה לא מספיק עבור מחרוזות JavaScript, כתובות URL או CSS. < בתוך א <script> block does't decode - script content isn't parsed for entities - כך שקידוד-ישויות לא עושה שם שום דבר שימושי כל הקשר צריך מקודד משלו: קידוד ישות עבור HTML, \uXXXX בריחה עבור מחרוזות JS, קידוד אחוזים עבור כתובות URL (that's what our מקודד/מפענח כתובת URL מיועד). שימוש במקודד הנכון בהקשר הלא נכון הוא הדרך הקלאסית שבה קוד מחוטא למראה נשאר ניתן לניצול.

בצד PHP, דע את שתי הפונקציות שלך. htmlspecialchars() בורח רק חמשת הספיישלים (עובר ENT_QUOTES או שאתה מתגעגע לציטוט היחיד - ממש טוב). htmlentities() בריחות הכל שיש לה ישות בשם, מסתובבת ü לתוך ü. בדפי UTF-8, htmlentities() היא כמעט תמיד הבחירה השגויה; הוא מנפח פלט ומבלבל תוכן כאשר ערכות תווים מוצהרות בצורה שגויה. וורדפרס עוטפת זאת בצורה הגיונית:

echo esc_html( $footer_text );              // body context
echo '<a title="' . esc_attr( $title ) . '">'; // attribute context

esc_html() ו esc_attr() שניהם בורחים מחמשת הספיישלים עם הדגלים הנכונים, שנבחרו לפי הקשר - בדיוק משמעת הבריחה המאוחרת ש-OWASP קובעת. הכלל שאני קודח בכל סקירת קוד: בריחה בזמן פלט, בהקשר של output's, בדיוק פעם אחת.

מה שמביא אותו הביתה: עם UTF-8, אתה לעתים רחוקות צורך ישויות לתווים טיפוגרפיים בכלל אתה צריך אותם לתווים בעלי משמעות סימון ולקלט לא מהימן כל השאר הוא הרגל מדור קודם.

מקרי שימוש נפוצים

הצגת קטעי קוד בפוסטים בבלוג ובמסמכים

כתוב הדרכה המכילה <script> או <?php ולהדביק אותו לתוך CMS גלם, והדפדפן ינסה לבצע או לבלוע הדוגמה שלך במקום להציג אותה כל דוגמת קוד בהקשר HTML צריכה <, >, ו & מקודד. אני עושה זאת ללא הרף עבור תיעוד תוסף - readme HTML, מאמרים מבוססי ידע, דוגמאות מוטבעות בכרטיסיות עזרה של ממשק המשתמש של מנהל זרימת העבודה: כתוב את הקטע, הפעל אותו דרך מקודד ישות, הדבק את הגרסה שנמלטה בפנים <pre><code>. שלושים שניות, ושלך <script> מציג כ <script> במקום להיעלם לתוך ה-DOM. אם אתה ' בונים זרימת עבודה של מסמכים באופן כללי, שלנו מדריך כלי קידוד מכסה את שאר ארגז הכלים סביב זה.

ניקוי טקסט עם בריחה כפולה ממאגרי מידע והזנות

ה &amp; מגפה. זה מופיע כאשר CMS בורח בשמירה, תוסף בורח בעיבוד ושכבת מטמון בורחת פעם נוספת. פעם שלחתי יומן שינויים של WP Adminify שבו מנתח wordpress.org readme וסקריפט הבנייה שלי לא הסכימו לגבי מי בורח - ביומן השינויים המעובד היו 23 גלויים &s בו לפני שמשתמש שלח לי דואל. הזנות RSS גרועות יותר; תוכן הזנה הוא לעתים קרובות HTML נמלט בתוך XML, כך הצרכנים באופן שגרתי over-או under-פענוח זה התיקון הוא אבחון פענוח: הדבק את הטקסט השבור, לפענח מעבר אחד בכל פעם, לספור כמה עובר עד it's נקי. that count equals the number of escape layers - now you know exactly how pieces of your pipeline are touching the text, and you can find the neutant one.

הכנת תוכן שנוצר על ידי משתמשים בצורה בטוחה

הערות, טקסט סקירה, ביוס פרופיל, כרטיסי תמיכה - כל דבר שמשתמש הקליד אינו מהימן, והוא מכיל לעתים קרובות PII: שמות אמיתיים, מיילים, כתובות. שני חששות מתנגשים כאן. ראשית, בטיחות: התוכן הזה חייב להיות מקודד ישות בפלט או you're one <img onerror=...> הרחק מ-XSS מאוחסן (שאל אותי לגבי שדה ההגדרות שכמעט שלחתי). שנית, פרטיות: כאשר אתה 'נמצא באגים למה משתמש ספציפי's ביו שובר את הפריסה שלך, אתה're טיפול בנתונים האישיים שלהם - הדבקתו לתוך ממיר בצד השרת פירושו משלוח PII לצד שלישי הכלי Toolz.dev מעבד הכל באופן מקומי, כך בדיקת מחרוזות בעיה אמיתית היא בטוחה.Code המדגם, לבדוק מה התבנית שלך צריך ייצרו, להבדיל מול מה שהוא כן ייצר.

תבניות HTML בדואל

דואל HTML הוא פיתוח אינטרנט עם מנוע רינדור בן 20 שנה. חלק מהלקוחות מטפלים ב-UTF-8 גולמי בסדר; אחרים - תלוי איך ה-ESP שלך מגדיר קידודי העברה - משליכים תווים טיפוגרפיים לתוך mojibake. המוסכמה ההגנתית שמפתחי דואל רבים עדיין עוקבים אחריהם: מקודדים טיפוגרפיה שאינה ASCII כישויות (—, ’,   לפריצות מרווחים) אז הבתים על החוט הם ASCII טהור. ותזכור ' נגמר '- Outlook's מנועים ישנים יותר הם בדיוק כלי העבודה שמעולם לא למד HTML5 שמות מאז תבניות לקבל אישית עם שמות וכתובות לקוחות, זה שוב תוכן I 'd רק לרוץ דרך כלי בצד הלקוח.Code את התבנית כרום פעם אחת, לשמור שדות מיזוג גלם, לברוח מהם בזמן המיזוג.

פענוח תוכן מגורד ותגובות API

לגרד דף או לצרוך API מרושל ואתה 'll לטבוע ב ’, “, &, ו  . ממשקי API מסוימים מחזירים מחרוזות מקודדות ישות בתוך JSON - פורמט שלא צריך בריחה של HTML בכלל - כך שתקבל חפצים כמו "title": "Fish & Chips". לפני שהנתונים האלה נכנסים למסד הנתונים שלך, פענח אותם כדי לנקות UTF-8; אחסן טקסט קנוני, בריחה בפלט. פגעתי בזה כל הזמן בעת ייבוא תוכן לאפליקציות Laravel: פענח תחילה ישויות ואז pretty-הדפס ובדוק את המטען עם פורמט JSON. לעשות את זה בסדר השני פירושו לקרוא JSON שבו כל אפוסתרוף הוא באורך שבעה תווים. אם המטען עטוף על גבי זה - חלק מספקי webhook עושים זאת - ה ממיר Base64 מטפל בשכבה החיצונית, ושלנו מדריך קידוד Base64 מסביר למה העטיפה הזאת קיימת.

לוקליזציה של תוכן עם דמויות מיוחדות

קבצי תרגום מגיעים בכל מצב שניתן להעלות על הדעת ספק אחד שולח UTF-8 נקי ü; אחר שולח ü; שליש שולח ü; מדי פעם אתה מקבל את שלושתם בקובץ PO אחד לפני הייבוא, אני מנרמל הכל ל UTF-8 גולמי עם לעבור פענוח - אחסון קנוני, חיפוש עקבי, הבדלים שפויים אותו הדבר חל על פיסוק RTL, סוגריים CJK, ו לטינית מודגש במחרוזות שנשלחו פענוח על ייבוא, לאחסן תווים אמיתיים, ולתת שכבת הפלט שלך לברוח רק את חמשת המיוחדים המתרגמים שלך גם יודו לך: über היא לא מילה שמישהו צריך לעשות הגהה.

שם לעומת עשרוני לעומת Hex לעומת UTF-8 גולמי: באיזה כדאי להשתמש?

טופס	דוגמה (em-dash)	קריאות	תמיכה בדפדפן	מתי להשתמש
ישות בשם	`—`	טוב - מתאר את עצמו	אוניברסלי לשמות מתקופת HTML4; שמות HTML5 בלבד (כמו `'`) נכשל בכלי עבודה ישנים	חמשת המבצעים; הקשרים מדור קודם כמו HTML בדואל
התייחסות עשרונית	`—`	מסכן - it's מספר	אוניברסלי, כולל מנתחים עתיקים	דמויות ללא שמות; בריחה מקסימלית-תאימות (`'`)
הפניה משושה	`—`	גרוע, אבל מפות לנקודות קוד Unicode	אוניברסלי בכל דבר מודרני מרחוק	בעת הצלבת תרשימים או מפרטים של Unicode
UTF-8 גולמי	`—`	מושלם	אוניברסלי בדפי UTF-8 שהוכרזו כהלכה	הכל טיפוגרפי - זו צריכה להיות ברירת המחדל שלך

עמדתי, בפשטות: כתוב UTF-8 גולמי לטיפוגרפיה, ישויות מילואים עבור חמשת המבצעים וקלט לא מהימן. מסמך מלא ב — ו … האם מסמך שאף אחד לא יכול להגיה, והוא מסמן זרימת עבודה שיש לה ' t מהימן הצהרות charset שלה מאז 2008 ערימות מודרניות - וורדפרס, Laravel, Next.js, כל מסד נתונים שאתה & #39;d לבחור היום - הם UTF-8 מקצה לקצה הקלד את התו האמיתי.

היכן ישויות מרוויחות את החזקתן: &, <, >, ", ו ' לכל דבר שיכול להתפרש כסימון, תמיד, ללא חריגים, מיושם בזמן פלט. ובסביבות רינדור עוינות - לקוחות דואל, עדכונים הנצרכים על ידי מנתחים לא ידועים - הפניות מספריות הן הבחירה הפרנואידית-אך-מוצדקת מכיוון שהן קודמות לכל טיעון תאימות. Between decimal and hex, it's taste; I lean hex because — תואם U+2014 ואני יכול להפסיק לעשות המרות בסיס בראש שלי.

שאלות נפוצות

מהי ישות HTML?

ישות HTML היא רצף טקסט המייצג תו במקום לכתוב את התו ישירות זה מתחיל עם אמפרסנד ומסתיים בנקודה-פסיק יש הפניות בשם כמו & ו ©, והפניות מספריות כמו © (עשרוני) או © (hex) שמנקודות בנקודת קוד Unicode דפדפנים פותרים אותן תוך כדי ניתוח, אז < מציג כסימן פחות מאשר במקום לפתוח תג הם קיימים כך שתוכל להציג תווים שאחרת היו מתפרשים כסימון.

אילו תווים חייבים לברוח ב-HTML?

חמש: האמפרסנד, פחות מ, גדול מ, ציטוט כפול, וציטוט יחיד - כתוב בשם &, <, >, ", ו '. אמפרסנד, כי הוא מתחיל ישויות; סוגרי הזווית, כי הם תוחמים תגים; הציטוטים, כי הם תוחמים ערכי תכונות. בטקסט גוף אלמנט אתה יכול לברוח רק עם שלושת הראשונים, אבל לברוח מכל החמישה בכל מקום הוא ההרגל שלעולם לא נושך אותך. כל השאר - מבטאים, מקפים, אימוג'י - יכול להיות UTF-8 גולמי בדף מוצהר כהלכה.

מה ההבדל בין < כתוב כישות בשם ו-<?

שום דבר, ברגע שהדפדפן מנתח אותם - שניהם מייצרים סימן פחות מ- הטופס בעל השם הוא חיפוש בטבלת WHATWG standard's של הפניות עם שם; < פונה ישירות לנקודת קוד Unicode 60, ו-< היא אותה נקודת קוד ב-hex. ישויות עם שם קל יותר לבני אדם לקרוא; הפניות מספריות פועלות עבור כל התווים, כולל אלפים שאין להם שם. למבצעים הנפוצים, בחר את מה שהצוות שלך מוצא קריא יותר - לדפדפנים לא אכפת.

מדוע הדף שלי מציג &amp; במקום אמפרסנד?

בריחה כפולה שכבה כלשהי של המחסנית שלך ברחה מחרוזת שכבר נמלטה, והפכה את & לתוך &amp;. הדפדפן מפענח רמה אחת ומציג את השאריות. זה בדרך כלל אומר ששני רכיבים שניהם חושבים שבריחה היא העבודה שלהם - CMS בשמירה בתוספת תבנית ברינדור הוא הזוג הקלאסי. פענח את המחרוזת במעבר אחד בכל פעם במפענח; מספר המעברים עד שהוא קורא נקי שווה למספר השכבות הבורחות ממנו. ואז הפוך בדיוק שכבה אחת אחראית, בזמן הפלט.

האם בריחה מ-HTML מונעת XSS?

בהקשרים של גוף ותכונות HTML, כן - קלט לא מהימן המקודד לישות יש את ההגנה המרכזית, מכיוון שהמטען מוצג כטקסט אינרטי. אבל זה לא מספיק בכל מקום. גיליון ה- Cheat Prevention OWASP XSS מפורש שמחרוזות JavaScript, כתובות URL ו-CSS כל אחד צריך קידוד ספציפי להקשר משלו; קידוד ישות בתוך בלוק סקריפט לא עושה כלום. בריחה בפלט, בהקשר שאליו אתה יוצא, באמצעות ההקשר הזה 's מקודד. קידוד ישות הוא כלי אחד בערכה הזו, לא בערכה כולה.

מה ההבדל בין htmlspecialchars לבין htmlentities ב-PHP?

htmlspecialchars () בורח רק מהתווים המשמעותיים לסימון - וכדאי לעבור ENT_QUOTES כדי שיכסה את הציטוט היחיד. htmlentities () ממיר כל תו שיש לו ישות בשם, כך שאותיות מודגשות הופכות לדברים כמו הפניה ל-uuml. בדפי UTF-8, htmlspecialchars () הוא כמעט תמיד מה שאתה רוצה; htmlentities () מנפח פלט וגורם ל-mojibake כאשר ערכות תווים מוגדרות בצורה שגויה. מפתחי וורדפרס נמנעים בעיקר מהשאלה על ידי שימוש ב-esc_html () ו-esc_attr (), המחילים את הדגלים הנכונים לכל הקשר.

האם עלי להשתמש ב apos בשם ישות עבור apostrophes?

מעדיף '.שם apos תקף בHTML5 אבל מעולם לא היה חלק HTML4, כך מנתחים ישנים יותר - כולל מנועי העיבוד בתוך כמה לקוחות דואל - לא לזהות אותו ויציג אותו פשוטו כמשמעו.The טופס מספרי ' פירושו אותו תו ועובד בכל דבר אי פעם נשלח זוהי בחירה מכוערת-אבל-בטוחה, אשר בדרך כלל את הפשרה הנכונה עבור בריחה אם אתה יודע הפלט שלך רק אי פעם פוגע דפדפנים מודרניים, apos בסדר; תבניות דואל הן בדיוק איפה אתה לא יכול לדעת את זה.

האם זה בטוח להדביק נתוני משתמש לתוך ממיר ישות מקוון?

רק אם הכלי מעבד טקסט בדפדפן שלך.תוכן ותבניות דואל שנוצרו על ידי משתמשים מכילים באופן שגרתי שמות, מיילים ו-PII אחרים, וממיר שמפרסם את הקלט שלך לשרת קיבל זה עתה את הנתונים האלה ללא הסכמה במקום. Toolz.dev HTML Entities Encoder/Decoder פועל 100% בצד הלקוח - ללא העלאה, ללא רישום, והוא פועל במצב לא מקוון לאחר טעינת הדף אם אינך יכול לאמת כיצד כלי מטפל בקלט, אל תדביק בו נתוני ייצור.

לברוח פעם אחת, במקום הנכון

אם אתה לוקח דבר אחד מעשור של טעויות הבריחה שלי, קח את זה: בדיוק שכבה אחת של הערימה שלך צריכה לברוח, וזה צריך להיות שכבת הפלט. Store נקי UTF-8. Escape חמשת המיוחדים בזמן רינדור, בהקשר you're רינדור לתוך. Every &amp; בייצור יש מפה של שני רכיבים שנלחמים על העבודה הזו - וכל מחרוזת משתמש שלא נמלטה היא XSS מאוחסן שמחכה לסקירת קוד שאולי לא תתרחש. שלי כמעט עשה 't.

שמור את מקודד/מפענח ישויות HTML בסיבוב ניפוי הבאגים שלך לצד אחיו - ה מקודד/מפענח כתובת URL עבור הקשרים המקודדים באחוזים (ה מדריך קידוד כתובת URL עובר דרך %2520, בן דודו המקודד באחוזים של &amp;), ה ממיר Base64 למטענים עטופים, וה מַגִישׁ לעבודת נהמת המזהה-שם ביניהם. ה מדריך כלי קידוד הולך כל הסט.

ומכיוון שהמחרוזות שאתה מאתר באגים הן לעתים קרובות כל כך מישהו 's שם בפועל או דואל: הכל למעלה פועל בצד הלקוח, שום דבר לא הועלה, ניתן לאימות בכרטיסיית הרשת שלך. That's לא שיווק - it's הסיבה שבניתי את הכלים האלה כמו שבניתי. עוד על הפילוסופיה הזו ב מדריך פרטיות נתונים.

Frequently Asked Questions

An HTML entity is a text sequence that represents a character instead of writing the character directly. It starts with an ampersand and ends with a semicolon. There are named references like & and ©, and numeric references like © (decimal) or © (hex) that point at a Unicode code point. Browsers resolve them while parsing, so < displays as a less-than sign instead of opening a tag. They exist so you can show characters that would otherwise be interpreted as markup.

מפענח מקודד ישות HTML: בריחה, ביטול בריחה והפסקת משלוח ומגבר; מגבר; לייצור