js值字符集编码以及对其应用的理解

最近一直在忙项目的事，就没有更新了。

正好碰到编码的问题，看的差不多就写写了。

首先得搞懂字符集和编码的区别；（字符集定义的是码点，即相应的值对应的字符；而编码则是怎么解析这些二进制位数，具体的可以查看http://www.ruanyifeng.com/blog/2014/12/unicode.html）

现在主要的字符集用的都是unicode和ascII字符集值，我今天也就主要讲一下这两种字符集。

先说一下字符集的由来:

计算机发明后，为了在计算机中表示字符，人们制定了一种编码，叫ASCII码。ASCII码由一个字节中的7位(bit)表示，范围是0x00 -

0x7F 共128个字符。

后来他们突然发现，如果需要按照表格方式打印这些字符的时候，缺少了“制表符”。于是又扩展了ASCII的定义，使用一个字节的全部8位(bit)来表示字符了，这就叫扩展ASCII码。范围是0x00

- 0xFF 共256个字符。 中国人利用连续2个扩展ASCII码的扩展区域（0xA0以后）来表示一个汉字，该方法的标准叫GB-2312。后来，日文、韩文、阿拉伯文、台湾繁体（BIG-5）……都使用类似的方法扩展了本地字符集的定义，现在统一称为

MBCS

字符集（多字节字符集）。这个方法是有缺陷的，因为各个国家地区定义的字符集有交集，因此使用GB-2312的软件，就不能在BIG-5的环境下运行（显示乱码），反之亦然。

为了把全世界人民所有的所有的文字符号都统一进行编码，于是制定了UNICODE标准字符集。UNICODE

使用2个字节表示一个字符(unsigned shor

int、WCHAR、_wchar_t、OLECHAR)。这下终于好啦，全世界任何一个地区的软件，可以不用修改地就能在另一个地区运行了。虽然我用

IE 浏览日本网站，显示出我不认识的日文文字，但至少不会是乱码了。UNICODE 的范围是 0x0000 - 0xFFFF

共6万多个字符(后来又扩展了2的5次方)，其中光汉字就占用了4万多个；

所以虽然有了这些对应的码点，但是不同的环境下编码格式又不一样；

就比如在JS中，\xXX这种格式的字符代表的就是ASCII值，而\uXXXX代表的就是unicode值，这些都是人为规定出来的（刚开始的时候很纠结，它为什么会是这样呢，其实只是规定的一种形式罢了）；而码点所对应的值其实二进制、八进制、十六进制都没有关系，都是可以映射的；

十六进制：  \u4f60\u597d\uff0c\u6781\u5ff5\u7f51\uff01
十进制：你好，极念网！

有些人就想了，转码干嘛呀，有什么用处啊，正常情况下电脑不都根据我们的含义给转换了吗？有些环境下，特别是我们开发中，解析环境不同，就容易造成乱码，所以才出现统一的编码格式，那么为什么我们要在Js文件中，把汉字进行处理呢？因为如果单独的JS文件中存在汉字，而正好JS文件本身的编码格式和网页文件格式不一致，就很容易出现JS乱码现象。

说点题外话，其实本身看这些编码并没有什么难的，把这些东西记住就OK了，难的其实是在应用中，我是在解决正则表达式映射的时候出现的这些问题，然后才来观摩这些内涵知识的，哈哈

记几点过程中的坑吧

1.js字符串中的反斜杠其实代表着转义，想要用就得\,要不然如果出现在字符串里面，应该是要直接转义为unicode值的；如“\u2213”其实就代表着一个字符；所以最后得看你想得到的究竟是那个字符“\u2213”->对应字符，还是这个编码值“\u2213”->\u2213

2.在过程中想到一个问题，现在想来也就想通了：假如我现在给了一个二进制的数，它代表的到底是什么呢，一个八进制的数，十六进制的，还是一个ascII码值？

其实答案是这样的，其实这个二进制数完全可以对应它所规定的这些值，只不过是看环境罢了，加入在计算机中，可能就解析成对应ascII的字符了呢，只是我们为了把它跟我们现实生活联系起来，所以才搞的各种对应关系而已；比如“\u1111”,”\u”是我们自己规定的；

6.各个进制之间的转换规律

7.一位十六进制的数等于四位二进制的数。一个字节等于8位二进制数；很简单，因为16只能是4个二进制数才可以表示啊，8进制也同理啊；

讲了大半天的理论，都是个人的意见，其实猛的一看，可能对你也没有什么用处，这个只是个人在理解上的一些容易的误区，自己探索；

接下来讲一下js对于这些值的转换吧；

主要用到了这三个charCodeAt()【将字符转化为unicode值】；

fromCharCode（）【将unicode值转化为字符】；

charAt(i)；找到第i位置上的字符

charCodeAt()的参数其实并非什么“\u”，只是它后面接的数而已；所以这个数可以是任何进制，只要你的前缀写明白就好；

fromCharCode（）解析出来的也只是一个数而已，需要你按照规则在前面添加“\u”;

其它的解析其实都是通过各自的规则调用这三个接口而已；说白了碰到unicode值都得通过这三个方法转义，只是有时候可能规则不一样，比如需要先正则找到“\u”,然后转义后面的值；

所以说，真正的对应的值跟前面的这些什么“\u”、”\x”什么的并没有什么关系，它们只是一个环境（比如JS为了解析方便加上的而已）；真正对应的只不过是那个对应的值而已；

以后看问题得分开看，这两天把正则、字符集什么的一块儿看，好懵啊，现在清楚多了，哈哈哈，又很晚了，没人了