使用jdbc-odbc桥读取SQLServer数据库的ntext字段出现乱码的原因与解决方法
在用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");