本来一直用json2.js来做客户端的JSON的parse和stringify,
现在ie8因为原生支持json，所以浏览器自带了JSON.parse与JSON.stringify两个方法，
现在问题是当需要stringify的对象中包含中文时，ie8的方法会将中文转为unicode编码格式，比如下面：
var json = '{"PermID":"30","PermName":"普通员工级","Re":"最基层员工使用的权限。"}';
var o = JSON.parse(json);
document.write(JSON.stringify(o));
会输出如下结果：
{"PermID":"30","PermName":"\u666e\u901a\u5458\u5de5\u7ea7","Re":"\u6700\u57fa\u5c42\u5458\u5de5\u4f7f\u7528\u7684\u6743\u9650\u3002"}这样的结果如果用XHR直接POST到服务器上中文会是乱码，现在我只好不用IE8的原生对象。
不知道哪位大侠有什么更好的办法既能用IE8原生的对象，又能避免乱码。
现在ie8因为原生支持json，所以浏览器自带了JSON.parse与JSON.stringify两个方法，
现在问题是当需要stringify的对象中包含中文时，ie8的方法会将中文转为unicode编码格式，比如下面：
var json = '{"PermID":"30","PermName":"普通员工级","Re":"最基层员工使用的权限。"}';
var o = JSON.parse(json);
document.write(JSON.stringify(o));
会输出如下结果：
{"PermID":"30","PermName":"\u666e\u901a\u5458\u5de5\u7ea7","Re":"\u6700\u57fa\u5c42\u5458\u5de5\u4f7f\u7528\u7684\u6743\u9650\u3002"}这样的结果如果用XHR直接POST到服务器上中文会是乱码，现在我只好不用IE8的原生对象。
不知道哪位大侠有什么更好的办法既能用IE8原生的对象，又能避免乱码。
script5.8版本内置了JSON对象，这样JSON的解析更快更安全，
json2.js本来就只对不支持内置对象的浏览器起作用。
<script>
var str = '{"PermID":"30","PermName":"\\u666e\\u901a\\u5458\\u5de5\\u7ea7","Re":"\\u6700\\u57fa\\u5c42\\u5458\\u5de5\\u4f7f\\u7528\\u7684\\u6743\\u9650\\u3002"}';
alert(str);
eval("var str1 = '"+str+"';");
alert(str1);
</script>var json = '{"PermID":"30","PermName":"普通员工级","Re":"最基层员工使用的权限。"}';
var o = JSON.parse(json);
eval("var str = '"+JSON.stringify(o)+"';");
document.write(str);
关键是POST到服务端会影响服务器端的使用，例如写库。
那只好自己写个转换函数了。
我简单的写了个ASP转换函数：
<%
s="\u666e\u901a\u5458\u5de5\u7ea7"
Response.Write ConvChinese(s)'转换为汉字函数
function ConvChinese(s)
dim temp,arr
arr=split(s,"\u")
for i=1 to ubound(arr)
if temp="" then temp=chrW(int("&H" & arr(i))) else temp=temp&chrW(int("&H" & arr(i)))
next
ConvChinese=temp
end function%>
如果再用eval来转一下，则有点多余，还不如我现在的办法——强制用json2.js的stringify方法。
服务器端我用的是.net2.0，如果直接用XHR提交过去，不能正确识别中文，但是这种情况仅发生在IE8下，
FF3.5、chrome2.0、safari、opera都没有问题。
我觉得总不能因为客户端浏览器的不同来影响服务器端的代码，所以现在只好采用折中的办法，不使用IE8的内置对象。另外，IE8可能不成熟，这是我发的另一个帖子，不知道是不是IE8的BUG
http://topic.csdn.net/u/20090731/16/3d7eb160-f043-4f9f-a16c-d07a3641e6ed.html
主要是我的数据在提交到服务器之前为保证安全肯定要encodeURIComponent一下。
这一来就把\u给URI编码了，而这个\u的特殊情况又只在IE8下出现，说不定哪天IE8一升级又变了。
所以不能让它来影响服务器端程序。另外，另一个帖子中的问题也确认了不是IE8的BUG，而是IE8下DOM元素固有了role属性，所以导致对象作用域的改变而引发错误。