1JSON.stringify會自動把所要轉換內容中的漢字轉換為Unicode編碼
2瀏覽器間有差別，個別瀏覽器會把將要提交表單內容中的Unicode編碼自動轉為漢字（Chrome自動轉換，IE不轉）
3Web服務器，可能也有區(qū)別對待，其他的不清楚，IIS5不轉換，IIS7自動轉換（題外話，IIS5不支持SSI指令,IIS7支持）。

瀏覽器—1—提交表單——Web服務器—2—asp解析器

Chrome在1處，在表單提交到服務器前轉碼。
IIS7在2處在把表單數(shù)據(jù)交給asp解析器前轉碼。

用JSON.stringify轉換再提交的內容中如果有漢字則需要特別處理。
1不用管他，交給web服務器處理。
2改JSON.stringify,看那JS代碼我就放棄了。
3加后臺代碼轉換，在網上找了個。
http://www.cnblogs.com/guardianf/archive/2012/08/21/2649147.html這里有Unicode編碼轉漢字的功能代碼

public static string unicodetogb(string text) 
{ 
    System.Text.RegularExpressions.MatchCollection mc = System.Text.RegularExpressions.Regex.Matches(text, "\\\\u([\\w]{4})"); 
    string a = text.Replace("\\u", ""); 
    char[] arr = new char[mc.Count]; 
    for (int i = 0; i < arr.Length; i++) 
    { 
        arr[i] = (char)Convert.ToInt32(a.Substring(i * 4, 4), 16); 
    } 
    string c = new string(arr); 
    return c; 
} 

說下個人的調試經歷。
項目內容是在線考試

JSON.stringify 功能為從一個對象解析為字符串
JSON.stringify(jsondata.table) 會把表中的"單選"轉為"\u5355\u9009" 作為JSON字符串提交。

在IE調試VS調試時回傳的數(shù)據(jù)為
"id":"10337","answer":"","rightanswer":"C","type":"\u5355\u9009"

服務端再把JSON轉為DataTable
DataTable dt = JsonToDataTable(table);
而這個方法轉回的結果，沒有對Unicode編碼作處理。

第一次的代碼。
string qt = dt.Rows[i]["\"type\""].ToString();
if (qt == "單選")
需要驗證是題型，算分值，但因為表中數(shù)據(jù)是"\u5355\u9009"編碼，匹配不上。

因為用的地方不多，我想了想還是直接這么改。
if (qt == @"\u5355\u9009");

算是調試過了。可以得到分值，但之后又碰上問題。

本地調試，正確，發(fā)布到本地的IIS上也正確，但發(fā)布到服務器上，就出錯了（確切的說不是出錯，是統(tǒng)計結果為0，要按題型算分值，題型匹配不上，題刑分值為0,總分也就為0）

我折騰了1個多小時沒找到問題所在，本地的IIS調試，正確。服務器有點問題，而且來公司沒多久，你們懂的。

突然就想IE是這樣，其他瀏覽器呢？

想看看Chorm在各版本下的結果，VS，本地IIS，服務器IIS。

Chrome本地居然也是結果0,不過雖然結果是錯了，卻隱約感覺到錯誤所在。
不走IE調試，用Chrome調試，查斷點，Chrome回發(fā)的數(shù)據(jù)就是"單選"，不是IE的"\u5355\u9009"。
Chrome提交數(shù)據(jù)時自動把Unicode編碼轉為了漢字了。
if (qt == @"\u5355\u9009")的結果顯而易見。
所以改為這樣，結果就正常了。
if (qt == @"\u5355\u9009" || qt == "單選")

再發(fā)布到服務器，也正常。一定是服務器的IIS服務也自動把表單里的Unicode編碼轉為漢字。

總結

以上是生活随笔為你收集整理的关于JSON.stringify和Unicode编码，需要注意的几点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。