字符集与数据库类型长度 对存入的汉字的个数的影响
一个汉字一般情况下占用2个字节,也就是16bit 。这种情况是建立在字符集是GBK 或者GB2312的情况下。
但是,一般通用的字符集是UTF—8,所以就会出现一个汉字占3个字节的问题。
所以在程序中根据表字段varchar的大小,保存或更新时作出必要的校验否则后台会报错。
办法:1、用表格 maxlength属性,比如maxlength="5",即只能存5个汉字。
UTF-8:Unicode Transformation Format-8bit,允许含BOM,但通常不含BOM。是用以解决国际上字符的一种多字节编码,它对英文使用8位(即一个字节),中文使用24为(三 个字节)来编码。UTF-8包含全世界所有国家需要用到的字符,是国际编码,通用性强。UTF-8编码的文字可以在各国支持UTF8字符集的浏览器上显 示。如,如果是UTF8编码,则在外国人的英文IE上也能显示中文,他们无需下载IE的中文语言支持包。
GBK是 国家标准GB2312基础上扩容后兼容GB2312的标准。GBK的文字编码是用双字节来表示的,即不论中、英文字符均使用双字节来表示,为了区分中文, 将其最高位都设定成1。GBK包含全部中文字符,是国家编码,通用性比UTF8差,不过UTF8占用的数据库比GBD大。
GBK、GB2312等与UTF8之间都必须通过Unicode编码才能相互转换:
GBK、GB2312--Unicode--UTF8
可以使用
- select u.name, length(u.name), lengthb(u.name) from var u; 查看 name 字段的字节长度 及字符长度
这样,就会出现因为字符集问题出现乱码显示问题。
char类型: 对英文(ASCII)字符占用1个字节,对一个汉字占用2个字节,CHAR存储定长数据很方便,CHAR字段上的索引效率级高,比如定义 char(10),那么不论你存储的数据是否达到了10个字节,都要占去10个字节的空间。因为是固定长度,所以速度效率高。
Varchar类型:Varchar 的类型不以空格填满,比如varchar(100),但它的值只是"qian",则它的值就是"qian"
而char
不一样,比如char(100),它的值是"qian",而实际上它在数据库中是"qian
"(qian后共有96个空格,就是把它填满为100个字节)。
由于char是以固定长度的,所以它的速度会比varchar快得多!但程序处理起来要麻烦一点,要用trim之类的函数把两边的空格去掉!
VARCHAR存储变长数据,但存储效率没有CHAR高。如果一个字段可能的值是不固定长度的,我们只知道它不可能超过10个字符,把它定义为 VARCHAR(10)是最合算的。VARCHAR类型的实际长度是它的值的实际长度+1。为什么“+1”呢?这一个字节用于保存实际使用了多大的长度。
Nchar类型和Nvarchar类型是怎么一回事呢?为了与其他多种字符的转换,如中文,音标等,对每个英文(ASCII)字符都占用2个字节,对一个汉字也占用两个字节,所有的字符都占用2个字节。
例如
varchar(n):变长型字符数据类型,存储最长长度为8,000 个字符。
换句话说varchar(100)能存50个汉字,nvarchar(100)能存100个汉字。
有一点不太明白的是,实际上很多时候varchar存汉字也是没有问题的,不会有乱码。所以varchar存汉字出现乱码还应该有别的原因吧?
你说的不错,varchar确实可以存中文,这只是解决乱码问题的一种方法。至于原因,应该是和我装的Sql Server有关,因为在其他的人的SqlServer上并不会出错。原因大概有两种:
1:
安装时选了 Hide advice configuration options
然后再 Collation designator and order 中不是选择 Chinese_PRC
2:
在建表时没有指明某个字段的语言
方法 COLLATE Chinese_PRC_CS_AS_WS