項目之繁簡體亂碼解決方法

　　最近在做自己的個人博客，由於自己的系統裝的繁體版，在後臺發布新聞、隨筆的時候，富編輯框用的是開源的FCK，一開始發布繁體的時候可以正常顯示，但是發布簡體中文的時候就出現亂碼了，一開始很鬱悶，以為是OS的緣故，仔細檢查了下數據庫的編碼，將編碼改為英文，可還是這樣，我開始懷疑FCK的編碼了，因為標題用簡體中文都可以正常顯示，又檢查了好久，一直在找FCK的編碼設置，就是沒有找到，杯具了，我已經將所有網頁的編碼格式改為UTF-8了，真的是怪事！

　　難道是數據庫的問題？我靈光一閃，對啊，爲什麽標題可以用簡體而內容不能用簡體呢？我最後做了下測試，直接將提交的內容替換為簡體字，然後在數據庫中查看，果然，發現了一個天大的秘密...

　　原來的數據庫中字段類型惹的禍，在標題字段上用的是：nvarchar(128),而在內容字段上用的是：text類型，問題就出在這裡，我先是將text類型改為nvarchar(4000),再試，OK了，難道是text類型惹的禍？？

　　到網上搜索了一下nvarchar,text的區別，搜索的結果同時還有幾個類型，分別是：varchar,char,ntext;

　　通過了解它們的區別，區別如下：

　　1、CHAR。CHAR存储定长数据很方便，CHAR字段上的索引效率级高，比如定义char(10)，那么不论你存储的数据是否达到了10个字节，都要占去10个字节的空间,不足的自动用空格填充。

　　2、VARCHAR。存储变长数据，但存储效率没有CHAR高。如果一个字段可能的值是不固定长度的，我们只知道它不可能超过10个字符，把它定义为 VARCHAR(10)是最合算的。VARCHAR类型的实际长度是它的值的实际长度+1。为什么“+1”呢？这一个字节用于保存实际使用了多大的长度。从空间上考虑，用varchar合适；从效率上考虑，用char合适，关键是根据实际情况找到权衡点。

　　3、TEXT。text存储可变长度的非Unicode数据，最大长度为2^31-1(2,147,483,647)个字符。

　　4、NCHAR、NVARCHAR、NTEXT。这三种从名字上看比前面三种多了个“N”。它表示存储的是Unicode数据类型的字符。我们知道字符中，英文字符只需要一个字节存储就足够了，但汉字众多，需要两个字节存储，英文与汉字同时存在时容易造成混乱，Unicode字符集就是为了解决字符集这种不兼容的问题而产生的，它所有的字符都用两个字节表示，即英文字符也是用两个字节表示。nchar、nvarchar的长度是在1到4000之间。和char、varchar比较起来，nchar、nvarchar则最多存储4000个字符，不论是英文还是汉字；而char、varchar最多能存储8000个英文，4000个汉字。可以看出使用nchar、nvarchar数据类型时不用担心输入的字符是英文还是汉字，较为方便，但在存储英文时数量上有些损失。

 

　　通過一上的分析，將文章內容的類型改為：ntext類型就將這個問題解決了，哈哈，真爽啊！

 

　　通過總結：在編碼上有以下幾點：

　　1：總站的編碼設置可以在web.config中設置，加入： <globalization requestEncoding="utf-8" responseEncoding="utf-8" />

　　2：對特殊的頁面，可以在頁面的：

<%@ Page Language="C#"  AutoEventWireup="true"   > 加入：CodePage="65001" ，具體編碼如下：

<%@ codepage=936%>简体中文 <%@ codepage=950%>繁体中文 <%@ codepage=65001%>UTF-8

一般這三個編碼就夠了！

　　3：js的編碼，檔我們用post方式提交數據時：可以用escape( content)進行編碼，在.net後臺獲取js傳過來的數據后，用HttpContext.Current.Server.UrlDecode還是對其進行界面就OK了！