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 實體編碼器解碼器:Escape、Unescape 和 Stop Shipping &amp;到生產

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'這是一個糟糕的工作流程,它'這正是為什麼 HTML 實體編碼器解碼器是我內建到 toolz。dev 中的第一個工具之一。

同一枚硬幣的另一面更可怕。在那張票之前的幾個月,在對我自己的插件進行程式碼審查時,我發現了一個設定字段,該字段與用戶輸入的管理通知相呼應 esc_html()。任何有權存取該欄位的人都可以儲存 <script> 並讓它為每個載入頁面的管理員執行。在我自己的程式碼中儲存了 XSS,一個缺少的函數呼叫被呼叫。沒有人利用它--我很幸運。但它永久地改變了我對逃跑的看法:它'不是格式化的苦差事,它'是"text"和"code。"之間的邊界

所以本指南涵蓋了兩個方向。編碼,所以不受信任的文字仍然是文字。解碼,這樣你就可以讀到一些過於急切的管道損壞的內容。足夠的理論 - 命名與數字引用,實際上重要的五個字符,為什麼操作順序會導致雙重轉義 - 你可以調試這些東西而不是猜測。

TL;DR: 將您的文字貼到 toolz。dev HTML 實體編碼器/解碼器在原始字元和實體之間按命名、十進位或十六進位方向進行轉換。它 100% 運行客戶端,因此用戶內容和 PII 永遠不會離開您的瀏覽器。經驗法則:始終逃避五個特殊(& < > " ')在不受信任的輸入中,並編碼 & 首先或你'將雙重逃脫。

主要特點

在兩個方向上進行編碼和解碼

我需要轉動一半的時間 <script> 進入 <script> 因此,它在部落格文章中以文字形式顯示。另一半 I'正朝相反的方向走──轉動刮擦的東西 &#8217;s 返回可讀撇號。該工具處理兩者。貼上文本,選擇編碼或解碼,完成。沒有模式搜尋,每個方向沒有單獨的工具。這聽起來很瑣碎,直到你'使用僅解碼的工具,並且您發現自己打開第二個選項卡來為文檔編碼程式碼範例。往返也是一個很好的理智檢查:編碼、解碼並確認您已恢復原始字串。如果您選擇 't,輸入中的某些內容已經部分逃脫 - 這本身就是有用的信息。

命名實體:&amp;,&lt;,&複製;和朋友

命名字元引用是人類可讀的 - & 對於&, < 對於<, © 對於©, — 對於 em-dash。該工具包含一個包含 147 個名稱的精選表,而不僅僅是著名的五個名稱:排版 ( , …, ’, “)、貨幣、數學和箭頭、希臘字母、完整的拉丁 1 重音範圍以及一些賠率(例如卡牌花色)。這個範圍就是現實世界內容實際需要的 - WordPress 發出  , …, 和 ’ 透過不斷的 wptexturize,只有十幾個名字的解碼器會讓一半的文字散落著未解決的引用。

清楚 147 不是什麼: WHATWG HTML 標準定義了 2,200 多個命名參考,因此這是一個實用的子集而不是完整的表。如果名稱是 't,解碼會使引用保持不變,而不是猜測 - &bogus; 出來時為 &bogus;。編碼具有互補行為,它's 更有用的一半:任何字元沒有表中的名稱會自動回退到十進制數字引用,因此不會默默刪除任何內容。表情符號編碼為 🌍中文文本為 你好. 姓名(如果存在),數字(如果存在)。

與瀏覽器行為的另一個分歧值得了解:解碼器區分大小寫並且需要分號。瀏覽器會解決 &COPY; 甚至裸露 &amp 由於遺留相容性規則,在某些解析上下文中沒有尾隨分號;此解碼器兩者都沒有解析。實際上,'沒問題 - 任何現代工具產生是小寫且終止 - 但如果您're 解碼從古代 CMS 中抓取的 HTML,則 ' 是您' 將擊中的邊緣。

數字參考:十進制和十六進制

任何統一碼字元可以寫成數字字元引用 - 像十進制一樣 — 或像十六進制 — (兩者都是 em-dash)。解碼器解析這兩種形式。這是標準中沒有名稱的字元的轉義艙口,它's 表單 you'將在 API 回應和 RSS 來源中不斷相遇,其中 ’ (右單引號)其實是一個簽名。十六進位引用直接對應到 Unicode 代碼點 - U+2014 是 —- 這就是為什麼當 I'm 與 Unicode 圖表交叉引用時我更喜歡它們。

誠實的限制,因為您'將在使用工具後一分鐘內註意到它:數字編碼模式僅發出十進制。 There'沒有十六進位輸出選項。解碼 — 工作正常;要求編碼器產生它沒有't。這兩種形式在語義上與每個瀏覽器相同,因此這在功能上不需要您花費任何費用,但如果您的程式碼庫在十六進位上標準化,您'將手動轉換。它'在我的列表中。超出範圍的引用會被捕獲而不是損壞 - &#1114112; 高於 Unicode 最大值並傳回明確錯誤而不是替換字元。

完整的 Unicode 覆蓋範圍

表情符號、CJK 字元、阿拉伯語、組合變音符號、作品。如果它有一個代碼點,該工具可以將其表達為一個實體並解決它。這比您更重要'考慮本地化工作 - I'已調試到達的德語元音變音符號 ü 來自一家翻譯供應商並作為原始 UTF-8 ü 來自另一個,在同一導入文件中。在 Latin-1 之外阻塞的工具對此毫無用處。 U+FFFF(表情符號存在於上方)上方的字元作為單一代碼點正確處理,而不是損壞的替代對。

解開雙重逃亡文本

的 &amp; 問題。當管道的兩層都逃逸時, & 成為 &amp;- 三層給你 &amp;amp;. 一旦剝落一層,即可進行解碼,這樣您就可以重複運行解碼器並觀看洋蔥展開: &amp;amp; → &amp; → & → &. 計算通行證會告訴您堆疊中有多少層正在逃逸,這正是我在四次逃逸的 WP Adminify 頁腳錯誤期間所需的診斷。每層解碼一次。 It'這是我所知道的定位管道中額外逃逸發生位置的最快方法。

附字元計數的並排窗格

左邊輸入,右邊輸出,字元數高於兩者。該計數對所做的工作比聽起來要多:轉義是一個擴展操作,因此如果您編碼 40 個字元並恢復 44 個字符,則恰好觸及了一個特殊字元。當 I'm 審核模板是否已經轉義某些內容時,delta 在 I&#39 之前告訴我;讀過輸出的單一字元。編碼、解碼、交換和清除都是按鈕 - 那裡'沒有即用即付的轉換,I'承認這是一個故意的權衡,我有時會後悔。明確的操作意味著您總是知道哪個方向產生了文字 you'正在查看,並且隨著逃避錯誤,模糊性才是整個問題。但對於探索性戳記,擊鍵驅動版本確實會更好。

100% 客戶端 - 未上傳任何內容

一切都在您的瀏覽器中運行。沒有請求,沒有伺服器,沒有日誌。這是 '這是一個值得擁有的:文字 you'轉義通常正是您應該貼上到隨機網站中的文字 - 用戶生成的實名評論、帶有客戶地址的電子郵件模板、支持票證內容。 I'之前寫過為什麼這很重要我們的資料隱私指南;簡短的版本是,上傳輸入的轉換器是您從未審查過的資料處理器。這 toolz。dev 實體工具載入後可離線工作。飛行模式是一個有效的測試 - 嘗試一下。

如何使用 HTML 實體編碼器和解碼器

第 1 步:開啟工具並貼上文字

去 Toolz.dev/tools/html-entities 並貼上您的輸入 - 程式碼片段、損壞的 RSS 摘錄、電子郵件範本片段等等。那裡'沒有正常使用值得擔心的尺寸上限; I'已將整個渲染的插件變更日誌貼入。由於處理是客戶端,因此敏感內容在這裡很好。

第 2 步:選擇編碼或解碼

編碼將原始字元轉換為實體 (< → <) - 當您想要標記顯示為文字時使用它。解碼將實體解析回字元 (& → &) - 當您&#39 時使用它;正在閱讀轉義內容。如果您'不確定您的文字處於哪種狀態,請先解碼並查看哪些變更。未更改的輸出意味著它已經很簡單。

步驟 3:選擇參考樣式(編碼時)

模式下拉恰好有三個選項,選擇比看起來更重要。命名對它所命名的所有內容進行編碼,其餘部分則回退到小數 - 在來源和差異中可讀,但它也會逃脫 ©, —, é 以及所有其他非 ASCII 字符,如果您 ' 無論如何,它們都會在 UTF-8 上膨脹輸出。數字以純十進制進行相同的覆蓋。 僅限特殊字元 只觸及什麼 & < > " ' 並將你的口音、em-dash 和表情符號保留為原始 UTF-8 - 這是我用於真實內容的,它'是與什麼相符的模式 htmlspecialchars() 在 PHP 中確實如此。注意這一點 ' 總是出來為 ',從來沒有 ',在所有三種模式下;那'這是故意的,因為 ' 在 HTML 4 中未定義,較舊的電子郵件用戶端仍然會對其造成阻礙。

第四步:檢查輸出,然後複製

點擊編碼或解碼並讀取右側窗格。對於解碼作業,請專門尋找剩餘的 & 序列 - 倖存者意味著文字是雙重轉義的,因此再次點擊「交換」並解碼。當它讀乾淨時,將結果複製到模板、CMS 或程式碼中。對於重複作業,往返一次(編碼然後解碼)以確認沒有發生任何有損;使用僅特殊字元模式,往返是準確的。

命名實體與數字實體 - 以及實際重要的五個字元

Let's 弄清楚術語,因為 "HTML 實體"使用鬆散。 WHATWG HTML 標準 - 定義瀏覽器如何實際解析 HTML 的活動規範 - 指定了一個表格 命名字元引用:超過 2,200 個名字,例如  , —, …, →,每個映射到一兩個 Unicode 代碼點。單獨地, 數字字元引用 讓您直接尋址任何代碼點:十進位 (—) 或十六進制 (—).相同的 em-dash,三種拼字。

這裡'是我固執己見的看法,並因多年的 WordPress 工作而變得更加尖銳: 在這 2,200 多個名字中,只有 5 個字元實際上對正確性和安全性很重要。 其他一切都是排版,在 UTF-8 頁面(這是您應該在 2026 年發貨的每一頁)上,您只需輸入真實的角色即可。你不需要'不需要 —;你需要 - 。重要的五個是 HTML 中具有句法意義的:

人物	實體	為什麼這很重要
`&`	`&`	開始每個實體-轉義角色本身
`<`	`<`	打開標籤
`>`	`>`	關閉標籤
`"`	`"`	界定雙引屬性
`'`	`'`	界定單引屬性

注意最後一行: ',不 '. 名稱 ' 在 HTML5 中有效,但它是 't HTML4 的一部分,舊工具(以及舊電子郵件用戶端 - 更多內容稍後)可以在上面跳閘。數字形式隨處可見。這種迂腐的做法可以避免您收到令人困惑的錯誤報告。

操作順序是整個遊戲。 編碼時, & 必須逃脫 第一的. 如果你逃跑了 < 到 < 然後轉義'將您自己的輸出轉換為 &lt;- 恭喜你've 雙重逃脫。解碼是鏡像: & 必須解決 最後的,或者 &lt; 成為 < 成為 < 你'解碼不足(或更糟的是,從故意轉義的文字中重新引入即時標記)。幾乎每個手動捲起的轉義錯誤 I'已審查 - 包括我自己的 - 都是訂購錯誤。

背景很重要,這就是逃跑與安全相遇的地方。 OWASP 跨站點腳本預防作弊表對此直言不諱:HTML 實體編碼是 HTML 的正確防禦身體和屬性上下文,但確實如此不是對於 JavaScript 字串、URL 或 CSS 來說就足夠了。 < a 內 <script> 區塊 do 't 解碼 - 腳本內容為 't 解析為實體 - 因此實體編碼在那裡沒有任何用處。每個上下文都需要自己的編碼器:HTML 的實體編碼 \uXXXX 轉義 JS 字串、URL 百分比編碼(that'swhat our URL 編碼器/解碼器是為了)。在錯誤的上下文中使用正確的編碼器是看起來經過清理的程式碼保持可利用的經典方式。

在 PHP 方面,了解你的兩個功能。 htmlspecialchars() 僅逃脫五個特價(通過) ENT_QUOTES 或者你錯過了這句話--一個真正的陷阱)。 htmlentities() 逃脫一切它有一個命名的實體,轉動 ü 進入 ü. 在 UTF-8 頁上, htmlentities() 幾乎總是錯誤的選擇;當字元集被錯誤聲明時,它會膨脹輸出並損壞內容。 WordPress 明智地包裹了這一點:

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

esc_html() 和 esc_attr() 兩者都透過根據上下文選擇的正確標誌來逃脫五個特殊情況 - 正是 OWASP 規定的遲到紀律。規則 I 深入到每個程式碼審查:在輸出時間、輸出和#39 中逃脫;s 上下文,恰好一次。

這讓它回家:使用 UTF-8,你很少需要印刷字元的實體。您需要它們來標記重要字元和不可信的輸入。其他一切都是遺留習慣。

常見用例

在部落格文章和文件中顯示程式碼片段

編寫包含的教程 <script> 或者 <?php 並將其貼到原始 CMS 中,瀏覽器將嘗試這樣做 執行或吞嚥 您的範例而不是顯示它。 HTML 上下文中的每個程式碼範例都需要 <, >, 和 & 編碼的。我經常為插件文件執行此操作 - 自述 HTML、知識庫文章、管理 UI 幫助選項卡中的內聯範例。工作流程:編寫片段,運行它實體編碼器,將轉義版本貼在裡面 <pre><code>.三十秒,還有你的 <script> 顯示為 <script> 而不是消失在 DOM 中。如果您'正在建立一個文件工作流程,我們的編碼工具指南覆蓋周圍工具箱的其餘部分。

從資料庫和來源清理雙聯文字

的 &amp; 瘟疫。當 CMS 在保存時逃脫、插件在渲染時逃脫以及快取層再次幫助逃脫時,就會出現這種情況。我曾經發布過一個 WP Adminify 變更日誌,其中 wordpress。org 自述文件解析器和我自己的建置腳本對於誰逃脫存在分歧 - 渲染的變更日誌有 23 個可見 &在用戶給我發電子郵件之前 S 出現在其中。 RSS 提要更糟;提要內容通常會轉義為 HTML 裡面 XML,因此消費者通常會對其進行過度或不足的解碼。修復方法是診斷解碼:貼上損壞的文本,一次解碼一次,計算多少次通過,直到它'乾淨。該計數等於轉義層的數量 - 現在您確切地知道有多少個管道正在接觸文本,並且您可以找到冗餘的層。

安全地準備使用者產生的內容

評論、評論文字、個人資料簡介、支援票證 - 用戶輸入的任何內容均不受信任,並且經常包含 PII:真實姓名、電子郵件、地址。這裡有兩個問題發生衝突。首先,安全性:內容必須在輸出或 you&#39 處進行實體編碼;是一個 <img onerror=...> 遠離儲存的 XSS(詢問我即將發貨的設定欄位)。第二,隱私:當你're調試 為什麼 特定用戶's bio 破壞您的佈局,you'正在處理他們的個人資料 - 將其貼上到伺服器端轉換器意味著將 PII 傳輸給第三方。 toolz。dev 工具在本地處理所有內容,因此測試實際問題字串是安全的。對樣本進行編碼,檢查您的範本應該已經生產出來,與它確實生產的東西不同。

電子郵件 HTML 範本

電子郵件 HTML 是 Web 開發,具有 20 年歷史的渲染引擎。有些客戶端處理原始 UTF-8 罰款;其他 - 取決於您的 ESP 設定傳輸編碼的方式 - 將排版字元亂碼轉換為 mojibake。許多電子郵件開發人員仍然遵循防禦性慣例:將非 ASCII 排版編碼為實體(()—, ’,   對於間距黑客),因此線上的位元組是純 ASCII。並記住 ' 結束了 '- Outlook'較舊的引擎正是從未學習過 HTML5 名稱的工具。由於模板會使用客戶名稱和地址進行個人化,因此這又是內容 I'd 僅透過客戶端工具運行。對模板 chrome 進行編碼一次,保持合併欄位原始狀態,在合併時轉義它們。

解碼廢棄內容和 API 回應

抓取頁面或消耗草率的 API,然後您'就會被淹沒 ’, “, &, 和  . 某些 API 會傳回 JSON 內的實體編碼字串(這種格式根本不需要 HTML 轉義),因此您會收到類似的工件 "title": "Fish & Chips". 在資料進入您自己的資料庫之前,對其進行解碼以清理 UTF-8;儲存規範文本,在輸出時轉義。當我將內容匯入 Laravel 應用程式時,我不斷遇到這個問題:首先解碼實體然後列印漂亮並用檢查有效負載 json 格式化程式。以其他順序執行此操作意味著讀取 JSON,其中每個撇號長 7 個字元。如果有效負載以 64 為底包裹在其之上 - 一些 Webhook 提供者會這樣做 - Base64 轉換器處理外層,還有我們的 Base64 編碼指南解釋了為什麼存在這種包裝。

使用特殊字元在地化內容

翻譯文件到達可以想像到的每個狀態。一個供應商發送乾淨的 UTF-8 ü;另一個發送 ü;第三個發送 ü;偶爾,您會將所有三個都放在一個 PO 檔案中。匯入之前,我透過解碼通道將所有內容標準化為原始 UTF-8 - 規範儲存、一致搜尋、理智差異。這同樣適用於 RTL 標點符號、CJK 括號和出貨字串中的重音拉丁文。在匯入時解碼,儲存真實字符,並讓您的輸出層僅逃脫五個特殊功能。您的翻譯人員也會感謝您: über 這不是任何人都應該校對的字。

命名 vs 十進制 vs 十進制 vs 原始 UTF-8:您應該使用哪一個?

形式	範例(em-dash)	可讀性	瀏覽器支援	什麼時候使用
命名實體	`—`	很好--自我描述	通用 HTML4 時代名稱;僅 HTML5 名稱(例如 `'`) 舊工具失敗	五個特價;舊版上下文,例如電子郵件 HTML
十進制參考	`—`	可憐 - it'一個數字	通用,包括古代解析器	沒有名字的角色;最大相容性轉義(`'`)
十六進制參考	`—`	較差,但映射到 Unicode 代碼點	普遍存在於任何遙遠的現代事物中	當交叉引用 Unicode 圖表或規範時
原始 UTF-8	`—`	完美的	在正確聲明的 UTF-8 頁面上通用	一切都是印刷的--這應該是你的預設

我的立場很明確: 編寫原始 UTF-8 進行排版、為五個特殊功能保留實體以及不可信的輸入。 充滿的文件 — 和 … 是一個沒人能校對的文件,它標誌著一個工作流程,自 2008 年以來已經信任其字元集聲明。現代堆疊 - WordPress、Laravel、Next。js、您和#39;今天選擇的每個資料庫 - 都是 UTF-8 端到端。輸入真實字元。

實體賺取保留的地方: &, <, >, ", 和 ' 對於任何可以解釋為標記的內容,始終無一例外,在輸出時應用。在敵對的渲染環境中 - 電子郵件用戶端、未知解析器消耗的提要 - 數字引用是偏執但合理的選擇,因為它們早於每個相容性參數。在十進制和十六進制之間,它's 品味;我傾向於十六進制,因為 — 匹配 U+2014,我可以停止在腦中進行鹼基轉換。

常見問題

什麼是 HTML 實體?

HTML 實體是表示字元而不是直接寫入字元的文字序列。它以&ampsand開頭,以分號結尾。有像 &amp 這樣的命名引用;和&複製;以及像 &#169 這樣的數字引用; (十進制)或© (十六進位)指向 Unicode 代碼點。瀏覽器在解析時解析它們,所以 <顯示為小於號而不是打開標籤。它們的存在是為了顯示否則會被解釋為標記的字元。

HTML 中必須轉義哪些字元?

五:&符號、小於、大於、雙引號和單引號 - 寫為 &,<,>,",以及'。& &,因為它開始實體;尖括號,因為它們分隔標籤;引號,因為它們分隔屬性值。在元素正文中,您可以只保留前三個,但到處逃避所有五個是永遠不會咬你的習慣。其他一切 - 重音、破折號、表情符號 - 都可以是正確聲明頁面上的原始 UTF-8。

< 和 &#60 之間有什麼區別?寫成命名實體;?

一旦瀏覽器解析它們,什麼都沒有 - 兩者都會產生小於符號。命名形式是 WHATWG 標準和#39 中的查找;命名參考文獻表; <直接尋址 Unicode 代碼點 60,以及 <是十六進位的相同代碼點。命名實體更容易被人類閱讀;數字引用適用於所有字符,包括數千個沒有名稱的字符。對於常見的特價商品,請選擇您的團隊認為更可讀的 - 瀏覽器不在乎。

為什麼我的頁面顯示 &amp;而不是&符號?

雙重轉義。堆疊的某些層轉義了已經轉義的字串,turning &進入&放大;放大;瀏覽器解碼一個層級並顯示剩餘的。這通常意味著兩個元件都認為轉義是它們的工作 - 儲存時的 CMS 加渲染時的範本是經典對。在解碼器中一次解碼一遍字串;讀取乾淨之前的遍數等於轉義的層數。然後在輸出時讓一層負責。

逃避 HTML 會阻止 XSS 嗎?

在 HTML 主體和屬性上下文中,是的 - 對不受信任的輸入進行實體編碼,存在核心防禦,因為有效負載呈現為惰性文字。但到處都不夠。 OWASP XSS 預防作弊表明確指出 JavaScript 字串、URL 和 CSS 都需要自己的上下文特定編碼;腳本區塊內的實體編碼沒有任何作用。使用上下文's 編碼器,在輸出時轉義。實體編碼是該套件中的一個工具,而不是整個套件。

PHP 中的 htmlspecialchar 和 htmlentities 有什麼不同?

htmlspecialchars () 僅轉義標記有效字元 - 您應該通過 ENT_QUOTES,以便它涵蓋單引號。 htmlentities () 轉換每個具有命名實體的字符,因此重音字母變成 uuml 參考等。在 UTF-8 頁上,htmlspecialchars () 幾乎總是您想要的; htmlentities () 會膨脹輸出並在字元集配置錯誤時導致 mojibake。 WordPress 開發人員大多透過使用 esc_html () 和 esc_attr () 來避免這個問題,它們會根據上下文套用正確的標誌。

我應該使用 apos 命名的實體作為撇號嗎?

更喜歡'。 apos 名稱在 HTML5 中有效,但從未成為 HTML4 的一部分,因此較舊的解析器 - 包括某些電子郵件用戶端內的渲染引擎 - 無法識別它並按字面顯示它。數字形式'表示相同的字元並適用於所發的所有內容。這是一個醜陋但安全的選擇,通常是逃跑的正確權衡。如果您知道您的輸出只擊中現代瀏覽器,那麼 apos 就很好;電子郵件範本正是您無法知道的地方。

將使用者資料貼上到線上實體轉換器中安全嗎?

僅當該工具在瀏覽器中處理文字時。使用者產生的內容和電子郵件範本通常包含姓名、電子郵件和其他 PII,並且將您的輸入發佈到伺服器的轉換器剛剛收到該數據,但沒有達成任何協議。 toolz。dev HTML 實體編碼器/解碼器 100% 客戶端運行 - 無需上傳,無需日誌記錄,頁面載入後即可離線工作。如果您無法驗證工具如何處理輸入,請勿將生產資料貼上到其中。

逃一次,在正確的地方

如果你從我十年的逃避錯誤中汲取一件事,請採取以下措施:恰好你堆疊的一層應該逃脫,它應該是輸出層。儲存乾淨的UTF-8。在上下文中,在渲染時逃避五個特殊功能 you'重新渲染到。每一個 &amp; 在生產中,有兩個元件爭奪該作業的地圖 - 每個未轉義的使用者字串都是一個儲存的 XSS,等待可能不會發生的程式碼審查。我的幾乎沒有't。

保留 HTML 實體編碼器/解碼器在您與其兄弟程式一起進行調試時 - URL 編碼器/解碼器對於百分比編碼上下文 (the URL 編碼指南走過 %2520,百分比編碼的表親 &amp;), Base64 轉換器對於包裹的有效載荷,以及變形器對於標識符重命名 grunt 在它們之間工作。這編碼工具指南走遍整套。

由於您調試的字串通常是某人的'實際姓名或電子郵件:上面的所有內容都運行客戶端,沒有任何內容上傳,可以在您的網路標籤中驗證。 That'不是行銷 - it'這是我以我做的方式建立這些工具的原因。更多關於這個哲學的內容資料隱私指南.

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 實體編碼器解碼器:Escape、Unescape 和 Stop Shipping &amp;到生產