js与ASP.NET 中文乱码问题
作者：
本文摘自一位哥们的QQ空间里，自认为方案比较可行，也确实解决了开发中的这一类问题，非原创，写在此是为以后自己能方便的找到，也希望对其他的朋友有帮助。
1. 客户端 -> 服务端的问题
1.1. get 方式提交短数据效率比 post 方式高
原因：个人感觉
1.2. post 方式提交时，若数据中含有中文，则服务端获得的数据中文部分会变为乱码
原因： 可能是提交时 XMLHttpRequest 自动对非标准 ASCII 字符进行了编码。
可能只是简单的逸码转换，但具体编码方式不详， 在服务端就很难还原。
解决：(a) 在客户端提交前，对串中的非标准 ASCII 字符用 escape() 手动转码。
这种方法对非标码位置比较有规律(比如存放在不同的变量中)的情况比较合适。
在服务端获取后无须用 unescape() 转换即可正常处理。
(b) 对非标码多而不方便分别 escape() 的，可以用 encodeURI() 两次(是两次，不是一次)。
服务端获取后用 decodeURI() 一次即得到原正确内容。
疑惑：
以上两个解决方法经测试都正确可行。
有个疑惑就是，浏览器在提交数据的时候，看起来是对非标码进行了一次转换，
而在服务端获取时(如 Request(), getAttribute() 等)，看起来又偷偷进行了一次逆向转换。
而这两次转换似乎没有遵循同样的标准，从而对非标码的默认转换会导致取不到正确的内容。
而在客户端 escape() 后，服务端的逆转换结果就是正确的。可惜 escape() 会对串中的所有可转换
字符都进行转换，而标准 ASCII 码转换后，在服务端取出来又成了错的了(神奇....)。
所以 escape() 仅适合用来转非标码。
终极解决方案就是，在客户端进行连续的两次 encodeURI()。
这个规律是从分析服务端转码后的结果串得到的。
比如‘中'字，在 encodeURI() 一次后被转码为‘%E4%B8%AD'，而在服务端手动进行一次
decodeURI() 却得到了乱码，猜想会不会是 Request() 偷偷进行那一次转码把不该转的重要标志
‘%'也转掉了，于是在客户端多做一次 encodeURI()，此时‘中'字的转码结果就成了
‘%25E4%25B8%25AD'，25h 恰好便是‘%'，这样一来，服务端偷转一次，把‘%25'解为
‘%'，再由手动 decodeURI() 转的时候，串已经变成了‘%E4%B8%AD'，这样就得到了正确的
内容。
好像没有说清楚，不过我是明白了，希望以后忘掉的时候也能再看懂。
2. 服务端 -> 客户端的问题
2.1. 回转含有中文的数据时，客户端收到的是乱码
原因： 肯定是页面编码的问题，因为我的前提就是不强求使用统一的编码，所以这个问题要解决。
解决： 太简单，只需要在服务端向客户端回写数据前任何地方设置 Response.Chartset = "gb2312" 即可，
不需要像很多讨论到的要转码甚至有人写出大段的转码程序，当然，客户端如果是别的编码方式，
改一下就行了。
2.2. 客户端用 JSON 方式处理接收数据时，eval() 函数不能正确地把收到的数据解释为代码片段
比如用 var obj = eval( "{ p1:1, p2:2 }" ) 这样的形式，obj 是不能正确被初始化为对象实例的，而是会
收到一个缺少分号的错误，而用 eval( "var obj = { p1:1, p2:2 }" ) 这样的形式，就能正确地生成一个
obj 的有效对象实例。
其实仔细想一下，似乎也对，eval() 并不是如书上所讲，直接把串作为代码的一部分插入到整个代码
段中，而是返回转入的表达式的值，而以‘{...}'的形式定义的空函数对象，其表达式值本身是
undefined，而若其中成员多于一个，则此表达值根本不能作为合法语法独立存在，所以才会报错；
而后一种形式，其实质其实是一个赋值表达式，虽然前缀了 var 会导致整个表达式值为 undefined，
但此过程中却真实地生成了 obj 对象实例。在之后的上下文中引用 obj 就是有效的了。
经过实验看来，书上和部分前辈文章提到的第一种用法，其实是不能正确工作的，至少在我的机器
上，它确实失败了。当然，不能不考虑有可能是我的浏览器甚至是 OS 本身的原因，这个就深了。
解决：不管有多深，问题总是要解决的。也很简单，只需要按第二种形式，把接收变量的定义一起放
到 eval() 中，即可正常工作。
另外，回转 JSON 数据时，也要考虑B/S双方编码问题，如果不一致，按 2.2 中的方法即可解决。
很重要的一点是，有时候 debug 或 trace 出来的结果，特别是字符串，看起来确实是正确的，但就
是不能正常工作，那时候就需要从编码的层次去验证，而不要仅仅考虑代码本身逻辑的问题。因为有
些非打印编码，在 debug 和 trace 时都是不会被回显到屏幕上的。“眼见非实”，这一点，在任何
地方永远适用。
综合感受
Ajax 作为一种技术，其本身并无先进之处，相反过多地依赖和信仰会令其成为开发中的累赘，大量
的精力耗费在基础工作中，思路游离于业务逻辑之外，这是一件好事，可以令你的工作更快地以失败
告终。
但，Ajax 作为一种思想，反而是值得推崇的，这种思想，早已经由卖童装的美特斯邦威作出了精辟
的概括——不走寻常路。
数年来，在世界各地，
有 80% 的开发人员没有想到在 submit 之外去找路，他们是幸福的，他们走在一条熟悉的路上。
另外 10% 的人走在了 iframe 的路上，他们是幸运的，他们找到了一条风景更加美好的路。
另外 8% 的人在草丛中发现了 XMLHttpRequest，他们是值得尊敬的，他们替人们找到了新的路。
另外 2% 的人把这条新路命名为 Ajax，他们是伟大的，他们替人们找到了加班到累死的理由。
1.1. get 方式提交短数据效率比 post 方式高
原因：个人感觉
1.2. post 方式提交时，若数据中含有中文，则服务端获得的数据中文部分会变为乱码
原因： 可能是提交时 XMLHttpRequest 自动对非标准 ASCII 字符进行了编码。
可能只是简单的逸码转换，但具体编码方式不详， 在服务端就很难还原。
解决：(a) 在客户端提交前，对串中的非标准 ASCII 字符用 escape() 手动转码。
这种方法对非标码位置比较有规律(比如存放在不同的变量中)的情况比较合适。
在服务端获取后无须用 unescape() 转换即可正常处理。
(b) 对非标码多而不方便分别 escape() 的，可以用 encodeURI() 两次(是两次，不是一次)。
服务端获取后用 decodeURI() 一次即得到原正确内容。
疑惑：
以上两个解决方法经测试都正确可行。
有个疑惑就是，浏览器在提交数据的时候，看起来是对非标码进行了一次转换，
而在服务端获取时(如 Request(), getAttribute() 等)，看起来又偷偷进行了一次逆向转换。
而这两次转换似乎没有遵循同样的标准，从而对非标码的默认转换会导致取不到正确的内容。
而在客户端 escape() 后，服务端的逆转换结果就是正确的。可惜 escape() 会对串中的所有可转换
字符都进行转换，而标准 ASCII 码转换后，在服务端取出来又成了错的了(神奇....)。
所以 escape() 仅适合用来转非标码。
终极解决方案就是，在客户端进行连续的两次 encodeURI()。
这个规律是从分析服务端转码后的结果串得到的。
比如‘中'字，在 encodeURI() 一次后被转码为‘%E4%B8%AD'，而在服务端手动进行一次
decodeURI() 却得到了乱码，猜想会不会是 Request() 偷偷进行那一次转码把不该转的重要标志
‘%'也转掉了，于是在客户端多做一次 encodeURI()，此时‘中'字的转码结果就成了
‘%25E4%25B8%25AD'，25h 恰好便是‘%'，这样一来，服务端偷转一次，把‘%25'解为
‘%'，再由手动 decodeURI() 转的时候，串已经变成了‘%E4%B8%AD'，这样就得到了正确的
内容。
好像没有说清楚，不过我是明白了，希望以后忘掉的时候也能再看懂。
2. 服务端 -> 客户端的问题
2.1. 回转含有中文的数据时，客户端收到的是乱码
原因： 肯定是页面编码的问题，因为我的前提就是不强求使用统一的编码，所以这个问题要解决。
解决： 太简单，只需要在服务端向客户端回写数据前任何地方设置 Response.Chartset = "gb2312" 即可，
不需要像很多讨论到的要转码甚至有人写出大段的转码程序，当然，客户端如果是别的编码方式，
改一下就行了。
2.2. 客户端用 JSON 方式处理接收数据时，eval() 函数不能正确地把收到的数据解释为代码片段
比如用 var obj = eval( "{ p1:1, p2:2 }" ) 这样的形式，obj 是不能正确被初始化为对象实例的，而是会
收到一个缺少分号的错误，而用 eval( "var obj = { p1:1, p2:2 }" ) 这样的形式，就能正确地生成一个
obj 的有效对象实例。
其实仔细想一下，似乎也对，eval() 并不是如书上所讲，直接把串作为代码的一部分插入到整个代码
段中，而是返回转入的表达式的值，而以‘{...}'的形式定义的空函数对象，其表达式值本身是
undefined，而若其中成员多于一个，则此表达值根本不能作为合法语法独立存在，所以才会报错；
而后一种形式，其实质其实是一个赋值表达式，虽然前缀了 var 会导致整个表达式值为 undefined，
但此过程中却真实地生成了 obj 对象实例。在之后的上下文中引用 obj 就是有效的了。
经过实验看来，书上和部分前辈文章提到的第一种用法，其实是不能正确工作的，至少在我的机器
上，它确实失败了。当然，不能不考虑有可能是我的浏览器甚至是 OS 本身的原因，这个就深了。
解决：不管有多深，问题总是要解决的。也很简单，只需要按第二种形式，把接收变量的定义一起放
到 eval() 中，即可正常工作。
另外，回转 JSON 数据时，也要考虑B/S双方编码问题，如果不一致，按 2.2 中的方法即可解决。
很重要的一点是，有时候 debug 或 trace 出来的结果，特别是字符串，看起来确实是正确的，但就
是不能正常工作，那时候就需要从编码的层次去验证，而不要仅仅考虑代码本身逻辑的问题。因为有
些非打印编码，在 debug 和 trace 时都是不会被回显到屏幕上的。“眼见非实”，这一点，在任何
地方永远适用。
综合感受
Ajax 作为一种技术，其本身并无先进之处，相反过多地依赖和信仰会令其成为开发中的累赘，大量
的精力耗费在基础工作中，思路游离于业务逻辑之外，这是一件好事，可以令你的工作更快地以失败
告终。
但，Ajax 作为一种思想，反而是值得推崇的，这种思想，早已经由卖童装的美特斯邦威作出了精辟
的概括——不走寻常路。
数年来，在世界各地，
有 80% 的开发人员没有想到在 submit 之外去找路，他们是幸福的，他们走在一条熟悉的路上。
另外 10% 的人走在了 iframe 的路上，他们是幸运的，他们找到了一条风景更加美好的路。
另外 8% 的人在草丛中发现了 XMLHttpRequest，他们是值得尊敬的，他们替人们找到了新的路。
另外 2% 的人把这条新路命名为 Ajax，他们是伟大的，他们替人们找到了加班到累死的理由。