在用java对数据库的操作时免不了要用到jdbc，而我们最常用到的驱动自然是数据库厂商提供的纯java的jdbc连接器，不仅是因为使用方便，运行速度更快，而且它与本地系统没有什么关系。但是除了一些常用数据库厂商会提供jdbc驱动，一些excel,txt,access却不会有这些jdbc驱动，因此想要提供更多对数据的支持，用odbc就是一个不错的办法。在很早的时候就是通过jdbc-odbc桥来实现数据库的连接与操作的。 以前连接SQLServer数据库都是用的MS提供的JDBC驱动，因此有些问题根本就没有遇到。但是要做一个严谨的系统，不能因为以前没有遇到而忽视现在发现的问题。就是在使用JDBC-ODBC桥连接SQLServer数据库的时候，ntext字段读取出来的中文成了乱码。不仅仅有这个区别，用JDBC-ODBC桥时，使用getObject()方法无法读取uniqueidentifier,text,nchar等很多字段，读取出来的为null，但是用特定的getString()方法却是正常的。出现这么多问题，都是以前用纯JDBC驱动所没有发现的。前面的问题容易解决，大不了判断一下字段的类型，然后选择相应的方法来读取数据。但是读取ntext字段的时候出现的问题，却很头痛。用纯jdbc是不会有这个问题的，就是因为用了jdbc-odbc。ntext数据类型在SQLServer里面比较特别，它是一个可以存储2G的文本UNICODE字符，由于经过UNICODE编码，于是读取出来的时候也是需要进行相应的转换。
开始的时候用普通的方法rs.getString(i)是没有用的，后来用rs.getBytes(i)，然后再用gb2312,gbk,utf-8,iso-8859-1进行转换依然是乱码。在感觉没有办法的时候，使用utf-16,utf-16be,utf-16le继续试验，终于在使用utf-16le的时候出现了正常的文本信息。看来SQLServer在将文本信息存放到ntext字段中使用的utf-16le的方法，问题解决，很奇怪，也很无奈，也没有听谁说过SQLServer的ntext字段使用utf-16le的编码呀！问题解决了感觉还是很好的，以后肯定还会出现更加古怪的问题……
附代码：
String str;
byte []bys;
while(rs.next()){
bys = rs.getBytes(1);
}
str = new String(bys,"utf-16le");