js与ASP.NET 中文乱码问题

2024-07-10 12:38:32

字体：大中小

来源：转载

供稿：网友

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" 即可，

上一篇：Asp.net中使用Sqlite数据库的方法

下一篇：asp.net url重写浅谈