简体   繁体   中英

about download a file by java drive api

I use the "get" method from java drive api, and I can get the inputstream. but I cannt open the file when I use the inputstream to creat it. It likes the file is broken.

private static String fileurl = "C:\\googletest\\drive\\";

public static void newFile(String filetitle, InputStream stream) throws IOException {
    String filepath = fileurl + filetitle;      
    BufferedInputStream bufferedInputStream=new BufferedInputStream(stream);
    byte[] buffer = new byte[bufferedInputStream.available()];


    File file = new File(filepath);
    if (!file.exists()) {
        file.getParentFile().mkdirs();

        BufferedOutputStream bufferedOutputStream = new BufferedOutputStream(new FileOutputStream(filepath));
          while( bufferedInputStream.read(buffer) != -1) { 
              bufferedOutputStream.write(buffer);
      }  
          bufferedOutputStream.flush();
          bufferedOutputStream.close();
    }
}

Firstly, C:\\googletest\\drive\\ is not a URL. It is a file system pathname.

Next, the following probably does not do what you think it does:

  byte[] buffer = new byte[bufferedInputStream.available()];

The problem is that the available() call can return zero ... for a non-empty stream. The value returned by available() is an estimate of how many bytes that are currently available to read ... right now. That is not necessarily the stream length ... or anything related to it. And indeed the device drivers for some devices consistently return zero, even when there is data to be read.

Finally, this is wrong:

   while( bufferedInputStream.read(buffer) != -1) { 
          bufferedOutputStream.write(buffer);

You are assuming that read returning -1 means that it filled the buffer. That is not so. Any one of the read calls could return with a partly full buffer. But then you write the entire buffer contents to the output stream ... including "junk" from previous reads.


Either or both of the 2nd and 3rd problems could lead to file corruption. In fact, the third one is likely to.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM