对于一个“纯JS实现GB2312转码”的看法

原创 2006年02月24日 12:07:00

完整贴在 http://community.csdn.net/Expert/TopicView3.asp?id=4563329

此处把我的论点集中一下:

编码问题不应该这样解决。楼主的出发点是好的,但是解决问题的思路有问题,这个东西充其量就是一个在某些特定条件下的patch。

我说的“思路问题”,是指楼主有没有想过,encoding实际上是一种底层的(相对你开发的application本身来说)设施。

你用到encoding仅仅是在通讯中,如流的io。对于b/s来说,基本上就是browser和server的通讯,极少数应用可能涉及本地文件系统的读写(但是这样的话通常会使用ActiveX或者XPCOM,就更不必用js来做转码了)。本质上,好的设计必然需要把这一部分细节包装起来。

事实上,encoding的处理,在正常环境下,这应该是由浏览器和服务器完成的任务。而且这些都有技术规范或约定。例如服务器发送content-type头中指定encoding。

正确的思路应该是学会怎样正确的利用浏览器和服务器的设施,而不是自己去造轮子。你的轮子运行在系统体系的错误的层次,而且转动也不流畅(性能问题)。只有在极少数的情况下(如某些浏览器的bug,或者你没有办法去修改服务器的错误设置),你的代码可以作为一种临时性的patch。

关于encoding问题,已经确立的最佳实践就是,尽可能全部使用utf-8编码(如html,xml,js,css...)。基本上现代浏览器都能识别带有BOM的utf-8。

这个东西如果作为framework的一部分来说,还是有一点意思的。framework和一般的app开发有些不同,提供这样的功能也不错。不过我是建议在文档中写清楚,对于大多数情况,不应推荐使用该功能。不能因为framework有一种patch的能力,就惯坏了所有用framework的程序员,让他们失去了学习“正确方式”的机会。

例如,“因为很多web服务器在处理请求,反编码的时候都是采用gb2312的方式。”
这个例子里面,关键在于这些web服务器端的程序(asp,jsp,etc.)最好不要用gb2312的方式解码,我在csdn和很多地方的讨论java中文问题的地方都反复表达了这个观点。特别是GET方式的(参数编码在url里面的),应该始终以utf-8来解码,这是大量规范(http相关的rfc, w3c html规范等等)已经规定了的。以XmlHttpRequest来说,由于它只能请求本domain的网页,可以认为做js开发的人,应该有能力影响 server端的人,所以基本上不存在server无法控制的问题。如果是虚拟主机用户发现虚拟空间的设置有问题(例如始终以错误的编码发送 content-type),可以要求webmaster做设置,如果它的服务商不愿意或者不会的话,那就是服务水准或者态度的问题,如果是我的话,我就会换一家。

开发难道不是根据具体的环境和情况来讨论的吗?对于可以得到更高权限的Intranet或本地应用,IE下可以用ActiveX,Moz可以用 XPCOM,都可以调用性能更高的编码模块。对于一般WebApp,应该始终遵循各种规范,例如提交URL参数应该始终使用UTF-8,这才是正途。我们有太多程序员老是用各种hack,而不是仔细看看到底这个工作应该在整个体系的哪一部分完成。

单纯作一个js下的gb2312codec,它是完成了一定的功能,我认为作为framework的一个备用工具还是不错的,但是采用其来作为通用的跨浏览器解决方案显然是不妥的,就好像在城市的公路上骑马出行,没错,可以到达目的地,但是能作为城市的通用交通工具吗?

同样是字符处理,做一个完整的汉字和拼音索引,对于高交互的webapp开发来说,如果能增加这方面的库,其意义比gb2312codec要大得多!

网页当然可以gb2312 编码。但是参数提交应该使用utf-8,两者并不矛盾。

我们不能完全归咎于客观原因,我们有没有自己争取过用正确的方式处理问题呢?其实并不一定需要转码。

虽然XMLHttpRequest在读取text文件时,并不会自动调整编码,但是如果你读取的是一个带有encoding声明的xml文件,无论IE或者 Moz都会正确的处理编码。所以根本没有必要大动干戈的使用所谓纯JS的转码。到现在为止,我还没有看到一个实际的web应用例子能说用纯JS转码是合理的方案。

最后补充一点,解决encoding问题的最好方法是服务器发送正确的Content-Type。这是多份规范所规定的,即服务器发送的Content- Type对决定User-Agent应采取的character encoding具有最高的优先级。而IE、Moz、Opera都是基本遵循这个规范的(无论是网页还是XMLHttpRequest)。

如果情况确实需要处理多种编码,那么最佳实践是:只要开发者有机会影响到server配置,就不要放弃使用这一最简单直接高效的方式来解决问题!例如,即使你是virtual host用户,而你的服务商既蠢又态度蛮横,使得你无法去改正错误的全局配置,但是你还可能有机会使用.htaccess的方式在局部作修正(事实上由于你的服务商很蠢,所以他做出错误配置的机率反而小,并且其服务器保持默认设置即允许使用.htaccess的机会是很大地)。

对于最常用的Apache 2而言,AddCharset指令甚至可以做的更好。使用该指令可以为特定后缀名的文件自动选择字符集编码。而且,令人高兴的是,在绝大多数安装版本的默认配置下,abc.gb.html就会发送gb2312作为编码,一切就都ok了。你所要做的只是规范一下文件命名。注意:Apache的默认配置使用 Content-Negotiation,你甚至只要访问abc就会自动为中文用户选择abc.gb.html的内容发送过去。
对于各种Java web container(servlet/jsp),只要你的container不是太老掉牙,你都可使用filter来处理encoding,Java具有一切你处理encoding所要的能力,唯一问题是你会不会使用。

对UTF-8和GB2312格式 URL进行解码

对UTF-8和GB2312格式 URL进行解码 新的系统编码格式是:UTF-8   老的页面编码格式是: GB2312  新的系统的URL参数(带中文) 提交到老的系统中,中文参数是乱码。 ...

js处理小数 , toFixed()的潜在问题

一、toFixed能做什么? 以下是摘自网络的toFixed的介绍: toFixed 方法: 返回一个字符串,代表一个以定点表示法表示的数字。 numObj.toFixed([fractionD...

解决gb2312与utf-8转码问题

http://blog.csdn.net/shanleichicheng/article/details/7927971 ARM开发板上iconv_open("utf-8", "gb23...

sublime text3 gb2312编码文件显示乱码,ConvertToUTF8转码失效

sublime text3 gb2312编码文件显示乱码,ConvertToUTF8转码失效 分类: 前端相关 | 发表于 2015-01-20 | 浏览(10753)  字体:大 中 ...

Qt QString 中文 char* UTF-8 QByteArray QTextCodec unicode gb2312 GBK 乱码与转码问题

代码如下:如果不不设全局的字符集是utf-8,那么网上一般的方法是可以转的。如下程序中 #define DD 1的情况下;但是如果设置了全局的utf-8,再用以前的方法: QByteArra...

utf8,gb2312转码工具

  • 2017年05月17日 12:06
  • 46KB
  • 下载

node.js 教你写爬虫(附上gbk,gb2312中文乱码的解决方法)

好久没有更新博客了,现在前端web越来越火了,各种前端技术也层出不穷,不过有一些趋势是可以肯定的,前端现在越来越模块化,mvvm框架让前端用户只需要关注数据的变化,也让web端从webpage转为功能...

utf-8 互转 gb2312 转码

  • 2015年02月02日 16:36
  • 1.14MB
  • 下载
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:对于一个“纯JS实现GB2312转码”的看法
举报原因:
原因补充:

(最多只允许输入30个字)