iview乱码问题处理与反思
问题描述
某天突然返现，原本正常的iview的分页器组件原本是省略号的地方突然变成乱码了
突然返现对这方面内容比较生疏，遂借此机会整理相关原理。
解决过程
首先查看相关css样式，发现iview实现省略号的相关代码如下：
:after {
content: "\2022\2022\2022"
}
自己验证一番，这种样式确实可以展示成省略点号。
这里引出第一个问题：问题1：为什么【\2022】会显示成 •
首先在cssTrick中找到XHTML的特殊字符表说明和unicode编码表，从中可以找到如下对应关系
对照一下上面两张表解释一下这些编码的含义
| 编码 | 详情 |
|---|---|
| •【&bull ;】 | html中的特殊实体（entity），可以被html直接识别 |
| • | •的unicode编码 |
| U2022 | 16进制编码，这里也就是8226的16进制的值 |
| U2219 | 是另一个.字符的编码，这是列出只表明这两个不是一个字符 |
所以可以知道2022是省略号的unicode编码，第一个问题得以解决。
接下来就是 问题2： 要如何处理该乱码问题
对症下药就非常块了，直接找到关于css@charset的描述。
给出了如下关于识别文件编码的说明:
简单来说就是：
文件本身的字节顺序标记 >
响应头中content-type的charset字段 >
css文件中的@charset申明 >
link中的charset申明（虽然上面说被飞起了，但是尝试了下还是生效的）>
默认为utf8格式
最终增加了css的@charset头，问题得以解决
但是仍然存在问题 问题2-引伸: 不申明@charset为什么会乱码，并且是偶现
按照MDN的说法，当文件中不存在任何charset申明的时候，默认是以utf-8的格式解析的。那么就算不加@charset,应该也不会出现乱码的。
这个问题在之后的文档浏览中有所发现：
而出现乱码的css中存在font-family: 微软雅黑; 因此导致css解析出现乱码
到此从项目的角度上该问题应该已经算是解决了，但是在处理的过程中发现了一个点理解不清 问题3：ASC码，unicode, UTF8，gbk有什么区别？
知识点的问题直接查阅就行了，这里发现了一篇写的比较好的知乎回答
这里简单归纳一下：
ASC码：最初使用一个字节的编码，主要包括字母大小写，各种符号等共127个。还加入了很多画表格时需要用下到的横线、竖线、交叉等形状，一直把序号编到了最后一个状态255。从128 到255这一页的字符集被称【扩展字符集】“。
unicode：国际标准编码，规定必须用两个字节，也就是16位来统一表示所有的字符。这时候ASC码这类只需要一个字节的字符，前面就全是0了，存在空间浪费
utf8: 变长编码规范
-
单字节的字符，字节的第一位设为0，对于英语文本，UTF-8码只占用一个字节，和ASCII码完全相同；
-
n个字节的字符(n>1)，第一个字节的前n位设为1，第n+1位设为0，后面字节的前两位都设为10，这n个字节的其余空位填充该字符unicode码，高位用0补足。
这样就形成了如下的UTF-8标记位：
0xxxxxxx
110xxxxx 10xxxxxx
1110xxxx 10xxxxxx 10xxxxxx
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
gbk：纯中文编码。把那些127号之后的奇异符号们直接取消掉, 规定：一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，前面的一个字节（他称之为高字节）从0xA1用到0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。在这些编码里，我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了，连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的”全角”字符，而原来在127号以下的那些就叫”半角”字符了。中国人民看到这样很不错，于是就把这种汉字方案叫做 “GB2312“。GB2312 是对 ASCII 的中文扩展。
到此完成整个问题从原理到项目实现的解决。
