标题：能否考虑增加一个读取字符串长度的函数
比如，下面这个字符串：
星期一，星期二，星期三，星期四，星期五，星期六，星期日
用Length得到的长度是27，而我在数据库结构中给它定义的“字段长度”是50，但在将这个字符串添加到数据库时还是会出错。这是因为，数据库中的字段长度是按一个汉字2个字节的标准进行判断的。
对于中英文混合的字符串，要判断其长度更麻烦，比如：一二三ABC。。。
由于得不到准确的字符串长度，这就很容易在将其写入数据库时导致各种错误。请老六看看能否增加一个相应的函数（将汉字按2个字节来处理）。
我也查了一下资料，用ASC可以判断某字符是否是汉字，但它需要对每个字符进行循环判断。如果导入的外部数据有成千上万条，这是不是太占资源了？
此主题相关图片如下：2.jpg
经认真检查，原来问题就出在对字符串长度的判断上。假如，某列的MaxLength是50（也就是字段的长度），用户在table或编辑行上输入50个汉字也是允许的。但只要对DataTable进行Save保存，肯定出错。（50个汉字实际上已经是100个字节了）
这个问题比较严重，请老六考虑一个妥善的解决办法。
Dim str As String = "星期一,星期二,星期三,星期四,星期五,星期六,星期日"
Dim Array() As Byte
array= System.Text.Encoding.Default.GetBytes(str)
Output.Show(Array.Length())
学习，收藏！谢谢！
那二楼的问题怎么处理呢？是不是只能在保存前对输入的字符串长度进行判断呢？
设成varchar(50) 或者 char(50)才会报错
如果要输入到汉字，设成nvarchar(50) 或者nchar(50)就不会报错
设成varchar(50) 或者 char(50)才会报错
是的，varchar是按字节存储的，而带“n”的nvarchar是按字符存储的。同样的字段长度，varchar(50)只能存储50个字节长度的字符，也就是25个汉字；而nvarchar(50)则可以存储50个汉字（也就是100个字节）。
由于Varchar更节省空间，我一般都是用Varchar来定义字段宽度。由于之前用的其它开发工具都是将一个汉字统计为2个字节的，所以都很正常；现在改用到foxtable后，同样的判断方法已经无效，总是导致“字符串截断”的错误。
nvarchar只有储存字母 数字等的时候才会浪费空间。 因为他们本来只需要一个字节的空间，却占用2个字节的空间。
存储汉字，无论你用nchar还是char都是占用2个字节的物理空间。varchar(50) nvarchar(50) 占用的物理空间就不一样
其实你完全可以用nvarchar来储存。nvarchar本来就是设计来储存双字节数据的，否则这个类型还有啥用。
正常情况下，我们使用varchar也可以存储中文字符，但是如果遇到操作系统是英文操作系统并且对中文字体的支持不全面时, 在SQL Server存储中文字符为varchar就会出现乱码(显示为??)．而且正常情况下，主机都会支持中文的环境，所以如果使用varchar来存储数据，在开发阶段是发现不了的．多数情况下，在布署的时候也不会有问题．
但是！如果布署的主机是英文操作系统，并且不支持中文环境，那问题就出来了．所有的varchar字段在存储中文的时候都会变成乱码（显示为??）．而且一般情况下你不会知道这是因为你采用了错误的数据类型来存储所造成的，你会试着去装中文字体，试着去设置操作系统的语言环境．．．这些都不能解决问题，唯一能解决问题的是把数据库字段的类型个性为nvarchar（或者nchar）．对项目管理比较熟悉的朋友应该都知道，到布署阶段再来修改数据库是一个很恐怖的事情．
使用nvarchar的另一个非常好处就是在判断字符串的时候可以不需要考虑中英文两种字符的差别．
当然，使用nvarchar存储英文字符会增大一倍的存储空间．但是在存储代价已经很低廉的情况下，优先考虑兼容性会给你带来更多好处的．
所以在Design的时候应该尽量使用nvarchar来存储数据．只有在你确保该字段不会保存中文的时候，才采用varchar来存储．
nvarchar只有储存字母 数字等的时候才会浪费空间。 因为他们本来只需要一个字节的空间，却占用2个字节的空间。
存储汉字，无论你用nchar还是char都是占用2个字节的物理空间。varchar(50) nvarchar(50) 占用的物理空间就不一样
其实你完全可以用nvarchar来储存。nvarchar本来就是设计来储存双字节数据的，否则这个类型还有啥用。
呵呵，因为习惯及数据库移植问题，我还是要用Varchar类型来保存字符型数据的。
看来，只有在保存前用3楼的方法进行判断了。