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: