PreparedStatement中setString方法的异常

转自

PreparedStatement中setString方法的异常

其实也不应该说是异常，应该是多种因素导致的使用问题。
一般在有了一定Java编程经验之后，大家都习惯用PreparedStatement代替Statement。
其好处就不用多说了。
但是却在开发中出现了问题。
如有表：
create table test(
 id int,
 name   varchar2(3000)
)
当执行插入语句到
stmt.setString(2, myString);
的时候，出现如下异常：

java.sql.SQLException: 数据大小超出此类型的最大值

而myString变量的内容为超过700的中文字符（测试的英文字符为2000个）。
也就是说一个中文字符占据了3－4个字节，而且英文字符个数也不对，这好像有点不可思议。
分析原因：
1、驱动程序在把SQL语句发给数据库前，PreparedStatement会对字符串进行预处理并进行转义替换；
2、字符集原因。

通过阅读PreparedStatement文档，发现有一个setCharacterStream方法可以解决这个问题：
stmt.setCharacterStream(2,new InputStreamReader(myString, myString.length());
替换之后中文字符可达1400多。

上次对PreparedStatement的setString中字符串长度这个问题没有解决透彻，
也没有深入分析其中的原因。

现在通过Oracle提供的JDBC文档来详细看看问题的来由。
我们都知道Oracle提供了两种客户端访问方式OCI和thin，
在这两种方式下，字符串转换的过程如下：

 

1、JDBC OCI driver：
在JDBC文档中是这么说的：
“
If the value of NLS_LANG is set to a character set other than US7ASCII or WE8ISO8859P1, then the driver uses UTF8 as the client character set. This happens automatically and does not require any user intervention. OCI then converts the data from the database character set to UTF8. The JDBC OCI driver then passes the UTF8 data to the JDBC Class Library where the UTF8 data is converted to UTF-16. ”

 

2、JDBC thin driver:
JDBC文档是这样的：

“If the database character set is neither ASCII (US7ASCII) nor ISO Latin1 (WE8ISO8859P1), then the JDBC thin driver must impose size restrictions for SQL CHAR bind parameters that are more restrictive than normal database size limitations. This is necessary to allow for data expansion during conversion.

The JDBC thin driver checks SQL CHAR bind sizes when a setXXX() method (except for the setCharacterStream() method) is called. If the data size exceeds the size restriction, then the driver returns a SQL exception (SQLException: Data size bigger than max size for this type) from the setXXX() call. This limitation is necessary to avoid the chance of data corruption when conversion of character data occurs and increases the length of the data. This limitation is enforced in the following situations:
(1)Using the JDBC thin driver
(2)Using binds (not defines)
(3)Using SQL CHAR datatypes
(4)Connecting to a database whose character set is neither ASCII (US7ASCII) nor ISO Latin1 (WE8ISO8859P1)

When the database character set is neither US7ASCII nor WE8ISO8859P1, the JDBC thin driver converts Java UTF-16 characters to UTF-8 encoding bytes for SQL CHAR binds. The UTF-8 encoding bytes are then transferred to the database, and the database converts the UTF-8 encoding bytes to the database character set encoding.”

 

原来是JDBC在转换过程中对字符串的长度做了限制。这个限制和数据库中字段的实际长度没有关系。
所以，setCharacterStream()方法可以逃过字符转换限制，也就成为了解决此问题的方案之一。
而JDBC对转换字符长度的限制是为了转换过程中的数据扩展。
根据实际测试结果，在ZHS16GBK字符集和thin驱动下，2000－4000长度的varchar字段都只能插入1333个字节（约666个汉字）。

 

To sum，解决PreparedStatement的setString中字符串长度问题可以有两种办法：
1、使用setCharacterStream()方法；
2、使用OCI驱动连接Oracle数据库。

分享到：

p6spy如何监控复杂web系统的sql语句，内 ... | 如何知道封装类所执行的SQL语句？

• 2007-06-01 10:38
• 浏览 8892
• 评论(1)
• 查看更多

评论

1 楼 marc 2007-08-15  

我也遇到了这个问题，我用的是9i，这个问题一直没有解决，我用以下几个方法都试过了：
1、换最新的Oracle10g驱动，结果出现更加怪的问题，不管是汉字还是字符，在1000下和2000以上都是可以保存的，而1000－2000之间不能保存，估计是10g驱动和9i不兼容。
2、用OCI驱动，结果发现一个字段超过666个汉字没有关系，如果2个以上字段同时超过666个汉字时候就报错了。