一个汉字一般情况下占用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