在 Java 中膨胀 byte[] 的问题？答案

【问题标题】：Problem Inflating byte[] in Java?在 Java 中膨胀 byte[] 的问题？
【发布时间】：2011-01-06 15:22:16
【问题描述】：

我遇到了一个我无法弄清楚的问题。这是问题的定义：我在 Db2/Linux 环境的 Blob 列中有一些数据。在使用 JDK 压缩（执行此操作的代码在 Linux 环境中运行）压缩 byte[] 之后，将 Blob 写入 DB2。我正在尝试编写一个简单的程序来读取其中一些数据解压缩它（使用 JDK）并从 Windows 环境（我的开发环境）中的解压缩字节数组创建一个字符串。问题是在我解压 Blob (byte[]) 后，解压后的字节数组的长度通常比预期的长 1-3 个字节。我的意思是偏移量和长度字段也存储在数据库中。所以在这种情况下，解压后的字节数组的长度通常比数据库中存储的长度要长，只有几个字节。因此，如果我从解压缩的字节数组中创建一个 String 对象，并使用数据库中的 offset 和 length 字段使用 substring(offset, length) 方法创建另一个 String 对象，我的第二个 String（我通过使用 substring 方法得到的那个）是更短。

一个例子是：数据库记录包含一个 blob，偏移量：0，长度：260,409 解压blob后 -

 compressedByte[].length  - 71,212
 decompressedByte[].length   - 260,412
 new String(decompressByte[]).length()  - 260,412
 new String(decompressByte[]).subString(0, 260,409).length() - 260409

对于其他一些输入记录，我看到的差异是长度在 1-3 个字节之间。

我对这个问题有点困惑，想知道是否有人可以提出任何建议，以便我可以进行更多调试来解决这个问题。我想知道这是否可能与字节在 Linux 环境中的存储/写入方式以及它们在 Windows 中的读取方式有关？感谢您的帮助。

【问题讨论】：

标签： java windows linux byte inflate

【解决方案1】：

我怀疑两个系统的默认编码不同。

// on the linux box   
byte [] blob = str.getBytes("UTF-8");

// in your code 
String str = new String(blob, "UTF-8");

或者至少找出 linux 机器上的默认编码是什么（普通 UTF-8）并跳过第 1 步。

Joel on software 上有一个很好的例子说明这里可能发生的事情

【讨论】：

是的，就是这样，它的编码方式不同。感谢您的回答。使用 new String(byte[], "UTF-8") 解决了这个问题。今晚我会读那篇文章——看起来里面有很多很好的信息。太糟糕了，因为我还没有足够的声誉，所以我无法投票赞成这个答案。
您可以对自己的问题进行投票（我认为），您也可以单击那个大勾号将此答案标记为已接受的答案。 Joels artical 是全金，基本上是必读。
请注意，有很多字节序列无法使用 UTF-8 字符编码解码为字符。最好使用 US-ASCII 进行直接的一对一映射。或者...不要使用 String 作为字节的持有者
公认的 UTF-8 可能不是在每种情况下最合适的编码，但如果您将字符串转换为字节数组，我强烈建议不要使用 US-ASCII，除非您确定字符串字符串不包含任何超过 128 标记的字符。请注意，对于这样的字符串，UTF-8 输出无论如何都是相同的。
取决于原始数据是否为字符串。如果您从 byte[] 开始（例如 JPG 或其他），请不要靠近字符串，或者，如果必须，请使用 ISO-8859-1（我不是真的指上面的 US-ASCII - 你'是的，这是一个 7 位字符集）。如果您从 String 开始并尝试通过 byte[]，则使用 UTF-8。

【解决方案2】：

String 不是字节的一般持有者。毫无疑问，您的 db2/Linux 环境和 Windows 环境之间会有不同的默认字符编码，这将导致字节和字符之间的来回转换不同。

【讨论】：