我在我的网站的<title>中使用了HTML5和UTF-8的“&”符号。谷歌在其serp上显示与号fine,所有浏览器在其标题中也是如此。
http://validator.w3.org给了我这个:
&没有开始字符引用。(&可能应该被转义为&。)
我真的需要做&
我并不在意我的页面为了验证而验证,但我很好奇人们对这个问题的看法,以及它是否重要以及为什么重要。
我在我的网站的<title>中使用了HTML5和UTF-8的“&”符号。谷歌在其serp上显示与号fine,所有浏览器在其标题中也是如此。
http://validator.w3.org给了我这个:
&没有开始字符引用。(&可能应该被转义为&。)
我真的需要做&
我并不在意我的页面为了验证而验证,但我很好奇人们对这个问题的看法,以及它是否重要以及为什么重要。
当前回答
如果你说的是静态文本
<title>Foo & Bar</title>
存储在硬盘上的某个文件中并直接由服务器提供,那么是的:它可能不需要转义。
然而,由于现在很少有HTML内容是完全静态的,我将添加以下免责声明,假设HTML内容是从其他来源生成的(数据库内容、用户输入、web服务调用结果、遗留API结果,……):
如果你不转义一个简单的&,那么很可能你也不转义&或a 或<b>或<script src="http://attacker.com/evil.js">或任何其他无效文本。这意味着您最多只能错误地显示您的内容,并且更有可能受到XSS攻击。
换句话说:当您已经检查和转义其他更有问题的情况时,那么几乎没有理由留下没有完全损坏但仍然有点可疑的独立&未转义的情况。
其他回答
几年前,我们收到一份报告,说我们的一个web应用程序在Firefox中不能正确显示。事实证明,该页面包含一个类似于
<div style="..." ... style="...">
当面对重复的样式属性时,Internet Explorer结合了这两种样式,而Firefox只使用其中一种,因此行为不同。我把标签改成了
<div style="...; ..." ...>
果然,它解决了问题!这个故事的寓意是,浏览器对有效HTML的处理比对无效HTML的处理更一致。所以,现在就修改你该死的加价吧!(或者使用HTML Tidy来修复它。)
这取决于分号在&附近结束的可能性,导致它显示完全不同的内容。
例如,当处理来自用户的输入时(例如,如果在标题标签中包含用户提供的论坛帖子的主题),您永远不知道他们可能会在哪里放置随机分号,并且可能会随机显示奇怪的实体。所以在这种情况下一定要逃避。
当然,对于您自己的静态HTML内容,您可以跳过它,但是包含适当的转义太琐碎了,因此没有理由避免它。
HTML5规则不同于HTML4。在HTML5中它不是必需的——除非&号看起来像一个参数名的开头。"©=2"仍然是一个问题,例如,因为©是版权符号。
然而,在我看来,决定编码或不编码取决于下面的文本是更困难的工作。所以最简单的方法就是一直编码。
在HTML中,&标记引用的开始,无论是字符引用还是实体引用。从那时起,解析器期望一个表示字符引用的#,或者一个表示实体引用的实体名称,两者后跟一个;。这是正常的行为。
但如果引用名或引用开头的&后面跟着空格或其他分隔符,如",',<,>,&,则结尾;甚至一个表示普通符号的引用&也可以省略:
<p title="&">foo & bar</p>
<p title="&">foo & bar</p>
<p title="&">foo & bar</p>
只有在这些情况下,才能结束;或者甚至引用本身被省略(至少在HTML 4中)。我认为HTML 5需要结尾;。
但是规范建议总是使用字符引用&或者实体引用&为了避免混淆:
作者应该使用“&”(ASCII十进制38)而不是“&”,以避免与字符引用(实体引用打开分隔符)的开头混淆。作者还应该在属性值中使用“&”,因为CDATA属性值中允许使用字符引用。
除了验证之外,编码某些字符对于HTML文档来说是很重要的,这样它才能正确安全地呈现为网页。
编码& as &在任何情况下,对我来说,这是一个更容易遵守的规则,减少了错误和失败的可能性。
比较一下:哪个更容易?哪个更容易搞砸?
方法1
写一些包含&字符的内容。 将它们全部编码。
方法2
(请加一点盐;))
写一些包含&字符的内容。 在具体情况的基础上,查看每个&号。确定:
它是孤立的,因此毫无疑问是一个&号。如。伏特和安培>在这种情况下,就不用费心编码了。 它不是孤立的,但您仍然觉得它是明确的,因为生成的实体不存在,也永远不会存在,因为实体列表永远不会演化。例如,安培和伏特>。在这种情况下,不要费心编码它。 它不是孤立的,也不是模棱两可的。例如,电压和安培>编码。
??