我是否应该使用HTML实体(')来使撇号(')字符转义?


38

哪些字符应与其HTML实体一起转义。例如,使用&进行转义&

应该'逃脱'吗?

Answers:


41

我没有评论权限,否则我将把它作为对较早答案的评论。

重复一遍,请勿重复,请勿使用HTML来转义撇号

'

这不是有效的HTML字符实体引用。它是一个XML字符实体参考。至少Firefox和Chrome会将以上内容呈现为HTML文档中的撇号,而Internet Explorer不会。当它拒绝这样做时,它就是遵循标准。

您可以使用来转义HTML中的撇号

'

但是,我一般认为这不是必需的。

http://fishbowl.pastiche.org/2003/07/01/the_curse_of_apos/

http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references


我知道这在发布时是正确的,但是查看Wikipedia文章,&apos现在看来对HTML5有效。话虽这么说,如果您必须支持旧版浏览器或为Outlook编写HTML电子邮件,那么'如果您认为有必要转义字符,则最好坚持。
tomhughes

24

我不同意内特。理想情况下,您应该使用尽可能少的转义符,并使用UTF-8本地表示字符。为此,您需要一个可以处理UTF-8以及正确的字符集声明的编辑器,例如:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

但是,您应该养成一种习惯,以逃避(X)HTML中具有特殊含义的字符,即:

< &lt;
> &gt;
" &quot;
& &amp;
' &#39;

这样可以确保您在编写这些字符时不会意外地编写标记。这对于用户输入,维护安全性尤其重要。它不太明显,但实际上逃脱很重要"。如果字符串最终以HTML属性(title="something"等等)结尾,则用户可以结束该属性并插入自己的标记。想象一下,如果用户输入" onclick="alert('hello');并将其插入到title="..."

如果您使用的是PHP,则可以使用该htmlspecialchars函数执行此操作。其他语言可能具有其他类似功能。

更新:我对apos问题已得到纠正。讨厌的IE浏览器。


我现在有两个矛盾的答案。一个建议转义为',另一个建议不转义。我应该相信什么?
汤姆(Tom)

7
简而言之。您可以自行决定是否逃避它。如果这样做,请使用&#39;not &apos;。如果出于某种原因而对HTML属性使用单引号,例如title='something'您显然必须转义该属性值内的任何单引号。
nitro2k01 2011年

您的第二段对我来说很重要,当我看到git commit中的红色文本段由于未转义的撇号而使
eballeste

6

这取决于您的用例,但'通常不建议您使用自然语言,因此,除非您的XML中包含计算机代码,否则不会出现此问题。

在翻译了字符串的地方,我们发现一些翻译器用unicode卷曲引号替换了右引号,但将直引号保留为开环引号,使它们在视觉上不平衡且看起来不专业。

unicode字符应该'尽可能替换,并且应该替换"。这很有用,因为计算机无法将卷曲标点识别为特殊字符。(尽管我很高兴看到Stack Overflow / Chrome认为' don’t'是拼写错误,而对' don't' 感到满意。)

它没有帮助,我们有非常诱人的'"字符右边的键盘上。


1

因此,让我们看看StackExchange本身是否使用HTML实体对撇号进行编码。

以下是此页面源代码中的一些示例。

(1)问题标题:已编码。

Should I escape the Apostrophe ( &#39; ) character with its HTML entity (&amp;#39;)?

(2)得出答案:未编码。

But I don't believe it is, in general, necessary.

(3)汤姆对nitro2k01的回答的评论:已编码。

I&#39;ve got two contradicting answers now. One recommends escaping &#39; and the other does not. What should I believe?

所以这是双向的。

但是,此页面的源代码从不使用&apos;。所有编码均为形式&#39;。这与nitro2k01相符,并提请不要使用&apos;


1
尽管在所有3种情况下都不需要对其进行HTML编码。
MrWhite 2015年

1

那条弦子去哪儿了?

您的答案取决于上下文:

  1. 如果您要使用此数据在HTML中编写段落,则足以转义<,>和&:

    <p>{string}</p>

  2. 但是,如果您正在写入HTML属性,例如

    <a href='/some/path/{string}'>...</a>

然后,您应该完全摆脱撇号。如果攻击者为此输入以下内容,这可能是攻击媒介string

string = "' onmouseover='alert(\"nasty script here!\")' data-ignore='"
  1. 双引号也一样。我什至读过反引号`易受攻击,因为它也可以用于HTML属性。如果部署例程中没有自动HTML语法检查脚本,请假定可以使用这三种方法中的任何一种,并且必须对HTML属性进行转义。

  2. 在极端情况下,即使未引用的属性也是有效的,因此空格字符也需要转义。而且!@$%()=+{}[,和],所有这些都可以打出来的属性,并允许插入一个新的。

我所做的

要在JavaScript中进行转义,我使用JQuery $(element).text(string)$(element).attr(attrname, string)为我进行转义。使用时要非常小心$(element).html(unsafe),它不能逃脱HTML!

在服务器端代码上,我必须仔细评估每种情况的风险,并仔细阅读文档。这将取决于您使用的特定语言和库,例如Rails,Django,原始PHP,Drupal等。

资料库

如果您正在考虑尽早解决问题,那么在问题尚未进入数据库之前,请紧紧抓住。HTML转义存储在数据库中的文本可能会让您大吃一惊。如果您以后想要允许某些HTML标签,但不允许其他HTML标签(如斜体,粗体,颜色和表格)怎么办?如果你错过了在第一阶段的东西,但你的逃避者已逃走&作为&amp;"作为&quot;?会把它们变成&amp;amp;&amp;quot;吗?

我的方法是仅对数据库执行SQL转义,但保留所有HTML特殊字符以供以后处理。这样,我可以轻松调试和微调HTML转义。注意,这也意味着如果我自己的SQL表具有用户提供的字符串,我将不信任它们。

道德

永远不要相信用户控制的输入,并且总是引用HTML属性!

基于:HTML转义比 Ryan Grove的&,<,>和“更多


-1

如果您的撇号属于内容,请对其进行转义。可以与代码混淆的任何其他内容字符,请对其进行转义。


“如果您的撇号属于内容,请对其进行转义。” -这似乎是不正确的(好像缺少了“不要”一词)。如果撇号是内容的一部分,那么请不要逃避它-不需要。
MrWhite 2015年

-4

在不使用实际实体的情况下完成工作的最简单方法是使用PHP htmlentities()htmlspecialchars()函数:

$val = htmlspecialchars("Don't", ENT_QUOTES, 'UTF-8');
if($_POST){
  $val = htmlspecialchars(trim($_POST['val']), ENT_QUOTES, 'UTF-8');
}
echo "<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'> 
<html xmlns='http://www.w3.org/1999/xhtml' xml:lang='en' lang='en' class='njs'> 
  <head>
    <meta http-equiv='Content-type' content='text/html;charset=utf-8' />
    <title>Special Characters</title>
    <style type='text/css'>
      @import 'special.css';
    </style>
  </head>
<body>
  <form method='post' action='' id='fm' name='fm'>
    <input type='text' value='$val' name='val' id='val' />
    <input type='submit' value='submit' name='sub' id='sub' />
  </form>
</body>
  <script type='text/javascript' src='special.js'></script>
</html>";

4
你在开玩笑吗?
Su

@Su'恐怕不是...
William Edwards
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.