js与ASP.NET 中文乱码问题 |
|
本文标签：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，他们是伟大的，他们替人们找到了加班到累死的理由 。 |
