最近在pc中测试j2me gzip的效率:
碰到了如下异常:
java.io.IOException: Unexpected end of ZLIB input stream
at com.tinyline.util.GZIPInputStream.if(+39)
at com.tinyline.util.GZIPInputStream.for(+48)
at com.tinyline.util.GZIPInputStream.read(+27)
at com.tinyline.util.GZIPInputStream.read(+8)
......
java.lang.NullPointerException
at java.io.OutputStream.write(+4)
.....
上网搜索找到如下文章,对我有所启示,毕竟按照它的改法,在pc中,在手机中都ok了。
[第一篇]:
java.io.EOFException: Unexpected end of ZLIB 的临时解决方法
2007-12-01 04:09
bobrow小作,允许自由转帖,不过请注明作者和出处,谢谢。在玩httpunit1.6时,捕获了“java.io.EOFException: Unexpected end of ZLIB”异常。 问题是这样的,com.meterware.httpunit.WebResponse类的readFromStream方法中有一段读取inputStream的代码: if (maxBytes > 0) { do { outputStream.write( buffer, 0, count ); maxBytes -= count; if (maxBytes <= 0) break; count = inputStream.read( buffer, 0, Math.min( maxBytes, buffer.length ) ); } while (count != -1); } 抛出异常的正是做红色标记的代码。由于抛出异常的前一个count值不是-1,所以执行了红色代码。跟踪进去,发现java.util.zip.InflaterInputStream类方法fill(): protected void fill() throws IOException { ensureOpen(); len = in.read(buf, 0, buf.length); if (len == -1) { throw new EOFException("Unexpected end of ZLIB input stream"); } inf.setInput(buf, 0, len); } 因len为-1所以抛出异常。 按照我自己的理解,len为-1之前count肯定也为-1。但是实际执行过程却是count不为-1(表示 inputStream还有后续内容),但是len为-1(表示 in没有后续内容了),这是矛盾的嘛。我还没深入查看 inputStream是怎么转为fill()方法中 in的。 知道问题大概所在,我采取了很没技术含量的方法:catch fill()方法抛出的IOException,然后在catch中把count置-1。代码如下: if (maxBytes > 0) { do { outputStream.write( buffer, 0, count ); maxBytes -= count; if (maxBytes <= 0) break; try { count = inputStream.read( buffer, 0, Math.min( maxBytes, buffer.length ) ); } catch (IOException e) { count = -1; } } while (count != -1); } 这样count和len就保持一致了。但问题来了:事实上 inputStream还没读完的,所以WebResponse.getText()只有前半段内容,会比浏览器里查看时内容要少。这个很容易理解。 到现在我还不明白为什么明明count不为-1但是fill()方法却不能读流了呢?呵呵,继续研究。 真正解决方法在 这里。
|
[第二篇]:
httpunit中java.io.EOFException: Unexpected end of ZLIB 的解决方法
2007-12-01 14:28
bobrow小作,允许自由转帖,但请注明出处和作者。谢谢。
今天凌晨写了一篇暂时解决httpunit异常“java.io.EOFException: Unexpected end of ZLIB ”的方法,今天起床仔细查看了httpunit1.6的WebResponse代码,在其defineRawInputStream方法中看到了感觉多于的代码:
final protected void defineRawInputStream( InputStream inputStream ) throws IOException { if (_inputStream != null || _responseText != null) { throw new IllegalStateException( "Must be called before response text is defined." ); }
if (encodedUsingGZIP()) { byte[] compressedData = readFromStream( inputStream, getContentLength() ); _inputStream = new GZIPInputStream( new ByteArrayInputStream( compressedData ) ); } else { _inputStream = inputStream; } }
红色标记的两行代码是其原有的代码。把一个InputStream转型为GZIPInputStream不需要这么复杂吧?
于是我把代码一修改成如下:
final protected void defineRawInputStream( InputStream inputStream ) throws IOException { if (_inputStream != null || _responseText != null) { throw new IllegalStateException( "Must be called before response text is defined." ); }
if (encodedUsingGZIP()) { _inputStream = new GZIPInputStream(inputStream); } else { _inputStream = inputStream; } }
蓝色标记代码为我修改的。呵呵,问题解决了。
后记:
1、其实为什么原代码处理GZIP流时会出错,而采用GZIPInputStream自带转型方式没问题,我也不是很明白,因为没去看GZIPInputStream到底是怎么转型的。得出的经验就是标准库有的方法,自己没必要去再实现一遍。
2、昨晚搜索了Google和百度N多文章,将近两小时的搜索也没有这个问题的结果。别人碰到过这个问题,但就是没人给出明确的解决方法。郁闷,只好自己动手解决了。
|
自己刚开始用的出错的方法:
public static byte[] gzipToXmlBytes(byte[] zipedfilebytes) {
ByteArrayInputStream bis = new ByteArrayInputStream(zipedfilebytes);
GZIPInputStream gis = null ;
try {
pos += "f" ;
byte[] buf = new byte[BUFSIZE];
gis = new GZIPInputStream(bis);
int len = 0;
int realsize=0;
while ( (len = gis.read(buf)) >= 0) {
......... ......... .........
后来按照上面的提示,问题搞定了。
在手机上测试j2me gzip的解压表现:
把 a.gz文件[2.11M] 解压到手机[n6120c]文件系统里面,大概需要23秒钟左右.
解压后的文件为a.dat文件[2.23M]。
把 b.gz文件[423k] 解压到手机[n6120c]文件系统里面,大概需要5秒钟左右.
解压后的文件为b.dat文件[469k]。
大概平均一秒钟 80~90k .
不知道其它仁兄的结果如何?
分享到:
相关推荐
j2me gzip压缩总汇
在平时的开发中,我们会碰到数据量过大的问题,为了解决这个问题,我们可以用GZIP处理方式,J2ME本身没有提供GZIP压缩,但可以利用一些开源包。 上面此句用于解压GZIP,至是否要转换成DataInputStream还是...
j2me zip 压缩及解压,不支持gzip格式
gzip压缩源代码,由java语言编写,里面有个ZipUtil类,其中有两个静态方法可以方便调用用来压缩和解压缩。该包可以用于j2me和android程序中。
能在j2me项目使用zip技术和gzip压缩解压
使用java语言可以很方便的实现gzip压缩和解压缩.以下是一个压缩和解压缩的最简程序.
GZIPInputStream This filter stream is used to decompress a "GZIP" format stream. GZIPOutputStream This filter stream is used to compress a stream into a "GZIP" stream. Inflater Inflater is used to ...
Compress files in j2me
Java用GZIP压缩解压文件.rar Java用Zip压缩多个文件实例源码.rar Java用的在线地图浏览模块.rar Java约瑟夫环演示Applet源码.rar java网络五子棋的源代码.rar JAVA网络抓包程序.rar Java转换xml.rar java项目源码...
这是个J2ME控制台程序,它能剔除PNG文件中的非关键数据段,减少文件大小从而达到压缩图片的目的。而图片的质量并不会受到损失。使用时候只需在控制台窗口执行jar就可以了。 Java 3DMenu 界面源码 5个目标文件 ...
这是个J2ME控制台程序,它能剔除PNG文件中的非关键数据段,减少文件大小从而达到压缩图片的目的。而图片的质量并不会受到损失。使用时候只需在控制台窗口执行jar就可以了。 Java 3DMenu 界面源码 5个目标文件 ...
这是个J2ME控制台程序,它能剔除PNG文件中的非关键数据段,减少文件大小从而达到压缩图片的目的。而图片的质量并不会受到损失。使用时候只需在控制台窗口执行jar就可以了。 Java 3DMenu 界面源码 5个目标文件 ...
这是个J2ME控制台程序,它能剔除PNG文件中的非关键数据段,减少文件大小从而达到压缩图片的目的。而图片的质量并不会受到损失。使用时候只需在控制台窗口执行jar就可以了。 Java 3DMenu 界面源码 5个目标文件 ...
J2ME优化压缩PNG文件 4个目标文件 内容索引:JAVA源码,综合应用,J2me游戏,PNG,图形处理 这是个J2ME控制台程序,它能剔除PNG文件中的非关键数据段,减少文件大小从而达到压缩图片的目的。而图片的质量并不会受到损失...
J2ME优化压缩PNG文件 4个目标文件 内容索引:JAVA源码,综合应用,J2me游戏,PNG,图形处理 这是个J2ME控制台程序,它能剔除PNG文件中的非关键数据段,减少文件大小从而达到压缩图片的目的。而图片的质量并不会受到损失...
Apime是J2ME应用程序的框架。 它与MIDP 1.0兼容。 核心是用户界面(UI),其结构类似于j2se的Swing,支持外观,国际化,键盘,GZIP等。
这是个J2ME控制台程序,它能剔除PNG文件中的非关键数据段,减少文件大小从而达到压缩图片的目的。而图片的质量并不会受到损失。使用时候只需在控制台窗口执行jar就可以了。 Java 3DMenu 界面源码 5个目标文件 ...
这是个J2ME控制台程序,它能剔除PNG文件中的非关键数据段,减少文件大小从而达到压缩图片的目的。而图片的质量并不会受到损失。使用时候只需在控制台窗口执行jar就可以了。 Java 3DMenu 界面源码 5个目标文件 ...