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

  最近在做自己的個人博客,由於自己的系統裝的繁體版,在後臺發布新聞、隨筆的時候,富編輯框用的是開源的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了!

 

         

  

原文地址:https://www.cnblogs.com/jxcia_Lai/p/1881869.html