前端编码问题汇总
众所周知，字符的编码方式有两种惯例，一种是很古老的对ASCII码做某种语言子集的扩展，比如big5和gb2312，分别是繁体字扩展和简体字扩展，两者互不兼容，与之类似的编码还有ISO系列，各个拉丁文的子编码集合也不相互兼容，这种编码的好处是编码集合很小，坏处是不能同时使用多种语言，于是就有了另一种编码惯例：“万国码”，全球所有语言做成一个码表，即unicode码 表，显然，这种编码的坏处是码表太庞大，好处是同时使用多种语言。所谓的utf-7、utf-8之类就是unicode的某种相对高效的实现，不管某个字 符用utf编码为几个字节，他们都属于同一个unicode超集。我们常遇到的中文编码是gb2312、gbk、gb18030和utf-8，不严谨的 讲，前三者大致相互兼容，但都和utf-8不兼容。
浏览器如何发送一个带有中文的URL
整个过程分两个阶段，1，发送URL请求，2，接收数据并呈现
URL是一种编码“方法”，编码结果依赖于所采用的“码表”，即汉字的内码表示形式。所以，相同汉字有N多种URL编码结果，“淘宝”的utf8编码为“%E6%B7%98%E5%AE%9D”，gbk编码为“%CC%D4%B1%A6”。
注：一个gb系编码的html页面中的form提交，表单中的中文编码会进行URL编码，但是以gbk格式作转码，utf8页面的form提交，以utf8格式作转码。
浏览器如何以正确的编码渲染页面
HTTP响应的数据起码有三个地方可以埋藏编码信息：
1，http头中的Content-Type
2，html页面中的meta标签中指定charset
3，页面正文数据（浏览器可以解析正文二进制码来判断编码）
浏览器可以从这三个地方获得HTTP响应报文的编码，此外还有两个因素，浏览器默认编码和操作系统语言类型。
如果三者编码不一致，浏览器会首先读取http头中的content-type，若没有设定编码，再查找页面中meta标签中的charset设定，如果 还没有就以浏览器默认编码来显示，如果默认编码没有指定，浏览器会通过解析正文内容来判断编码。所以，页面是gbk编码，即便meta属性中设置 charset=utf-8，只要content-type中设定为gbk（或者GB2312、GB18030），该页面就正常显示，如果这时没有设定 content-type的编码，浏览器就会以meta中的charset属性为准，页面出现乱码。
js如何把字符串编码成gbk的
问题由来：
js引擎内码是unicode，所以通过encodeURI(str)进行URL编码的时候均属utf8编码
所以在gbk编码的html中无法用js计算出gbk格式的URL编码,
因此在ajax过程中也就无法用js来模拟gbk格式URL编码的数据提交
"中文"两字的utf8 URL编码为:%E4%B8%AD%E6%96%87
"中文"两字的gbk URL编码为:%D6%D0%CE%C4
实现原理：
一个gbk编码的html的表单提交时字段的URL编码是和页面编码保持一致的（gbk）
所以这里用模拟表单提交的方法来获得gbk URL编码
当然，前提必须是页面编码也必须为gbk
