为什么"&reg"在没有边界分号的情况下呈现为"®"

Question

为什么"&reg"在没有边界分号的情况下呈现为"®"

我一直在遇到一个问题,这个问题是通过谷歌adwords推动的营销活动揭示出来的.使用的标准参数之一是"区域".当用户搜索并点击赞助商链接时,Google会生成一个长URL来跟踪点击,并在引荐来源中发送大量内容.我们捕获了这些记录,我们注意到"Region"参数输入错误.应该是什么

http://ravercats.com/meow?foo=bar&region=catnip

Run Code Online (Sandbox Code Playgroud)

而是通过以下方式:

http://ravercats.com/meow?foo=bar®ion=catnip

Run Code Online (Sandbox Code Playgroud)

我已经证实这种情况发生在所有浏览器中.我的理解是HTML实体语法定义如下:

&VALUE;

Run Code Online (Sandbox Code Playgroud)

其中前导边界是&符号,闭合边界是分号.看起来很简单.问题是,这个实体并没有得到尊重,而且它在整个系统中造成了各种各样的破坏.

有谁知道为什么会这样？这是DTD中的错误吗？(我正在寻找当前的HTML DTD以确定我是否可以理解它)我正在试图找出跨浏览器的常见情况,以便实现这一点,因此我在寻找DTD.

这是您可以使用的证明.获取此代码,从中制作HTML文件并在浏览器中呈现它:

<html>
<a href="http://foo.com/bar?foo=bar&region=US&register=lowpass&reg_test=fail&trademark=correct">http://foo.com/bar?foo=bar&region=US&register=lowpass&reg_test=fail&trademark=correct</a>
</html>

Run Code Online (Sandbox Code Playgroud)

编辑:对于那些建议我需要转义整个网址的人来说,上面的示例网址就是这样的例子.真正的网址直接来自Google,我无法控制它的构建方式.这些建议虽然有效,却没有回答这个问题:"为什么会这样？"

Answer 1

Alo*_*hci 40

虽然有效的字符引用最后总是有分号,但是出于向后兼容的原因,一些无分号的无效命名字符引用是现代浏览器的HTML解析器可识别的.

要么你知道,整个名单是什么,或者你遵循当HTML5规则&是不被转义有效(E,G,随后在一个空格),或者以其他方式总是逃避&如&如有任何疑问.

作为参考,没有分号识别的命名字符引用的完整列表是:

AElig,AMP,Aacute,Acirc,Agrave,Aring,Atilde,Auml,COPY,Ccedil,ETH,Eacute,Ecirc,Egrave,Euml,GT,Iacute,Icirc,Igrave,Iuml,LT,Ntilde,Oacute,Ocirc,Ograve, Oslash,Otilde,Ouml,QUOT,REG,THORN,Uacute,Ucirc,Ugrave,Uuml,Yacute,aacute,acirc,acute,aelig,agrave,amp,aring,atilde,auml,brvbar,ccedil,cedil,分,副本, curren,deg,divide,eacute,ecirc,egrave,eth,euml,frac12,frac14,frac34,gt,iacute,icirc,iexcl,igrave,iquest,iuml,laquo,lt,macr,micro,middot,nbsp,not, ntilde,oacute,ocirc,ograve,ordf,ordm,oslash,otilde,ouml,para,plusmn,pound,quot,raquo,reg,sect,shy,sup1,sup2,sup3,szlig,thorn,times,uacute,ucirc, ugrave,uml,uuml,yacute,yen,yuml

但是,应该注意的是,只有在属性值中,如果下一个字符是=字母或字母数字ASCII字符,则不通过符合HTML5解析器来处理上述列表中的命名字符引用.

有关带或不带分号的命名字符引用的完整列表,请参见此处

我遇到了一个有趣的案例,其中URL中的`&provider = XXX&reg = 1`被一些过时或不常见的浏览器替换为`provider =XXX®= 1`完全打破了脚本. (5认同)
我不知道有任何实体可以在没有分号的情况下“逃脱”。感谢您回答问题并为我指出一个很好的参考。 (2认同)
死链接.https://html.spec.whatwg.org/multipage/syntax.html#named-character-references (2认同)

Answer 2

Juk*_*ela 11

这是一个非常混乱的业务,取决于上下文(文本内容与属性值).

正式地,通过HTML规范直到并包括HTML 4.01,如果下一个字符不是名称字符,则实体引用可能不会以分号结尾.因此,例如&region=,语法正确但未定义,因为实体region尚未定义.XHTML需要使用尾随分号.

但是,浏览器传统上仍然遵循其他规则.由于查询URL的通用语法,它们进行解析,例如href="http://ravercats.com/meow?foo=bar&region=catnip",&region不将其视为实体引用,而仅视为文本数据.作者大多使用这样的结构,即使它们正式不正确.

与问题似乎说的相反,href="http://ravercats.com/meow?foo=bar&region=catnip"实际上效果很好.当字符串不在属性值中但在文本内容中时出现问题,这种情况相当罕见:我们通常不会在文本中编写URL.在文本中,&region=进行处理以便将&reg其识别为实体引用(对于"®"),其余的只是字符数据.这种奇怪的行为在HTML5 CR中正式出现,其中第8.2.4.69节标记字符引用描述了"双重标准":

如果字符引用正在作为属性的一部分使用,并且匹配的最后一个字符不是";" (U + 003B)字符,下一个字符是"="(U + 003D)字符或ASCII数字,大写ASCII字母或小写ASCII字母的范围,然后,由于历史原因,所有字符都是在U + 0026 AMPERSAND字符(&)必须未消耗之后匹配,并且不返回任何内容.

因此,在属性值中,甚至&reg=不会被视为包含字符引用,并且更少&region=.(但reg_test=由于下划线的特征,情况会有所不同.)

在文本内容中,适用其他规则.&region=然后,该构造会导致解析错误(通过HTML5 CR规则),但具有明确定义的错误处理:&reg被识别为字符引用.

有趣的是,在现实世界中,我基本上是从Google收集HTTP_REFERER并将其解析为cookie.我收到的URL已经通过这种方式解析了.感谢您对来源的简明解释. (2认同)

Answer 3

jch*_*apa 9

也许尝试替换你&的&？&符号是必须在HTML中转义的字符,因为它们被保留用作实体的一部分.

Answer 4

Fra*_*dor 5

这是一个简单的解决方案，它可能不适用于所有情况。

\n\n

所以由此可知：

\n\n

http://ravercats.com/meow?status=Online&region=Atlantis

\n\n

对此：

\n\n

http://ravercats.com/meow?region=Atlantis&status=Online

\n\n

因为&reg我们知道会触发特殊字符\xc2\xae

\n\n

警告：如果您无法控制 URL 查询字符串参数的顺序，那么您必须将变量名称更改为其他名称。

\n

归档时间：	12 年，5 月前
查看次数：	47240 次
最近记录：	7 年，4 月前