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

完整贴在 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所要的能力，唯一问题是你会不会使用。