我可以依靠未转义的 & 符号在文本区域中正确显示吗？
我刚刚注意到我们的代码中的一个例程无法正确转义文本区域中的＆符号：
<textarea>Arts & Crafts</textarea>
令我惊讶的是，这个在我检查的每个浏览器中都有效。关于文本区域内的“&”符号是否有不成文的规则？如果是这样，这是我可以依赖的规则吗？或者这只是浏览器提供的一种便利，以确保错误的页面呈现，并且没有任何保证？
I've just notice a routine in our code that doesn't properly escape an ampersand in a textarea:
<textarea>Arts & Crafts</textarea>
What surprises me is that this works in every browser I check. Is there an unwritten rule about ampersands inside textareas? If so, is it a rule I can depend on? Or is this just a convenience that browsers provide to make sure your faulty page renders and there are no guarantees whatsoever?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
大多数浏览器都会尝试修复页面中出现的错误。 & 符号只能表示 & 符号，因此它是这样显示的。另一种选择是跳过＆符号，或者根本不渲染页面，但所有供应商都认为这种后备是最合乎逻辑的。
例如，当文本为
，因为这也会将è渲染为è。因此在这种情况下必须对 & 进行转义。然而，这是在任何浏览器中都可以以相同方式解决的极少数错误之一。最好不要犯任何错误。这将为您提供最大的成功机会。 ;)
Most browsers will try to fix errors made in the page. The ampersand cannot mean anything else than an ampersand, so it is shown as such. Alternatives would be to skip the ampersand, or not to render the page at all, but all vendors have thought this fallback to be the most logical one.
It will give you problems when the text is for example
<textarea>Use è to show an è</textarea>, because this will renderèas anètoo. So in this case the ampersand must be escaped.It is however one of the very few errors that are solved the same way in any browser. It is best not to make any error. That will give you the greatest chance on succes. ;)
这只是一个方便；独立的
&是无效的 HTML 和 XHTML。It's just a convenience; a standalone
&is invalid HTML and XHTML.