前端工地进程师的编码遭遇战.pdfVIP

前端工程师的编码遭遇战 导语：由于历史原因，淘宝网的页面编码一直都是gb k ，F2E 手册中也有明确规范，刚开始的一段 时间，F2E 们并未遭遇太哫烦的乱码问题，大家相安无事，但随着淘宝的合作方越来越多，合作 方的A PI接口编码可谓五花八门，淘宝的系统和第三方的数据对接之后就暴露出各式各样的乱码问 题。有必要再把这个问题缕缕清楚。 我想，可能是在做第一个淘宝网的页面时，工程师只顾写代码，而忘了看一看编辑器的默认编码设置，再后 来就将错就错直到今天，如果稍微留神，可能就不会犯下这么一个低级错误。没错，“编码约定”在全站规范 中占有及其重要的权重，不幸的是，而这个异常重要的问题却非常容易被忽略，毕竟它不仅仅是“统一页面 编码约定”这么简单，甚至包含全站的安全策略（这是显而易见的）。而作为F2E面对各式乱码问题时，更 要了解问题的本源，搞清楚能根治问题的方法，而不是依赖于浏览器的某种适应性暂时规避掉乱码，治标不 治本。 从二进制码流到显示出字符 众所周知，字符的编码方式有两种惯例，一种是很古老的对ASCII码做某种语言子集的扩展，比如big5和 gb2312 ，分别是繁体字扩展和简体字扩展，两者互不兼容，与之类似的编码还有ISO系列 ，各个拉丁文的子 编码集合也不相互兼容，这种编码的好处是编码集合很小，坏处是不能同时使用多种语言，于是就有了另一 种编码惯例：“万国码” ，全球所有语言做成一个码表，即unicode码表，显然，这种编码的坏处是码表太庞 大，好处是同时使用多种语言。所谓的utf -7 、utf-8之类就是unicode的某种相对高效的实现，不管某个字符 用utf 编码为几个字节，他们都属于同一个unicode超集。我们常遇到的中文编码是gb2312 、gbk 、gb 18030和 utf-8 ，不严谨的讲，前三者大致相互兼容，但都和utf-8不兼容。如果一段文本以gbk （码表）进行编码的 话，阅读软件只有按照gbk （码表）解码才能阅读。但机器码显示为最终的字符点阵，阅读软件（浏览器、 文本编辑器等）还需要将解码后（通过查找码表将连续的二进制码转换为了字符）的字符码对应到相应的点 阵，显然，如果用以显示文本的字体不包含某个字符的点阵，这个字符自然也无法显示出来。 由于浏览器比较好的兼容性，一般不会出现因为字体问题而出现乱码的情况，但在工程师写代码的时候 偶有遇到，比如使用v im以gb2312编码编辑一个文件，当文件中出现“镕”字时，是无法保存这个文件 的。这是因为gb2312码表中不存在这个字，但指定gb2312编码的网页是可以显示这个字的，这是因为 浏览器通常会采用window s系统编码来解析gb系的页面，通常是gbk 。 如果使用editplus或记事本，只需存为ANSI编码就可以，这些编辑器会根据码流去识别到底是gbk还是 gb2312还是gb18030的编码，所以window 下很多文本编辑器都没有强行采用某种特定的编码，统一使用系 统编码，通常情况下中文win系统中，可以认为ANSI就是gbk 。如果使用linux系统，可以参照这里来正确处 理你的编辑器的编码。 浏览器如何发送一个带有中文的URL 那么，浏览器打开一个网页，从敲入网址到最终呈现出UI整个过程中，是如何处理编码的呢？整个过程分 两个阶段，1 ，发送URL请求，2 ，接收数据并呈现。HTTP 标准对URL编码有着如是规定（RFC1738 ）： “…Only alphanumerics [0- 9a-zA-Z], the special characters “$-_. * ’(), ” [not including the quotes - ed], and reserved characters us ed for their reserved purposes may be used unencoded within a URL.” “只有字母和数字[0- 9a-zA-Z] 、一些特殊符号“$-_. * ’(), ”[不包 括双引号] 、以及某些保留字，才可以不经码直接用于URL 。” 这里不得不提到URL编码 ，尽管根据RFC的规定，含有中文的URL是非法的URL ，但没有规定如何转码 。确 切的讲，URL是一种编码“方法” ，编码结果依赖于所采用的“码表” ，即汉字的内码表示形式。所以，相同汉 字有N多种URL编码结果，“淘宝” 的utf8编码为“%E6%B7%98%E 5%AE%9D” ，gbk编码为 “%CC%D4%B1%A