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重寫淺談