从 InputStream 读取时出现 IOException
我在 Android 平台上从 InputStream 读取数据时遇到了一个奇怪的问题。 我不确定这是 Android 特有的问题，还是我一般做错的事情。
唯一特定于 Android 的是此调用：
InputStream is = getResources().openRawResource(R.raw.myfile);
这会返回 Android 资产中的文件的InputStream。 无论如何，这就是我遇到问题的地方：
bytes[] buffer = new bytes[2];
is.read(buffer);
当 read() 执行时，它会抛出一个IOException。 奇怪的是，如果我执行两次连续的单字节读取（或任意数量的单字节读取），也不例外。 例如，这是可行的：
byte buffer;
buffer = (byte)buffer.read();
buffer = (byte)buffer.read();
知道为什么两个连续的单字节读取有效，但一次调用同时读取两个字节会引发异常吗？ InputStream 看起来不错... is.available() 返回超过一百万个字节（正如它应该的那样）。
堆栈跟踪在 InputStream.read() 之前显示这些行：
java.io.IOException
at android.content.res.AssetManager.readAsset(Native Method)
at android.content.res.AssetManager.access$800(AssetManager.java:36)
at android.content.res.AssetManager$AssetInputStream.read(AssetManager.java:542)
将缓冲区大小更改为单个字节仍然会引发错误。 看起来只有在读入字节数组时才会引发异常。
如果我将文件截断为 100,000 字节（文件最初为：1,917,408 字节），则它可以正常工作。 超过一定大小的文件是否有问题？
感谢任何帮助！
谢谢！
I'm running into a strange problem while reading from an InputStream on the Android platform. I'm not sure if this is an Android specific issue, or something I'm doing wrong in general.
The only thing that is Android specific is this call:
InputStream is = getResources().openRawResource(R.raw.myfile);
This returns an InputStream for a file from the Android assets. Anyways, here's where I run into the issue:
bytes[] buffer = new bytes[2];
is.read(buffer);
When the read() executes it throws an IOException. The weird thing is that if I do two sequential single byte reads (or any number of single byte reads), there is no exception. In example, this works:
byte buffer;
buffer = (byte)buffer.read();
buffer = (byte)buffer.read();
Any idea why two sequential single byte reads work but one call to read both at once throws an exception? The InputStream seems fine... is.available() returns over a million bytes (as it should).
Stack trace shows these lines just before the InputStream.read():
java.io.IOException
at android.content.res.AssetManager.readAsset(Native Method)
at android.content.res.AssetManager.access$800(AssetManager.java:36)
at android.content.res.AssetManager$AssetInputStream.read(AssetManager.java:542)
Changing the buffer size to a single byte still throws the error. It looks like the exception is only raised when reading into a byte array.
If I truncate the file to 100,000 bytes (file is: 1,917,408 bytes originally) it works fine. Is there a problem with files over a certain size?
Any help is appreciated!
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
（我发给 android-developers 的帖子没有显示，所以我会尝试在这里重新发布它）
IIRC，这个问题来自于尝试访问在构建 APK 过程中压缩的文件。
因此，要解决此问题，请为其指定一个不会被压缩的文件扩展名。 我忘记了跳过哪些扩展名的列表，但已知已压缩的文件类型（例如 mp3、jpg）可能有效。
(my post to android-developers isn't showing up, so I'll try reposting it here)
IIRC, this problem comes from trying to access files that were compressed as part of building the APK.
Hence, to work around the issue, give it a file extension that won't be compressed. I forget the list of what extensions are skipped, but file types known to already be compressed (e.g., mp3, jpg) may work.
将文件扩展名更改为 .mp3 以避免文件压缩确实有效，但应用程序的 APK 要大得多（在我的例子中为 2.3 MB，而不是 0.99 MB）。
还有其他方法可以避免这个问题吗？
这是我的回答：
从资产文件夹加载大于 1M 的文件
Changing the file extension to .mp3 to avoid the file compression does work, but the APK of the app is much bigger (in my case 2.3 MB instead of 0.99 MB).
Is there any other way to avoid this issue ?
Here is my answer:
Load files bigger than 1M from assets folder
您可以使用 GZIP 自行压缩文件并使用 GZIPInputStream 类解压它。
http://developer.android.com/reference/java/util/zip /GZIPInputStream.html
You can compress the file for yourself with GZIP and unpack it with GZIPInputStream class.
http://developer.android.com/reference/java/util/zip/GZIPInputStream.html
您是对的，因为提取文件有一定的大小限制。 您可能希望将较大的文件分割成 1MB 的块，并有一种方法可以让您知道哪些文件由哪些块组成，并在应用程序运行时将它们重新拼接在一起。
You are correct, in that there is a certain size limit for extracting files. You may wish to split larger files into 1MB pieces, and have a method by which you know which files are made of which pieces, stitching them back together again when your app runs.