1. 从一次“诡异”的页面显示说起为什么我的代码变成了文本那天下午我正在为一个内部管理后台赶一个功能。需求很简单一个表格用来展示系统里各种“规则”的配置详情其中一列需要显示规则的条件表达式比如score 90或者status 3。我三下五除二写好了前端代码用的是最朴素的HTML表格。为了清晰我决定把表达式放在code标签里让它看起来像代码片段。我的HTML大概是这样的table border1 tr th规则ID/th th条件表达式/th /tr tr td101/td tdcodeuser.age 18/code/td /tr tr td102/td tdcodeorder.amount 1000/code/td /tr /table写完之后我信心满满地刷新了浏览器。结果让我愣住了表格里“条件表达式”那一列竟然是一片空白。我检查了元素code标签和里面的文本明明都在但浏览器渲染出来的就是什么都没有。我第一反应是CSS样式冲突把字体颜色设成了白色我赶紧打开开发者工具检查发现根本不是颜色问题。当我查看“元素”面板时看到了让我恍然大悟的一幕浏览器把我的codeuser.age 18/code解析成了codeuser.age然后它认为后面跟着一个未闭合的符号和一堆乱码18/code。同理符号也被当成了标签的开始。问题根源在HTML中小于号和大于号具有特殊含义。是标签的开始符号是标签的结束符号。当浏览器解析到user.age 18中的时它无法智能地判断这个是我想展示的文本内容还是某个标签比如一个不存在的18/code标签的结束符。为了安全和不破坏文档结构它选择了一种“保守”的处理方式这直接导致了内容显示异常或消失。这就是HTML转义字符登场的核心场景。它们不是为了增加学习成本而是为了解决HTML语言本身的语法冲突确保“内容”与“结构”能够清晰、无歧义地共存。而标题中提到的amp;gt;和amp;lt;正是解决这个“大于号、小于号显示难题”的钥匙。不过这里有个有趣的细节标题里写的是amp;gt;和amp;lt;这本身就是一个“转义后的转义符”我们稍后会深入拆解。这篇文章我就从一个前端老手的角度带你彻底搞懂HTML转义特别是和的处理让你以后再也不会掉进这个坑里并能游刃有余地处理各种特殊字符。2. 庖丁解牛HTML转义符的本质与“双层转义”谜题要理解转义我们得先回到HTML解析器的工作逻辑上。你可以把解析器想象成一个严格的语法分析器它逐字符读取你的文档并遵循一套硬性规则遇到就进入“标签开始”状态开始收集标签名。遇到就结束当前标签的收集并尝试闭合它。标签之外的内容都被视为文本节点Text Node进行渲染。那么当文本内容中需要包含或时就产生了冲突。我们需要一种方法告诉解析器“喂后面这个字符不是语法的一部分它就是普通文本。” 这种方法就是字符实体引用Character Entity Reference。lt;和gt;才是本尊lt;是 “less than” 的缩写代表。gt;是 “greater than” 的缩写代表。所以我上面那个出错的表格正确的写法应该是tdcodeuser.age gt; 18/code/td tdcodeorder.amount lt; 1000/code/td这样浏览器解析到gt;时会将其转换为文本页面就能正确显示user.age 18了。现在我们来解开标题amp;gt;的谜团。标题里写的是amp;gt;而不是gt;。这涉及到“转义中的转义”。符号在HTML中也有特殊意义它是字符实体引用的起始符号。当解析器看到它会认为后面跟着的是一个实体名称如lt或编号如#60直到遇到分号;结束。如果你想在页面上显示gt;这五个字符本身而不是显示为你就需要对进行转义。转义的实体是amp;amp 是 ampersand 的缩写。所以gt;会被浏览器渲染成amp;gt;会被浏览器渲染成gt;这看起来就是原始代码标题“amp;gt---amp;lt”很可能是在某个需要展示代码示例的上下文比如一篇教程中为了在页面上原样输出“gt;”和“lt;”这两个转义符字符串而使用的。它本身并不是直接用来转义大于、小于号的“操作指南”而是一个“如何展示转义符代码”的示例。这提醒我们在编写技术文档或博客时如果需要在网页中展示包含HTML特殊字符的代码片段通常需要做两层转义或者更常见的使用pre和code标签并配合htmlspecialchars等函数进行处理确保代码能被安全、原样地渲染。3. 不止于大于小于你必须知道的HTML特殊字符全家福搞定了和这只是HTML转义世界的冰山一角。在实际开发中尤其是涉及用户输入、动态内容生成、富文本展示时以下几个字符同样至关重要忽视它们可能会导致严重的漏洞或显示问题。3.1 双引号与单引号属性值的守卫者quot;或#34;代表双引号。apos;或#39;代表单引号注意apos;在旧的HTML4中并非标准但在HTML5及XML中可用#39;是更通用的数字引用。为什么需要转义想象一下你用JavaScript动态生成一个按钮let userName ‘O’Reilly‘; // 用户名里有个单引号 let buttonHtml ‘button onclick“alert(‘’ userName ‘’)“欢迎/button‘;如果不处理生成的HTML会是button onclick“alert(‘O’Reilly‘)“.../button这里的单引号会提前闭合onclick属性的值导致语法错误甚至XSS漏洞。正确的做法是将其转义为#39;let safeUserName userName.replace(//g, ‘#39;‘);在HTML属性值中如果属性值本身用双引号包裹那么内部的双引号必须转义如果用单引号包裹内部的单引号需要转义。为了省事和清晰我个人的习惯是属性值统一用双引号包裹内部如果出现双引号一律使用quot;转义。3.2 “与”符号一切转义的开端amp;代表符号本身。这是最容易被忽略但也最危险的一个。因为是转义序列的开始。考虑这个URL链接a href“/search?qfoobarbaz”搜索/a你的本意是传递参数qfoo和barbaz。但浏览器解析时会认为bar是一个字符实体的开始直到遇到下一个或;才会结束这破坏了URL的结构。正确的写法必须是a href“/search?qfooamp;barbaz”搜索/a在HTML中凡是出现在属性值或文本内容里的除非它是某个合法实体如copy;的一部分否则都应该被转义为amp;。这是编写健壮HTML的第一条军规。3.3 不间断空格与版权符号常用实体记一记nbsp;代表一个不间断空格Non-Breaking Space。浏览器不会在此处换行。常用于保持特定文字在一起比如“10 kg”或者在前端做简单排版时但CSS才是排版的正道。copy;代表版权符号©。reg;代表注册商标符号®。mdash;代表长破折号—。这些实体更多是为了方便记忆和输入它们对应的字符通常可以直接用UTF-8编码保存和显示。但在某些受限环境如旧系统或为了语义清晰时使用实体引用是个好习惯。注意关于转义一个核心原则是在文本内容或属性值中需要对有特殊HTML语义的字符进行转义。而在script或style标签内部规则由JavaScript和CSS语法决定HTML转义符在其中不生效除非这些内容是被当做文本字符串注入的。例如在script里写if (a b)这个不需要转义为lt;因为JS解析器能理解它。4. 实战场景深潜不同语境下的转义策略与自动化工具理解了原理我们来看看在不同技术栈和场景下如何具体应用和自动化处理转义。4.1 场景一纯静态HTML与模板当你手写静态HTML或使用像Jinja2、Thymeleaf、Handlebars这样的服务端模板时你需要手动或借助模板引擎的自动转义功能。手动转义就像前文例子在需要的地方直接写入实体引用。模板自动转义现代模板引擎默认通常是开启自动转义Auto-escaping的。例如在Jinja2中{{ user_input }}会自动将、、、等转义。如果你确信一段内容是安全的HTML比如你从数据库取出的是富文本编辑器生成的、已消毒的内容则需要使用{{ content|safe }}来告诉模板引擎不要转义。这是一个关键的安全边界决策必须谨慎。4.2 场景二JavaScript动态生成HTMLDOM操作这是前端开发中最常见的场景也是XSS漏洞的高发区。绝对不要使用字符串拼接然后直接赋值给innerHTML错误示范危险const userComment ‘img src“x” onerror“stealCookie()”‘; // 恶意输入 document.getElementById(‘content‘).innerHTML ‘用户说’ userComment; // 脚本被执行正确做法1使用textContent或innerText如果只是为了显示纯文本这是最安全、最高效的方法。它会将内容作为纯文本处理任何HTML标签都会被原样显示而不会解析。document.getElementById(‘content‘).textContent ‘用户说’ userComment; // 页面会安全地显示字符串用户说img src“x” onerror“stealCookie()”正确做法2使用DOM API创建节点对于需要生成复杂结构的情况使用document.createElement、setAttribute、appendChild等方法。const link document.createElement(‘a‘); link.href ‘/search?q‘ encodeURIComponent(keyword) ‘amp;sortdesc‘; // URL参数编码 link.textContent ‘搜索‘; // 文本内容安全 container.appendChild(link);正确做法3使用现代前端框架React, Vue, Angular这些框架的模板/JSX语法在底层默认进行了转义处理极大地提升了安全性。React在JSX中大括号{}内的变量默认会被转义。div{userInput}/div是安全的。如果你确实需要插入原始HTML必须显式使用dangerouslySetInnerHTML其命名就是为了警示你。Vue双花括号{{ }}插值也会自动转义。需要原始HTML时使用v-html指令同样需要警惕。4.3 场景三服务器端与数据持久化数据在进入数据库之前应该如何处理这里有一个重要原则存储原始数据在展示层进行转义。不要在接收用户输入后就急匆匆地用replace(//g, ‘lt;‘)把数据“消毒”然后存进数据库。因为你存储的lt;可能用于多种输出场景网页、移动端API、纯文本邮件而lt;只对HTML上下文有意义。存储原始数据保证了数据的纯净性和最大复用性。转义的责任应该交给最终的渲染层或序列化层。例如在Node.js中可以使用he这样的库进行编码/解码。在PHP中使用htmlspecialchars($string, ENT_QUOTES | ENT_HTML5, ‘UTF-8‘)进行输出转义。在Java中使用Apache Commons Text的StringEscapeUtils.escapeHtml4()或OWASP ESAPI库。4.4 自动化工具与库推荐前端浏览器对于少量动态内容手动textContent或框架内置能力足够。如果需要从字符串安全生成DOM可以考虑使用DOMParserAPI但要注意其上下文。Node.jshe库是功能最全面、遵循标准最严格的HTML实体编码/解码库。PHP内置的htmlspecialchars和htmlentities函数是主力。记住htmlspecialchars只转义必要的几个字符通常就够用了。Python标准库html模块提供了html.escape()函数。通用原则选择一个活跃维护、经过安全审计的库并理解它转义的字符集和规则。5. 安全红线转义与XSS防御的深度绑定我们反复提到XSS跨站脚本攻击因为HTML转义是防御XSS最基础、最重要的一道防线。XSS的本质是攻击者能够向你的网页中注入恶意脚本并在其他用户的浏览器中执行。转义如何防御XSS攻击者注入的载荷通常包含script、img onerror、a href“javascript:等HTML/JS片段。通过在输出到HTML上下文时将转义为lt;将转义为amp;将“转义为quot;这些载荷就会从“可执行的代码”变成“无害的纯文本”被显示出来。但是转义不是银弹必须考虑上下文Context这是很多开发者会踩的坑。转义只在对应的上下文中有效。HTML内容上下文Content Context就是我们主要讨论的在标签体内用lt;、gt;、amp;。HTML属性上下文Attribute Context在标签的属性值里除了上述字符还要注意根据包裹属性值的引号类型来转义引号。永远使用引号包裹属性值onclick“alert(‘apos;‘)”比onclickalert(‘apos;‘)安全得多。URL属性上下文URL Attribute Context比如href、src。这里光HTML转义不够还需要进行URL编码encodeURIComponent防止javascript:协议等攻击。a href“ encodeURIComponent(userInput) “是错误且危险的因为javascript:被编码后依然是一个合法的href值。正确的做法是白名单校验协议只允许http:、https:、mailto:。JavaScript上下文JavaScript Context如果数据要插入到script标签内的JS变量中HTML转义无效需要用的是JavaScript字符串转义如将“转义为\“换行转义为\n或更推荐的做法使用JSON.stringify()将数据序列化后输出。CSS上下文CSS Context同样在style标签或style属性中需要遵循CSS的转义规则。最佳安全实践组合拳输入验证与过滤在接收端对数据类型、长度、格式进行严格校验如手机号只能是数字。存储原始数据在数据库存最原始、干净的数据。输出编码转义根据数据将要被放置的输出上下文在最后一刻进行正确的编码HTML编码、URL编码、JS编码等。使用安全框架与库利用模板引擎的自动转义、前端框架的数据绑定特性。实施内容安全策略CSP作为最后一道防线通过HTTP头Content-Security-Policy限制页面可以加载和执行脚本的来源即使有XSS漏洞也能极大程度限制其危害。6. 进阶在MyBatis、XML及其他场景中的“”和“”标题的相关热词里提到了“mybatis小于号转义”这引出了另一个常见场景在XML或类XML语言如MyBatis的SQL映射文件中处理特殊字符。MyBatis的*.xml文件本身就是XML格式。XML和HTML在特殊字符上高度相似和定义标签。定义实体引用。“和‘包裹属性值。因此当你在MyBatis的select、if等标签中编写SQL语句时如果SQL里包含比较运算符、或者逻辑运算符AND、OR就会和XML标签语法冲突。在MyBatis XML中的解决方案使用XML实体和HTML一样使用lt;和gt;。select id“selectUsers” SELECT * FROM users WHERE age lt; 18 /select使用CDATA区块将整段SQL包裹在![CDATA[ ... ]]中。CDATA内的所有内容都会被XML解析器视为纯文本忽略任何标签和实体。select id“selectUsers” ![CDATA[ SELECT * FROM users WHERE age 18 AND status 0 ]] /select这是我最推荐在MyBatis中处理复杂SQL的方式一劳永逸避免到处写lt;。但要注意CDATA内部不能再包含]]这个结束标记否则需要拆分。其他类似场景在字符串资源文件如.properties中通常不需要转义按字面存储即可。在JSON数据中JSON有自己的语法和转义规则如\“表示双引号\n表示换行。在将JSON嵌入HTML的script标签时需要先对JSON字符串进行JavaScript字符串转义或者更好的办法是通过AJAX动态获取JSON数据完全避免将其内联在HTML中。在正则表达式中正则表达式中的许多字符如.、*、?、\有特殊含义有时需要转义使用反斜杠\但这和HTML转义是两码事。7. 调试与排查当转义出错时如何快速定位即使知道了所有规则在复杂的动态应用中转义问题仍可能发生。页面显示乱码、样式错乱、交互失效都可能是转义不当引起的。排查工具箱浏览器开发者工具Elements面板这是你的第一道防线。查看渲染出的DOM结构与你预期的HTML源代码进行对比。如果看到lt;被直接显示为文本说明这里可能该用innerHTML的地方用了textContent或者该关闭转义的地方没关。如果看到被解析成了标签的一部分说明转义缺失。查看网络请求与响应在“Network”面板中查看服务器返回的原始HTML或JSON数据。确认数据在离开服务器时是否已被正确编码。有时问题出在后端没有正确转义。隔离测试创建一个最简单的HTML文件手动写入你怀疑有问题的代码段看浏览器如何渲染。这能帮你快速排除框架或复杂上下文的干扰。代码审查重点关注以下高危模式字符串拼接innerHTML/outerHTML。eval()或new Function()动态执行包含用户输入的字符串。模板引擎中滥用|safe、v-html、dangerouslySetInnerHTML等“危险”方法。动态构建的href、src、onclick等属性其值来源于用户输入。一个经典的调试案例问题一个用户生成的链接在页面上显示为https://example.com/?qfoobarbaz但点击后控制台报错URL解析失败。 排查右键链接“检查元素”看到HTML是a href“https://example.com/?qfoobarbaz”。问题很明显bar没有被转义。浏览器将其解析为字符实体的一部分。解决方案在服务器端生成链接或前端拼接时确保被替换为amp;或者对整个URL进行正确的编码。处理好转义问题就像是给你的Web应用穿上了一件基础的防弹衣。它不炫酷但至关重要。从理解和的转义开始建立起对上下文安全编码的敏感度你就能写出更健壮、更安全的代码。记住安全无小事转义是基石。
尧图网络