js与ASP.NET 中文乱码问题


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.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,他们是伟大的,他们替人们找到了加班到累死的理由。
« 
» 
快速导航

Copyright © 2016 phpStudy | 豫ICP备2021030365号-3