,,

看了許多網上使用MSSQL Server 2000/2005使用UTF-8造成數據庫存儲亂碼的描述，也說一下自己做的一個國際化項目的經驗。
這個項目描述：
架構：VC++的ATL Server進行開發；
頁面：web頁面是UTF-8編碼，CodePage=65001；
應用服務器程序：編譯好的dll是Unicode編碼;
操作系統:中文Windows 2003 Server;
數據庫聯接方式：OLEDB
數據庫：中文MSSQL Sever2005，顯示Codepage=936,
字段都是支持Unicode的nchar,nvarcha,nText;
SELECT COLLATIONPROPERTY(\'Chinese_PRC_Stroke_CI_AI\', \'CodePage\')
936
________________________________________________

發現從Web頁面提交的數據到數據后查詢總是亂碼，經過檢查，發現保存的數據直接就是是UTF-8編碼，其CodePage=65001，而數據默認顯示支持的Unicode語言版本Codepage=936（即是簡體中文），所以數據查詢的就是亂碼，想過兩種方案：
1，懷疑是數據時UTF-8編碼，而SQLServer是UCS-2 版本，相通過UTF-8-〉UCS-2轉換，發現還是行不通，仍然亂碼，此路不通；
2，
搜索了網絡發現并沒有現成的例子，經過測試中文系統使用Web頁面為GB2312編碼提交的數據到數據很正常，基于Windows2003是支持
Unicode（UCS-2），排除操作系統的問題，這個過程經過分析可以這么理解：936（Web頁面編碼GB2312）-〉Unicode（應用服務
器端）-〉Unicode（數據庫OLEDB傳輸）-〉UCS-2（數據庫）-〉自動轉化為936（Unicode簡體中文語言版本），而使用UTF-8
的Web頁面這個過程就是：65001（Web頁面編碼UTF-8）-〉Unicode（應用服務器端）-〉Unicode（數據庫OLEDB傳輸）-〉
UCS-2（數據庫）-〉自動轉化為936（Unicode簡體中文語言版本），所以最后的使用數據分析查詢器看到的就是亂碼，最后確定的方案就是兩種手
段：一是更改數據查詢分析器的Codepage為65001，很顯然當前的SQLServer沒有這個功能（沒找到？知道的告訴我）；二是將前端的UTF
-8轉為GB2312編碼，很顯然這個最后成功了，這個過程程序還是保留了所有的多語言的特性，一位UTF-8-〉GB2312，這個過程是無損的（新的
驗證會出現部分方塊無法顯示），因為是UTF-8->Unicode->GB2312.
總結：
1，MSSQL
Server不支持UTF-8（Codepage=65001）直接顯示，數據庫查詢的顯示數據使用默認的Codepage，如簡體中文版就是936，繁
體中文是950，韓文949等，因此從使用的Web頁面UTF-8提交的數據自動轉換為所用的Codepage顯示，因此就是亂碼，這個有待MS
SQL
Server進一步發展，因為現在Oracle和MySQL是可以支持直接UTF-8存儲顯示，國際化時請先將數據由UTF-8編碼轉化為MSSQL數據
庫默認的編碼，讀寫出來這個過程著相反進行轉化，這個過程看起來會因為轉化過程影響處理速度（抉擇于國際化）；
2，ASP/ASPX/JSP/PHP使用MSSQL Server編程支持UTF-8都會面臨這樣的問題，可以看看MSDN有關這個方面的解釋
補充：根據測試和MSDN分析，將UTF-8轉化為GB2312并不是很好的方案，這樣會使包含韓文、阿拉伯文等等，這些都會變成問號，所以整個過程并不是很繁瑣，簡化一下：