问题标签 [gzipinputstream]

我需要逐块下载压缩数据并将其附加到文件中。问题是当我从 HTTP conn 读取时，它不会一次发送总压缩字节数组（流）。我的应用程序在之前发送的字节数组的剩余字节中寻找 Gzip 标头。我怎样才能强制http一次性发送字节数组的压缩实例。这是我的代码片段，它将数据压缩并将其添加到文件中。

解压功能：-

GZIP 的大小限制为 4GB，从http://www.gzip.org/#faq10获得 。上面的链接中提到了一些补丁，可以读取超过 4GB 的文件。

我正在使用 GZIPInputStream 读取 .gz 文件。

而且我也能够读取超过 4GB 的大小。我知道我正在混淆 java 中的输入流和实际的 gzip 可执行文件。

但我想知道这是否可能是一个问题？

例如 - 是否会出现我无法在 java 中读取 6Gb .gz 文件的情况？直到现在我试过了，我没有遇到任何问题。

简而言之，gzip文件大小限制和java中的gzipinputstream之间有关系吗？

我有一个奇怪的程序，其中 GzipInputStream 零填充缓冲区的一部分。我有幸知道字节在流中应该是什么样子，我可以看到缓冲区被 8 个正确字节和 12 个零（不应该为零）填充

字节应如下所示----> 0 20 82 22 -91 27 -96 65 66 65 88 32 32 32 32 81 32 0 0 0 100 78

字节实际上看起来像这样---> 0 20 82 22 -91 27 -96 65 66 65 0 0 0 0 0 0 0 0 0 0 0 0

前两个字节表示一个整数，它确定前两个之后的可变长度（以字节为单位）有效负载的大小。所以在这个例子中，第一个字节是 0 20，在 BIG_ENDIAN 中，这给了我们一个 20 字节的后续有效负载大小。

这是我的阅读代码

所以前两个字节是有效负载数组中的字节，后 20 个字节是 messageBytes 中的字节。想不通

由于 NPE 修改了代码

我正在尝试使用以下 Java 代码来压缩和解压缩字符串。但是从新的 ByteArrayInputStream 对象中创建新的 GZipInputStream 对象的行会引发“java.util.zip.ZipException: Not in GZIP format”异常。有谁知道如何解决这个问题？

我正在尝试通过 tcp 将以下 json 写入 graylog 服务器：

以下是通过网络传输的实际压缩字节：

并且 graylog 服务器抛出以下异常：

写入 UDP 端口时完全相同的消息通过。

负责在线写入字节的 C# 代码片段：

任何提示/建议都非常感谢。

Graylog jira链接。 Github 问题链接。

在代码中

，如何通过知道文件解压缩长度来优化磁盘空间使用而不创建大字节[]？

根据这个答案，没有这种方法。

这个想法是使用这个 byte[] 来调用

出于这个原因，我需要一个包含所有内容且没有额外零的字节 []。

我们有一个大部分时间都运行良好的应用程序。

值得注意的是，如果我们在发送数据进行渲染时关闭服务器和客户端之间的压缩（gzip），它总是有效的。

当我们打开 gzip（首选模式）时 - 有时 - 很少但有时 - 我们会遇到解压缩流失败，如下所示：

注意我们得到双>>的结尾。

我们可以在几个查询响应上复制该行为，但不是全部，也不是在所有环境中。

我们认为问题已经缩小到正在压缩流的服务器端，因为我们有 Firefox 和 javasGZIPInputStream都以相同的方式解密流（我们不认为 Firefox 使用GZIPInputStream）

关于如何进一步调试的任何提示？中的任何已知错误GZIP？

谢谢你。

我正在尝试从 URL 中检索 gzip 后的 XML 文件。我的问题是，GZipInputStream在生产中使用解压缩时，我得到的内容似乎被截断了。我最多只能读取 xml 的一小部分。

此代码始终只读取 xml 的一小部分。多次运行它会显示完全相同的结果。我已经尝试过先下载二进制内容，使用 aByteArrayOutputStream.数组的大小与我下载的文件完全相同。但是，当我使用GZipInputStream解压缩字节数组时，我仍然得到相同的截断字符串。

顺便说一句，在本地一切正常，所以我被引导相信在GZipInputStream某种程度上受限于GAE. 有谁知道我怎么能解决这个问题？

我正在尝试从公共匿名 ftp 读取文件，但遇到了问题。我可以很好地读取纯文本文件，但是当我尝试读取 gzip 文件时，我得到了这个异常：

我尝试下载文件并使用FileInputStream包装在 a 中GZIPInputStream并遇到完全相同的问题，所以我认为这不是 FTP 客户端（即 apache）的问题。

这是一些重现问题的测试代码。它只是试图打印到标准输出：

我找不到任何关于为什么会发生这种情况的文档，并且通过调试器中的代码跟踪它并没有让我到任何地方。我觉得我错过了一些明显的东西。

编辑：我手动下载了文件并使用 GZIPInputStream 将其读入，并且能够很好地打印出来。我已经用 2 个不同的 Java FTP 客户端尝试过这个

我正在为我们的一些系统之间的交互实施 GZIP 压缩。这些系统是用 Java 和 C# 编写的，因此双方都使用 GZIP 流，因为它们具有标准库支持。

在 C# 方面，一切正常，包括我们最大的测试文件（70MB 未压缩），但是我们遇到了 Java 堆空间不足的问题。我们已尝试将堆大小增加到 IDE 的容量，但问题仍未解决。

我已经采取了一些措施来尝试优化 Java 代码，但似乎没有什么可以阻止数据堆积在堆中。有没有好的方法来处理这个？下面是我当前（处理较小的流）解决方案的一个子集。

编辑：根据@MarkoTopolnik 的建议修改了以下代码。通过更改，崩溃前读取了 1700 万个字符。

代码在命中超过 760 万个字符后终止，ArrayList堆栈跟踪表明ArrayList.add()调用是原因（在触发内部数组扩展后失败）。

使用上面编辑过的代码，调用AbstractStringBuilder.expandCapacity()是杀死程序的原因。

是否有一种内存消耗较少的方法来实现动态数组，或者我可以使用一些完全不同的方法从解压缩的流中获取字符串？任何建议将不胜感激！