WEB安全第七课 层叠样式表 之三 字符编码 |
为了在CSS字符串里使用一些保留字符或有问题的字符,CSS提供了一套不太正统的转义处理策略:用一个反斜杠(\)后面跟1〜6位的十六进制数字。
例如,根据这个策略,字母e可以编码为“\65”、“\065”以及“\000065”。但是,如果字母e后面紧挨着的字符就是一个有效的十六进制数字时,这三种写法里只有最后一种是不会产生歧义的;因为把“teak”编码成“t\65ak”就有问题了,此时转义序列会按照“\65A”来解析,这就变成Unicode里一个阿拉伯语符号了。 ![]() 为避免这一问题,CSS规范给出了一个很笨拙的妥协方案,就是在每个转义序列后面再加一个空格符作为终止的标识,要还原字符串时再移除这个空格符(例如:“t\65ak”)。真遗憾,其实可以采用更为人熟知、具有固定长度的C风格转义序列,如\x65。 除了数字形式的转义之外,还可以在一个非十六进制数字的字符前加反斜杠作为转义处理。采用这种方式时,紧跟在转义符后的那个字符就按字面意思直接解析了。这种机制可以用来转义引号字符和反斜杠本身,但不能用于转义由HTML控制的字符,如尖括号。此前提到的HTML解析优先于CSS解析顺序,会使这种处理出现问题。 ![]() 由于W3C草案里一些语焉不详的规定,导致了某些颇为荒谬的差异,所以许多CSS解析器对本该用引号括起的字符串里的任意转义序列。更加雪上加霜的是,在IE浏览器里,对转义序列解析的优先级甚至要高于对伪函数语法的解析,结果导致以下两个例子效果其实是一样的: ✍🚠❌🐞 引用 而更复杂的是,出于对代码容错性的无度追求,在微软的浏览器实现里,url(...)值里的反斜杠符号却不会被识别成转义符,这种做法,仅仅为了照顾那些输人URL时输错成反斜杠的用户的感情。 👮♂️👠🛋😷 林林总总的类似问题,导致要检测一个已知的有危害性的CSS语法变得非常容易出错。#389: WEB安全第八课第一节:
帖子热度 1.2万 ℃
小执念殷勤地给楼主揉揉肩捶捶背,楼主奖励2 个 金币.
|
|