pstmt.setBinaryStream(1, is, (int) (file.length() - 1)); //Why?

Question

跟采用md5判断没任何联系。
md5只是校验前后是否一致。

Answer 1

我在使用此方法时没有这种问题把binary和text类型的文件都试一下，看看是不是都有此类问题

Answer 2

哦，我用的是SQLServer 2000的image类型。coolmetal(Hello :)~) 你说你用的时候不需要那个减一就是正常的？用了减一反而出错？

Answer 3

对呀！不可能需要减一的你在其他类型的数据库上一下。或者其他类型的字段。我的环境是Mysql 4.0.14 for Win32

Answer 4

经过我多次尝试不同的写入读出方法，发现了如下实验可以证明bug的存在位置：实验方法与步骤：
1、先把二进制数据写入Access数据库
2、使用SQLServer2000的导入导出工具导入到SQLServer
3、分别使用JDBC驱动和JDBC-ODBC桥驱动从SQLServer中读取数据并写入到文件
4、分别使用MD5和Ultraedit比较原文件和从数据库中读取到的文件对比1、2步骤可以用使用jdbc-odbc桥驱动写入到数据库SQLServer来替代。实验结论：
SQLServer 2000的JDBC驱动程序在使用ResultSet.getBinaryStream()时得到的InputStream，总是把数据流的最后一个字节重复。
比如如下字节流：01 ab cd ef
在原文件中为：  01 ab cd ef
在数据库中为：  01 ab cd ef
从数据库中使用jdbc-odbc桥驱动读取为： 
                01 ab cd ef
从数据库中使用jdbc驱动读取为：
                01 ab cd ef ef
另外，之所以一开始会让我得出写入时需要减一的结论。是由于正确格式的.torrent（BitTorrent）文件总是以65 65结尾的（即e e）。
也就是说每个文件都是这样的：
...65 65
写入到数据库时减一：
...65
读出时由于jdbc驱动程序的错误重复最后一个字节：
...65 65
如果有需要测试程序，跟我联系就行了，累死我了，为了找到它，从1：15到3：32才找到原因，写出此贴。
微软提供的sqlserver2000的jdbc驱动的源程序我也不想去追究到底在那一行了，累死人。

Answer 5

另外还发现jdbc在读取数据时，如果有两个字段都是BinaryStream的话，那么你不能一起把它读出来，而用jdbc-odbc桥时就可以。

Answer 6

经过进一步研究发现是在使用方法：int read(byte[]?b)时才会发生，而使用int read()则没有错误。        InputStream is = rs.getBinaryStream(1);
        //这段代码有问题
        byte[] b = new byte[1];
        while (is.read(b) != -1) {//is.read(b),问题在这里
          response.getOutputStream().write(b);
        }
        //这段代码没问题
        int b;
        while ( (b = is.read()) != -1) {
          response.getOutputStream().write(b);
        }