前端开发涉及到的编码问题

Posted 2020-08-30 btg.yoyo

前言

URL只能使用英文字母、阿拉伯数字和某些标点符号，不能使用其他文字和符号。比如，世界上有英文字母的网址"http://www.abc.com"，但是没有希腊字母的网址"http://www.aβγ.com"（读作阿尔法-贝塔-伽玛.com）。这是因为网络标准RFC 1738做了硬性规定：

"...Only alphanumerics [0-9a-zA-Z], the special characters "$-_.+!*‘()," [not including the quotes - ed], and reserved characters used for their reserved purposes may be used unencoded within a URL."

"只有字母和数字[0-9a-zA-Z]、一些特殊符号"$-_.+!*‘(),"[不包括双引号]、以及某些保留字，才可以不经过编码直接用于URL。"

这意味着，如果URL中有汉字，就必须编码后使用。但是麻烦的是，RFC 1738没有规定具体的编码方法，而是交给应用程序（浏览器）自己决定。这导致"URL编码"成为了一个混乱的领域。

如下:

1:地址栏输入和点击url访问浏览器时，chrome下无论请求地址和参数，均经过utf-8编码;非chrome浏览器，其中请求地址用utf-8编码，参数按操作系统编码进行编码（ie下的编码参数部分都不带%）。但参数中含特殊符号时，未确定何特殊符号会被编码。

例子：http://www.google.com/小明|=?param=小明|=
a.上面的url在中文xp的chrome下，发送的请求地址是

http://www.google.com/%E5%B0%8F%E6%98%8E%7C=?param=%E5%B0%8F%E6%98%8E|=

b.在中文xp的firefox下，发送的请求地址是
http://www.google.com/%E5%B0%8F%E6%98%8E%7C=?param=%D0%A1%C3%F7|= 

c.在中文xp的ie下，发送的请求地址是
http://www.google.com/%E5%B0%8F%E6%98%8E%7C=?param=С??|=

2：超链接中的请求，请求地址用utf-8编码，参数用页面编码,但是在ie下的参数不带%号。

在上面的例子中，在页面指定utf-8编码下，参数部分会变成：param=%E5%B0%8F%E6%98%8E|=。但ie会变成param=E5B08FE6988E|=。

3：js进行超链接访问时，和超链接情况一致。

4：ajax异步请求时，ie总是用gbk来编码，包括网页路径和参数，非ie和超链接请求一致。

在上面例子中，ie下发送的请求会变成：http://www.google.com/%D0%A1%C3%F7%7C=?param=d0a1c3f7|=

 

form提交涉及到的编码

 form 表单中有一个 accept-charset  属性,如果没有此属性会用页面编码来提交，如果页面编码没有就是 utf-8编码。

 

两个应用编码不同，一个是GBK编码，另一个是UTF-8编码。现在要在GBK编码的应用里使用表单向UTF-8编码的应用里提交数据，很显然，如果不做特殊处理的话，会出现乱码。 

解决方案：
在GBK编码的页面里编写如下代码： 
<form method="post" action="..." accept-charset="utf-8"> ... </form> 

如此的代码在Firefox等正常的浏览器下没有任何问题，但是遇到IE这个变态浏览器就不灵光了，我们还得用点不入流的手段Hack一下： 
<form method="post" action="..." accept-charset="utf-8" onsubmit="document.charset=‘utf-8‘;"> ... </form> 

 

 

ajax 中涉及到的编码

ajax 提交到服务器的编码上面已经讨论过。但是获取后台内容也会有乱码的情况出现：

如果ajax 后台返回的不是utf-8的编码的二进制流，那么在xmlhttprequest 对象的responseText 方法中字符就会乱码，因为浏览器默认用utf-8来解码。 

我在后台返回时的conent-type 中也明确书写了charset ：gbk 。但是实测没起到作用。 这个等有时间在验证

 

注意：

无论何种方式提交的服务器，浏览器都会转化成ascll字符，然后以ascll对应的码点转成二进制进行传输。对于那么不能直接转成ascll字符的，比如汉字。也会先用以上的编码方式转成ascll字符。
比如：
春节 ==》%E6%98%A5%E8%8A%82  utf-8编码
       ==》 %B4%BA%BD%DA            gbk 编码

在utf-8编码下，一个汉字 会有9个字节进行传输。

在一个html标签的属性中会有长度的限制。比如
a 标签的href 的长度限制，计算这个长度时要注意以上的细节

 

由于各个浏览器处理起来的不一致，所以我们需要用js来处理编码，因为js的处理结果都是一致的，都是utf-8编码。三个函数：

1.escape()

虽然这个函数现在已经不提倡使用了，但是由于历史原因，很多地方还在使用它，所以有必要先从它讲起。

实际上，escape()不能直接用于URL编码，它的真正作用是返回一个字符的Unicode编码值。比如"春节"的返回结果是%u6625%u8282，也就是说在Unicode字符集中，"春"是第6625个（十六进制）字符，"节"是第8282个（十六进制）字符。

  它的具体规则是，除了ASCII字母、数字、标点符号"@ * _ + - . /"以外，对其他所有字符进行编码。在\u0000到\u00ff之间的符号被转成%xx的形式，其余符号被转成%uxxxx的形式。对应的解码函数是unescape()。

　escape对0-255以外的unicode值进行编码时输出%u****格式，其它情况下escape，encodeURI，encodeURIComponent编码结果相同。

  所以，"Hello World"的escape()编码就是"Hello%20World"。因为空格的Unicode值是20（十六进制）

  首先，无论网页的原始编码是什么，一旦被javascript编码，就都变为unicode字符。也就是说，Javascipt函数的输入和输出，默认都是Unicode字符。这一点对下面两个函数也适用。

  其次，escape()不对"+"编码。但是我们知道，网页在提交表单的时候，如果有空格，则会被转化为+字符。服务器处理数据的时候，会把+号处理成空格。所以，使用的时候要小心。可以这样处理下 str.replace(/+/g,"%u002B");

  escape不编码字符有69个：*，+，-，.，/，@，_，0-9，a-z，A-Z

 

2.encodeURI()

encodeURI()是Javascript中真正用来对URL编码的函数。
它着眼于对整个URL进行编码，因此除了常见的符号以外，对其他一些在网址中有特殊含义的符号"; / ? : @ & = + $ , #"，也不进行编码。编码后，它输出符号的utf-8形式，并且在每个字节前加上%。
它对应的解码函数是decodeURI()。 需要注意的是，它不对单引号‘编码。

 

3.encodeURIComponent()

最后一个Javascript编码函数是encodeURIComponent()。与encodeURI()的区别是，它用于对URL的组成部分进行个别编码，而不用于对整个URL进行编码。
因此，"; / ? : @ & = + $ , #"，这些在encodeURI()中不被编码的符号，在encodeURIComponent()中统统会被编码。至于具体的编码方法，两者是一样。
它对应的解码函数是decodeURIComponent()。
encodeURIComponent不编码字符有71个：!， ‘，(，)，*，-，.，_，~，0-9，a-z，A-Z

 

上面说到form post提交的时候可以设置 charset。那ajax提交的时候怎么办？比如怎么把上面三个函数处理过的utf-8编码的字符发送到GBK编码的后台

首先，当我们使用提交时，浏览器会根据当前页面编码，encode一次，然后发送到服务端，服务端接收到表单，会自动dencode一次，通常这个过程是对程序是透明的。即，浏览器把请求翻译成ascll字符传输，服务端接受二进制并翻译成ascll进行dencode。

这个dencode 和前端的encode 的编码不一致问题就来了。

解决：

1.使用escape函数 把中文换成%uxxxx的形式提交。这样浏览器encode的时候不会在处理了。到了后台，dencode完也是这种形式。 之后再用utf-8转一下。

2.

1.在A应用处用encodeURIComponent()2次编码参数数据，如k=中文（utf-8编码为%E4%B8%AD%E6%96%87），进行2次编码后,encodeURIComponent(encodeURIComponent(k))=%25E4%25B8%25AD%25E6%2596%2587

2.将请求发送到url2 = http://www.xxx.com/a.htm?k=%25E4%25B8%25AD%25E6%2596%2587&encoding=utf-8

3.url2对应应用收到这个请求后，web容器会对%25进行解码，变成%，对应request.getParameter("k")=%E4%B8%AD%E6%96%87

4.再URLDecoder.decode("%E4%B8%AD%E6%96%87", "UTF-8")就能解码回原来的中文而不会乱码了。

 

 

 

 

从编码到页面呈现中涉及的编码

我们在开发过程中新建文件（js,css,html），都会有默认的编码方式存储在硬盘上。不过的开发工具新建文件时的编码方式不同。

源代码发布到web容器后，用户在浏览器访问我们的文件，web容器以二进制流发送我们的文件给浏览器。

浏览器要解析这个二进制流。那么问题来了，浏览器用什么编码去解析？

1.根据http协议中的 content-type 中的charset ，content-type中的charset的优先级最高，如果有charset选项浏览器将忽略以下规则

2.html页面中meta标签中的charset。(js,css 也有charset ，如果有将用此charset ，如果没有就用宿主html的charset)

3.浏览器默认charset 

浏览器解析完这个二进制流之后，会把这些信息存在变量中。 变量在内存中存储的编码方式就是浏览器默认的了，跟以上的规则都没有关系了。 包括在html input 中输入字符都是浏览器以默认编码存储在内存中。