导语:由于历史原因,淘宝网的页面编码一直都是gbk,F2E手册中也有明确规范,刚开始的一段时间,F2E们并未遭遇太麻烦的乱码问题,大家相安无事,但随着淘宝的合作方越来越多,合作方的API接口编码可谓五花八门,淘宝的系统和第三方的数据对接之后就暴露出各式各样的乱码问题。有必要再把这个问题缕缕清楚。
我想,可能是在做第一个淘宝网的页面时,工程师只顾写代码,而忘了看一看编辑器的默认编码设置,再后来就将错就错直到今天,如果稍微留神,可能就不会犯下这么一个低级错误。没错,“编码约定”在全站规范中占有及其重要的权重,不幸的是,而这个异常重要的问题却非常容易被忽略,毕竟它不仅仅是“统一页面编码约定”这么简单,甚至包含全站的安全策略(这是显而易见的)。而作为F2E面对各式乱码问题时,更要了解问题的本源,搞清楚能根治问题的方法,而不是依赖于浏览器的某种适应性暂时规避掉乱码,治标不治本。
从二进制码流到显示出字符
众所周知,字符的编码方式有两种惯例,一种是很古老的对ASCII码做某种语言子集的扩展,比如big5和gb2312,分别是繁体字扩展和简体字扩展,两者互不兼容,与之类似的编码还有ISO系列,各个拉丁文的子编码集合也不相互兼容,这种编码的好处是编码集合很小,坏处是不能同时使用多种语言,于是就有了另一种编码惯例:“万国码”,全球所有语言做成一个码表,即unicode码表,显然,这种编码的坏处是码表太庞大,好处是同时使用多种语言。所谓的utf-7、utf-8之类就是unicode的某种相对高效的实现,不管某个字符用utf编码为几个字节,他们都属于同一个unicode超集。我们常遇到的中文编码是gb2312、gbk、gb18030和utf-8,不严谨的讲,前三者大致相互兼容,但都和utf-8不兼容。如果一段文本以gbk(码表)进行编码的话,阅读软件只有按照gbk(码表)解码才能阅读。但机器码显示为最终的字符点阵,阅读软件(浏览器、文本编辑器等)还需要将解码后(通过查找码表将连续的二进制码转换为了字符)的字符码对应到相应的点阵,显然,如果用以显示文本的字体不包含某个字符的点阵,这个字符自然也无法显示出来。更多背景知识可以参照这个ppt。
由于浏览器比较好的兼容性,一般不会出现因为字体问题而出现乱码的情况,但在工程师写代码的时候偶有遇到,比如使用vim以gb2312编码编辑一个文件,当文件中出现“镕”字时,是无法保存这个文件的。这是因为gb2312码表中不存在这个字,但指定gb2312编码的网页是可以显示这个字的,这是因为浏览器通常会采用windows系统编码来解析gb系的页面,通常是gbk。
如果使用editplus或记事本,只需存为ANSI编码就可以,这些编辑器会根据码流去识别到底是gbk还是gb2312还是gb18030的编码,所以 window下很多文本编辑器都没有强行采用某种特定的编码,统一使用系统编码,通常情况下中文win系统中,可以认为ANSI就是gbk。如果使用linux系统,可以参照这里来正确处理你的编辑器的编码。
浏览器如何发送一个带有中文的URL
那么,浏览器打开一个网页,从敲入网址到最终呈现出UI整个过程中,是如何处理编码的呢?整个过程分两个阶段,1,发送URL请求,2,接收数据并呈现。HTTP标准对URL编码有着如是规定(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的规定,含有中文的URL是非法的URL,但没有规定如何转码,阮一峰的这篇文章详细的介绍了在Firefox和IE中是如何对带有中文的URL进行编码发送HTTP请求的。确切的讲,URL是一种编码“方法”,编码结果依赖于所采用的“码表”,即汉字的内码表示形式。所以,相同汉字有N多种URL编码结果,“淘宝”的utf8编码为“%E6%B7%98%E5%AE%9D”,gbk编码为“%CC%D4%B1%A6”。
这里需要注意的是,一个gb系编码的html页面中的form提交,表单中的中文编码会进行URL编码,但是以gbk格式作转码,utf8页面的form提交,以utf8格式作转码。看这两个例子:
gbk页面的表单提交,utf-8页面的表单提交
这时就需要和后台程序做好约定,页面怎么进行编码,后台逻辑就需要对应的解码。比如淘宝的Search页面和百度搜索页一样,只接收gbk的URL编码。网上这方面的资料也比较多,这里不再赘述。
但如果通过JavaScript的encodeURI(encodeURIComponent亦是同理)做URL编码又会出现什么情况呢?JS只会以utf-8的形式做URL编码,同样参照上面两个例子,不管页面是gbk还是utf-8,JS中的URL编码始终是一样的。这在使用JS库模拟form提交时需要尤为注意,直接提交表单结果正常,用JS库或框架提供的方法模拟拼接查询串提交表单就出问题,也就是这个原因。所以,在用JS拼接查询URL的时候要小心,需要注意后台程序需要的编码是什么格式。
浏览器如何以正确的编码渲染页面
HTTP响应的数据起码有三个地方可以埋藏编码信息:
1,http头中的Content-Type
2,html页面中的meta标签中指定charset
3,页面正文数据(浏览器可以解析正文二进制码来判断编码)
浏览器可以从这三个地方获得HTTP响应报文的编码,此外还有两个因素,浏览器默认编码和操作系统语言类型。
淘宝首页是gbk的编码,HTTP响应头中指定了文档编码为GB2312,同时meta中的charset和页面正文都是gbk编码,浏览器渲染正确。
content-type中的编码设置
源码中的meta标签
如果三者编码不一致,浏览器会首先读取http头中的content-type,若没有设定编码,再查找页面中meta标签中的charset设定,如果还没有就以浏览器默认编码来显示,如果默认编码没有指定,浏览器会通过解析正文内容来判断编码。所以,页面是gbk编码,即便meta属性中设置charset=utf-8,只要content-type中设定为gbk(或者GB2312、GB18030),该页面就正常显示,如果这时没有设定content-type的编码,浏览器就会以meta中的charset属性为准,页面出现乱码。
在PHP中可以这样设置content-type的编码:
1
|
- header('Content-Type: text/html; charset=GBK');
复制代码
|