nvarchar及其它编码问题

前几天曾经总结了一下sql server2005中，字符型数据的字段类型选择，虽然联机丛书上对这个问题讲的很清楚，但在我脑子里还是有好多的困惑，对于到底选择varchar还是nvarchar还是心存疑虑。今天又花了一上午的时间，从网上找了一大堆相关文字，依然是云里雾里，但有一点我是明白了，那就是对于使用中文环境的用户还是应该选择nvarchar。

翻翻以前创建的数据库，几乎很少用到nvarchar，幸运的是还没有遇到什么大的问题，主要是因为程序的用户面比较窄，不存在什么国际化，也没有遇到移植的情况。但这并不表示以后不会出现问题，也不表示这样做就是正确的选择。选择varchar类型，数据以非unicode方式保存，对于中文环境来说，只要长度足够，一般不会出现问题，就是要注意中文是双字节的，如果长度是100，那只能存50个汉字。虽然如此，稳妥的做法还是将其设置其nvarchar类型，以unicode字符保存。注意，受影响的是保存时的编码方式，并不会影响到len或substring等函数，它们依然是按字符来计算，无论是中文还是字母，都是一个算一个。说了半天，那到底有啥好处呢？我觉得还是在可扩展性和可移植性等方面吧。如果你的数据要被转移到另一部非中文系统的数据上，如果你的数据需要与异类数据库（比如oracle）交互，为了避免出现异常情况，unicode应该还是明智的选择。当然，前面已经说过，还是有些迷糊，所以，请指正。

这个问题先放到这里吧，以后再慢慢理解，再来说说另一个还是和编码有关的问题。在一个将页面导出为word文档的程序中，有这样一段代码：

Response.ContentEncoding = System.Text.Encoding.GetEncoding("GB2312");

当然，这段代码的作用很明显，就是用来设置输出流的http字符集。我做了一个测试，尝试变换各种字符集以改为导出word文档的编码方式。我的office环境是2003，语言环境当然是简体中文。对于GB2312、GBK、GB18030这些字符集，生成的word文档都很正常，用big5，也能正常打开，但有些乱，靠猜还能看懂，用uft-8，也行，但用utf-16就不行了，打开生成的文档时会弹出一个提示窗口让你手工选择编码。做这个测试只是想说明，unicode也不是都可靠，所以，在这里我还是选择了GB2312，当然，GB18030更没有问题。