我在我的网站的<title>中使用了HTML5和UTF-8的“&”符号。谷歌在其serp上显示与号fine，所有浏览器在其标题中也是如此。
http://validator.w3.org给了我这个:
&没有开始字符引用。(&可能应该被转义为&。)
我真的需要做&
我并不在意我的页面为了验证而验证，但我很好奇人们对这个问题的看法，以及它是否重要以及为什么重要。
好吧，如果它来自用户输入，那么绝对是，因为显而易见的原因。想想如果这个网站没有这样做:这个问题的标题会显示为:我真的需要将“&”编码为“&”吗?
如果它只是echo '<title>Dolce & Gabbana</title>';严格来说，你不需要这么做。这样会更好，但如果你不这样做，没有用户会注意到区别。
是的。正如错误所示，在HTML中，属性是#PCDATA，这意味着它们被解析了。这意味着您可以在属性中使用字符实体。使用&本身是错误的，如果不是因为浏览器宽容，而且这是HTML而不是XHTML，就会破坏解析。转义为&一切都会好起来的。
HTML5允许你不转义它，但只有当后面的数据看起来不像一个有效的字符引用。但是，最好是忽略这个符号的所有实例，而不是担心哪些应该是，哪些不需要是。
记住这一点;如果你没有转义&到&，这对你创建的数据来说已经很糟糕了(代码很可能是无效的)，你也可能没有转义标记分隔符，这对用户提交的数据来说是一个巨大的问题，这很可能导致HTML和脚本注入，cookie窃取和其他漏洞。
请转义你的代码。这将在将来为您省去很多麻烦。
这取决于分号在&附近结束的可能性，导致它显示完全不同的内容。
例如，当处理来自用户的输入时(例如，如果在标题标签中包含用户提供的论坛帖子的主题)，您永远不知道他们可能会在哪里放置随机分号，并且可能会随机显示奇怪的实体。所以在这种情况下一定要逃避。
当然，对于您自己的静态HTML内容，您可以跳过它，但是包含适当的转义太琐碎了，因此没有理由避免它。
是的，如果可能的话，您应该尝试提供有效的代码。
大多数浏览器会无声地纠正这个错误，但是依赖浏览器中的错误处理存在一个问题。对于如何处理不正确的代码没有标准，因此每个浏览器供应商都要尝试找出如何处理每个错误，结果可能会有所不同。
一些浏览器可能会有不同反应的例子是，如果你把元素放在表格中，但在表格单元格之外，或者你把链接嵌套在彼此之间。
对于您的特定示例，它不太可能导致任何问题，但是浏览器中的错误更正可能会导致浏览器从标准兼容模式变为怪癖模式，这可能会使您的布局完全崩溃。
因此，您应该在代码中纠正这样的错误，如果没有其他错误，则可以使验证器中的错误列表保持简短，以便您可以发现更严重的问题。
如果你说的是静态文本
<title>Foo & Bar</title>
存储在硬盘上的某个文件中并直接由服务器提供，那么是的:它可能不需要转义。
然而，由于现在很少有HTML内容是完全静态的，我将添加以下免责声明，假设HTML内容是从其他来源生成的(数据库内容、用户输入、web服务调用结果、遗留API结果，……):
如果你不转义一个简单的&，那么很可能你也不转义&或a 或<b>或<script src="http://attacker.com/evil.js">或任何其他无效文本。这意味着您最多只能错误地显示您的内容，并且更有可能受到XSS攻击。
换句话说:当您已经检查和转义其他更有问题的情况时，那么几乎没有理由留下没有完全损坏但仍然有点可疑的独立&未转义的情况。
HTML5规则不同于HTML4。在HTML5中它不是必需的——除非&号看起来像一个参数名的开头。"©=2"仍然是一个问题，例如，因为©是版权符号。
然而，在我看来，决定编码或不编码取决于下面的文本是更困难的工作。所以最简单的方法就是一直编码。
如果用户将它传递给您，或者它将在URL中结束，您需要转义它。
如果它以静态文本的形式出现在页面上?所有浏览器都能正确地处理这个问题，您不必太担心，因为它可以工作。
如果&在HTML中使用，那么你应该转义它。
如果&在JavaScript字符串中使用，例如，一个警报('This & that');或文档。你不需要用它。
如果你使用文档。写完之后你就应该使用它，例如:document。写(< p >,< / p >)。
你能告诉我们你的头衔是什么吗?当我提交时
<!DOCTYPE html>
<html>
<title>Dolce & Gabbana</title>
<body>
<p>Am I allowed loose & mpersands?</p>
</body>
</html>
到http://validator.w3.org/ -明确要求它使用实验性的HTML 5模式-它没有抱怨&s…
在HTML中，&标记引用的开始，无论是字符引用还是实体引用。从那时起，解析器期望一个表示字符引用的#，或者一个表示实体引用的实体名称，两者后跟一个;。这是正常的行为。
但如果引用名或引用开头的&后面跟着空格或其他分隔符，如"，'，<，>，&，则结尾;甚至一个表示普通符号的引用&也可以省略:
<p title="&">foo & bar</p>
<p title="&">foo & bar</p>
<p title="&">foo & bar</p>
只有在这些情况下，才能结束;或者甚至引用本身被省略(至少在HTML 4中)。我认为HTML 5需要结尾;。
但是规范建议总是使用字符引用&或者实体引用&为了避免混淆:
作者应该使用“&”(ASCII十进制38)而不是“&”，以避免与字符引用(实体引用打开分隔符)的开头混淆。作者还应该在属性值中使用“&”，因为CDATA属性值中允许使用字符引用。
我认为这已经变成了一个“当浏览器不关心时，为什么要遵循规范”的问题。以下是我的概括回答:
标准不是“现在”的东西。它们是“未来”的东西。作为开发人员，如果我们遵循web标准，那么浏览器供应商就更有可能正确地实现这些标准，我们就更接近一个完全可互操作的web，在那里CSS黑客、功能检测和浏览器检测都是不必要的。我们不需要弄清楚为什么我们的布局会在特定的浏览器中中断，或者如何解决这个问题。
具体来说，如果HTML5不需要使用&在您的特定情况下，并且您正在使用HTML5文档类型(并且还期望您的用户使用兼容HTML5的浏览器)，那么没有理由这样做。
除了验证之外，编码某些字符对于HTML文档来说是很重要的，这样它才能正确安全地呈现为网页。
编码& as &在任何情况下，对我来说，这是一个更容易遵守的规则，减少了错误和失败的可能性。
比较一下:哪个更容易?哪个更容易搞砸?
方法1
写一些包含&字符的内容。 将它们全部编码。
方法2
(请加一点盐;))
写一些包含&字符的内容。 在具体情况的基础上，查看每个&号。确定:
它是孤立的，因此毫无疑问是一个&号。如。伏特和安培>在这种情况下，就不用费心编码了。 它不是孤立的，但您仍然觉得它是明确的，因为生成的实体不存在，也永远不会存在，因为实体列表永远不会演化。例如，安培和伏特>。在这种情况下，不要费心编码它。 它不是孤立的，也不是模棱两可的。例如，电压和安培>编码。
??
几年前，我们收到一份报告，说我们的一个web应用程序在Firefox中不能正确显示。事实证明，该页面包含一个类似于
<div style="..." ... style="...">
当面对重复的样式属性时，Internet Explorer结合了这两种样式，而Firefox只使用其中一种，因此行为不同。我把标签改成了
<div style="...; ..." ...>
果然，它解决了问题!这个故事的寓意是，浏览器对有效HTML的处理比对无效HTML的处理更一致。所以，现在就修改你该死的加价吧!(或者使用HTML Tidy来修复它。)
更新(2020年3月):W3C验证器不再抱怨转义url。
我正在检查为什么图像url需要转义，因此在https://validator.w3.org中尝试了它。这个解释很好。它强调了即使是url也需要转义。[PS:我猜它将无法转义当它被消费，因为url需要&。有人能澄清一下吗?］
<img alt="" src="foo?bar=qut&qux=fop" />
An entity reference was found in the document, but there is no reference by that name defined. Often this is caused by misspelling the reference name, unencoded ampersands, or by leaving off the trailing semicolon (;). The most common cause of this error is unencoded ampersands in URLs as described by the WDG in "Ampersands in URLs". Entity references start with an ampersand (&) and end with a semicolon (;). If you want to use a literal ampersand in your document you must encode it as "&" (even inside URLs!). Be careful to end entity references with a semicolon or your entity reference may get interpreted in connection with the following text. Also keep in mind that named entity references are case-sensitive; &Aelig; and æ are different characters. If this error appears in some markup generated by PHP's session handling code, this article has explanations and solutions to your problem.
该链接有一个很好的例子，说明了你何时以及为什么需要转义&到&
https://jsfiddle.net/vh2h7usk/1/
有趣的是，我不得不转义字符，以便在这里的回答中正确地表示它。如果我要使用内置的代码示例选项(来自回答面板)，我只需输入&看起来也应该如此。但如果我手动使用<code></code>元素，那么我必须转义，以便正确地表示它:)
