重复读取InputStream的方法
来源:互联网 发布:帝国仿内涵吧网源码 编辑:程序博客网 时间:2024/05/16 05:41
1.为什么InputStream不能重复读取
首先,熟悉Java的人可能都知道,Java中的Inputstream是不能重复读取的。 但是有没有想过,InputStream为什么不能重复读呢?
其实要回答“为什么”这个问题很简单,就是人家接口就是这么设计的,不能重复读。 所以今天要讨论的问题更像是:Java的InputStream为什么要设计为不能重复读?
关于InputStream为什么不能重复读取,网上也各有说法:
有的同学说:
“InputStream就类比成一个杯子,杯子里的水就像InputStream里的数据,你把杯子里的水拿出来了,杯子的水就没有了,InputStream也是同样的道理。”
比喻的非常好,让我们从直观上认识了InputStream为什么不能重复被读。
也有的同学从更深的代码角度去分析:
“在InputStream读取的时候,会有一个pos指针,他指示每次读取之后下一次要读取的起始位置,当读到最后一个字符的时候,pos指针不会重置。”
说的也有道理,就是说InputStream的读取是单向的。但是并不是所有的InputStream实现类都是这样的实现方式。
//BufferedInputStream代码片段: public synchronized int read() throws IOException { if (pos >= count) { fill(); if (pos >= count) return -1; } return getBufIfOpen()[pos++] & 0xff; } //FileInputStream代码片段: public native int read() throws IOException;
我们知道:
Java 的List内部是使用数组实现的,遍历的时候也有一个pos指针。但是没有说List遍历一个第二次遍历就没有了。第二次遍历是创建新的Iterator,所以pos也回到了数组起始位置。对于某些InputStream当然可以也这么做。例如:ByteArrayInputStream ,ByteArrayInputStream就是将一个Java的byte数组保存到对象里,然后读取的时候遍历该byte数组。
public ByteArrayInputStream(byte buf[]) { this.buf = buf; this.pos = 0; this.count = buf.length; } public synchronized int read() { return (pos < count) ? (buf[pos++] & 0xff) : -1; }
就ByteArrayInputStream而言,要实现重复读取是很简单的,但是为什么没有。我想是为了遵循InputStream的统一标准。
在InputStream的read方法的注释上明确说明:
/** * Reads the next byte of data from the input stream. The value byte is * returned as an <code>int</code> in the range <code>0</code> to * <code>255</code>. If no byte is available because the end of the stream * has been reached, the value <code>-1</code> is returned. This method * blocks until input data is available, the end of the stream is detected, * or an exception is thrown. * * <p> A subclass must provide an implementation of this method. * * @return the next byte of data, or <code>-1</code> if the end of the * stream is reached. * @exception IOException if an I/O error occurs. */ public abstract int read() throws IOException;
当流到达末尾后,返回-1.
其实像FileInputStream这样的文件流,要实现重复使用可能也并不是很难,利用缓存什么的应该能做到(大文件读取就悲剧了,呵呵呵)。
但是InputStream顾名思义就是一个单向的字节流,跟水流一样,要想再次使用就自己再去源头取一下。
InputStream其实不像杯子,更像是一根水管,要想喝水了,就在把水管架在水源与杯子之间,让水流到杯子里(注意:这个动作完成了之后水管里面就没有水了)。
这样看来,InputStream其实是一个数据通道,只负责数据的流通,并不负责数据的处理和存储等其他工作范畴。
前面讲过,其实有的InputStream实现类是可以实现数据的处理工作的。但是没有这么做,这就是规范和标准的重要性。
2.重复读取InputStream的方法
我们知道Java的InputStream是不能重复被读取的。
但是在有的场合中,我们需要重复利用InputStream的数据。
比如:
- 一个office word文件流,我需要首先读取InputStream中的前一些字节来判断word文件的实际内容(word文件可以保存html,mht的内容)。然后再根据实际内容决定我要解析InputStream的方式。
- 一个Html文件流,我需要首先读取InputStream中的一些字节来判断Html文件编码方式。然后再根据html文件编码方式读取Html内容
- 从socket收到的一个InputStream,我首先需要读取InputStream判断是什么类型的字符串。然后再将InputStream读取写到文件里。
总之,在实际的工作当中,我们常常会需要多次读取一个InputStream的需求。
如果该InputStream是我们通过某种方式“主动”获取的,那我们可以不必重复读取一个InputStream,而是再次获取一样数据的InputStream来处理。
例如:
InputStream inputStream = new FileInputStream(path); //利用inputStream inputStream = new FileInputStream(path); //再次利用inputStream
再例如:
InputStream inputStream = httpconn.getInputStream(); //利用inputStream inputStream = httpconn.getInputStream(); //再次利用inputStream
但是,对于“被动”利用InputStream的接口,在接口内部需要重复利用InputStream,对于InputStream的来源,可能是文件,可能是网络,也可能是内存里的一个String,对于InputStream的方式接口内部不得而知,因此更谈不上在接口内部重复获取了。
例如有这样一个接口:
//将InputStream转换成一个文本字符串 public String convert(InputStream inputStream);
在接口内部我们可能需要首先读取InputStream前n个字节来判断InputStream流的数据流型,然后转化InputStream为一个字符串。
最简单的方式就是缓存,首先将InputStream缓存到内存,然后重复使用内存里的数据。
例如:
package com.gs.cvoud.attachment.converter; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.InputStream; import com.gs.cvoud.util.ObjectUtils; /** * 缓存InputStream,以便InputStream的重复利用 * @author boyce * @version 2014-2-24 */ public class InputStreamCacher { private static final org.slf4j.Logger logger = org.slf4j.LoggerFactory.getLogger(InputStreamCacher.class); /** * 将InputStream中的字节保存到ByteArrayOutputStream中。 */ private ByteArrayOutputStream byteArrayOutputStream = null; public InputStreamCacher(InputStream inputStream) { if (ObjectUtils.isNull(inputStream)) return; byteArrayOutputStream = new ByteArrayOutputStream(); byte[] buffer = new byte[1024]; int len; try { while ((len = inputStream.read(buffer)) > -1 ) { byteArrayOutputStream.write(buffer, 0, len); } byteArrayOutputStream.flush(); } catch (IOException e) { logger.error(e.getMessage(), e); } } public InputStream getInputStream() { if (ObjectUtils.isNull(byteArrayOutputStream)) return null; return new ByteArrayInputStream(byteArrayOutputStream.toByteArray()); } }
接口内部使用情景:
InputStreamCacher cacher = new InputStreamCacher(inputStream); InputStream stream = cacher.getInputStream(); //读取stream stream = cacher.getInputStream();
上述的方式是将InputStream缓存到一个ByteArrayOutputStream中,当然缓存的数据类型和方式都是任意的,这只是一种解决思路。
这种方式有一个最大的缺点,就是内存压力。
外部传给接口的InputStream有可能很大。每调用一次接口就将InputStream缓存到内存中,内存要承受的压力是可想而知的。
编程永远都是在时间和空间之间找到一个平衡点,前面说的“主动获取方式”的重复获取也有它的缺点,就是需要重新读取文件,获取重新建立网络连接等,这就是需要消耗更多的时间。
万事万物都是这样,天下没有完美的事,有舍才有得,选择什么就意味着放弃什么,开了一扇窗可能就要关一扇门。所以不管是生活还是编程,我们都需要在舍与得,选择的与放弃的,窗和门之间做出相对合理的抉择,或者说不得不做的抉择。
闲话扯远了,其实重复利用InputStream还有另一种方式:
3.通过mark和reset方法重复利用InputStream
之前,我们已经简单的知道可以通过缓存InputStream来重复利用一个InputStream,但是这种方式的缺点也是明显的,就是要缓存一整个InputStream内存压力可能是比较大的。如果第一次读取InputStream是用来判断文件流类型,文件编码等用的,往往不需要所有的InputStream的数据,或许只需要前n个字节,这样一来,缓存一整个InputStream实际上也是一种浪费。
其实InputStream本身提供了三个接口:
第一个,InputStream是否支持mark,默认不支持。
public boolean markSupported() { return false; }
第二个,mark接口。该接口在InputStream中默认实现不做任何事情。
public synchronized void mark(int readlimit) {}
第三个,reset接口。该接口在InputStream中实现,调用就会抛异常。
public synchronized void reset() throws IOException { throw new IOException("mark/reset not supported"); }
从三个接口定义中可以看出,首先InputStream默认是不支持mark的,子类需要支持mark必须重写这三个方法。
第一个接口很简单,就是标明该InputStream是否支持mark。
mark接口的官方文档解释:
“在此输入流中标记当前的位置。对 reset 方法的后续调用会在最后标记的位置重新定位此流,以便后续读取重新读取相同的字节。
readlimit 参数告知此输入流在标记位置失效之前允许读取许多字节。
mark 的常规协定是:如果方法 markSupported 返回 true,则输入流总会在调用 mark 之后记住所有读取的字节,并且无论何时调用方法 reset ,都会准备再次提供那些相同的字节。但是,如果在调用 reset 之前可以从流中读取多于 readlimit 的字节,则根本不需要该流记住任何数据。”
reset接口的官方文档解释:
将此流重新定位到对此输入流最后调用 mark 方法时的位置。
reset 的常规协定是:
如果方法 markSupported 返回 true,则:
如果创建流以来未调用方法 mark,或最后调用 mark 以来从该流读取的字节数大于最后调用 mark 时的参数,则可能抛出 IOException。
如果未抛出这样的 IOException,则将该流重新设置为这种状态:最近调用 mark 以来(或如果未调用 mark,则从文件开始以来)读取的所有字节将重新提供给 read 方法的后续调用方,后接可能是调用 reset 时的下一输入数据的所有字节。
如果方法 markSupported 返回 false,则:
对 reset 的调用可能抛出 IOException。
如果未抛出 IOException,则将该流重新设置为一种固定状态,该状态取决于输入流的特定类型和其创建方式的固定状态。提供给 read 方法的后续调用方的字节取决于特定类型的输入流。
简而言之就是:
调用mark方法会记下当前调用mark方法的时刻,InputStream被读到的位置。
调用reset方法就会回到该位置。
举个简单的例子:
String content = "BoyceZhang!"; InputStream inputStream = new ByteArrayInputStream(content.getBytes()); // 判断该输入流是否支持mark操作 if (!inputStream.markSupported()) { System.out.println("mark/reset not supported!"); } int ch; boolean marked = false; while ((ch = inputStream.read()) != -1) { //读取一个字符输出一个字符 System.out.print((char)ch); //读到 'e'的时候标记一下 if (((char)ch == 'e')& !marked) { inputStream.mark(content.length()); //先不要理会mark的参数 marked = true; } //读到'!'的时候重新回到标记位置开始读 if ((char)ch == '!' && marked) { inputStream.reset(); marked = false; } } //程序最终输出:BoyceZhang!Zhang!
看了这个例子之后对mark和reset接口有了很直观的认识。
但是mark接口的参数readlimit究竟是干嘛的呢?
我们知道InputStream是不支持mark的。要想支持mark子类必须重写这三个方法,我想说的是不同的实现子类,mark的参数readlimit作用不尽相同。
常用的FileInputStream不支持mark。
- 对于BufferedInputStream,readlimit表示:InputStream调用mark方法的时刻起,在读取readlimit个字节之前,标记的该位置是有效的。如果读取的字节数大于readlimit,可能标记的位置会失效。
在BufferedInputStream的read方法源码中有这么一段:
} else if (buffer.length >= marklimit) { markpos = -1; /* buffer got too big, invalidate mark */ pos = 0; /* drop buffer contents */ } else { /* grow buffer */
为什么是可能会失效呢?
因为BufferedInputStream读取不是一个字节一个字节读取的,是一个字节数组一个字节数组读取的。
例如,readlimit=35,第一次比较的时候buffer.length=0(没开始读)<readlimit
然后buffer数组一次读取48个字节。这时的read方法只会简单的挨个返回buffer数组中的字节,不会做这次比较。直到读到buffer数组最后一个字节(第48个)后,才重新再次比较。这时如果我们读到buffer中第47个字节就reset。mark仍然是有效的。虽然47>35。
- 对于InputStream的另外一个实现类:ByteArrayInputStream,我们发现readlimit参数根本就没有用,调用mark方法的时候写多少都无所谓。
public void mark(int readAheadLimit) { mark = pos; } public synchronized void reset() { pos = mark; }
因为对于ByteArrayInputStream来说,都是通过字节数组创建的,内部本身就保存了整个字节数组,mark只是标记一下数组下标位置,根本不用担心mark会创建太大的buffer字节数组缓存。
- 其他的InputStream子类没有去总结。原理都是一样的。
所以由于mark和reset方法配合可以记录并回到我们标记的流的位置重新读流,很大一部分就可以解决我们的某些重复读的需要。
这种方式的优点很明显:不用缓存整个InputStream数据。对于ByteArrayInputStream甚至没有任何的内存开销。
当然这种方式也有缺点:就是需要通过干扰InputStream的读取细节,也相对比较复杂。
原文:查看原文
- 重复读取InputStream的方法
- 重复读取InputStream的方法
- 构建可重复读取inputStream的request
- 构建可重复读取inputStream的request
- 重复读取request中的inputstream
- InputStream为什么不能被重复读取?
- InputStream为什么不能被重复读取?
- InputStream的read方法读取字节不完全的问题
- InputStream的read方法读取字节不完全的解决方案
- Java InputStream读取网络响应Response数据的方法!(重要)
- 三种将公用配置文件读取为InputStream的方法
- I/O流学习--InputStream的读取文件方法
- 输入流重复读取问题,解决InputStream引发的空指针问题
- ark和reset方法重复利用InputStream
- InputStream流的二次读取
- InputStream的avaliable()方法
- 拦截器中,request中getReader()和getInputStream()只能调用一次,构建可重复读取inputStream的request.
- io读取的输入输出,InputStream ,OutputStream 的read(),write()方法的详细介绍
- Qt OpenGL教程 (非常详细)
- 模板的分离编译
- python一个关于贴吧的小爬虫(二)
- MySQL主从实验
- 集合框架(一)续 向集合中添加一个集合、数组和List之间的相互转换、从集合中删除另一个集合所包含的元素
- 重复读取InputStream的方法
- MySQL主从实验
- 项目中整合第三方插件与SpringMVC数据格式化关于ip地址
- hdu 1849 Rabbit and Grass
- 高性能MYsql读书笔记-加快alter table操作的速度
- Renesas CS+ for ca cx入门(三)
- Algorithm_princeton UnionFind COPY
- spring task 定时任务实现
- VIM配置