在用AJAX进行异步请求(asp)的时候，出现了乱码问题

AJAX是客户端与服务端进行的数据层交互。也就是说客户端请求的只是服务端的数据，而显示与定位等都并由客户端进行的显示。大量的定位或显示代码出现在客户端时称之为“肥客户端”设计，而如果同时返回定位，显示格式化时，代码还是压在了服务端，这种情况称为“瘦客户端”设计。但两者的区别是数据的交换量变大了。

既然是数据层的交互，那么实际上编码并不是一个客户端所了解的事。所以应该在后台支持文件中将其编码设定好的。也就是后台如果是gb2312或是gb65001情况，前台接收时才会改动相应的编码而不会出现乱码的现象。

好在GB2312是一种汉语的页面编码标准，是双字节标准。如果后台是使用了这样的编码时，前台接收时本来应该同样使用GB2312相对应的，但双字节的处理方式恰好能使用UFT-8,ISO-8859,Unicoded等形式是可以接收到不乱码的中文字符的。但不是一种自适应，而中文进行组码时如果前一个字节在于80H时自动将两个字节做为一个汉字，汉字编码首位是1，所以我们常说汉字编码是负数。所以几种情况都这样解释，才会出现中文不乱码。但由于编码不仅仅是汉字一项，同时编码规则中含类似日期格式，小数点格式，币种表示方式等等各方面的内容。而这些并不见得是相同的。当然对于多语言包的机器，如果使用了其他国家的语言，而客户机区域文化不同时会显示成其他的语言版本。也就是说，不管你使用了什么编码方式，选择语言才是客户机自适应的。比如，你后台用的是GB2312，通知前台使用了GB2312，而在前台页面中使用UFT-8或是unicoded时，中国的机器访问是出现的中文，但日期格式可能不符合中国的习惯，货币等也是。此时若是国外比如日本，朝鲜等，他们访问会出现他们的语言习惯。但如果前台是gb2312至少是不管你是什么国家，都是出现的中文编码。

所以，你的第一个问题，AJAX是数据的一种格式，对于数据的编码应该是有目的的，AJAX只是一个网络上传送的数据，它本身没有所谓的编码的。所以也不会出现AJAX自适应这样的方式。

第二个问题，同理，客户机在进行浏览时，根据它们具体的文化的不同，对任何网页都是调用相应的文化页面。除非你事先规定了编码。所以对于多语言的网页，是根据不同的文化而转向了不同的链接。如果没有设置编码时，或