以大量 nul 字符结尾的 StringBuilder

Question

我在调试我正在构建的应用程序的问题时遇到了非常困难的时间。我似乎无法用具有相同问题的代表性测试程序来重现问题本身，这使得演示变得困难。不幸的是，由于安全原因，我无法分享我的实际源代码，但是，以下测试很好地代表了我正在做的事情，文件和数据是 unix 样式 EOL，使用 PrintWriter 写入 zip 文件，以及 StringBuilders 的使用：

public class Tester {

    public static void main(String[] args) {
        // variables
        File target = new File("TESTSAVE.zip");
        PrintWriter printout1;
        ZipOutputStream zipStream;
        ZipEntry ent1;
        StringBuilder testtext1 = new StringBuilder();
        StringBuilder replacetext = new StringBuilder();
        // ensure file replace
        if (target.exists()) {
            target.delete();
        }
        try {
            // open the streams
            zipStream = new ZipOutputStream(new FileOutputStream(target, true));
            printout1 = new PrintWriter(zipStream);
            ent1 = new ZipEntry("testfile.txt");
            zipStream.putNextEntry(ent1);

            // construct the data
            for (int i = 0; i < 30; i++) {
            testtext1.append("Testing 1 2 3 Many! \n");
            }
            replacetext.append("Testing 4 5 6 LOTS! \n");
            replacetext.append("Testing 4 5 6 LOTS! \n");

            // the replace operation
            testtext1.replace(21, 42, replacetext.toString());

            // write it
            printout1 = new PrintWriter(zipStream);
            printout1.println(testtext1);
            // save it
            printout1.flush();
            zipStream.closeEntry();
            printout1.close();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

问题的核心是我在我身边看到的文件正在生成一个 16.3k 字符的文件。我的朋友，无论他在电脑上使用该应用程序，还是与我查看完全相同的文件，都会看到一个包含 19.999k 个字符的文件，其中额外的字符是 CRLF 后跟大量空字符。无论我使用什么应用程序、编码或视图，我都看不到这些 nul 字符，我只在最后一行看到一个 LF，但我确实看到了一个 20k 的文件。在所有情况下，即使两台计算机都是 Windows 计算机并且都使用相同的编辑软件来查看，但两台计算机上完全相同的文件所看到的内容之间还是存在差异。

我还无法使用任何数量的虚拟程序重现这种行为。不过，我已经能够将最后一行的杂散 CRLF 追溯到我在 PrintWriter 上使用 println 的情况。当我用 print(s + '\n') 替换 println(s) 时，问题似乎消失了（文件大小为 16.3k）。但是，当我将程序返回到 println(s) 时，问题似乎没有返回。我目前正在由法国的一位朋友验证文件，看看问题是否真的消失了（因为我看不到nul，但他可以），但这种行为已经彻底混淆了。

我还注意到 StringBuilder 的替换函数声明“如果需要，该序列将被延长以容纳指定的字符串”。鉴于 stringbuilders setLength 函数用 nul 字符填充，并且 EnsureCapacity 函数将容量设置为输入或 (currentCapacity*2)+2 中的较大者，我怀疑某处存在关系。然而，当我用这个想法进行测试时，我只有一次能够得到代表我所看到的结果，并且从那以后就无法重现它。

有谁知道可能导致此错误的原因，或者至少对进行测试的方向有建议？

由于评论部分对我来说已损坏，因此进行编辑： 需要澄清的是，无论操作系统如何，输出都需要采用 unix 格式，因此直接使用 '\n' 而不是通过格式化程序。插入的原始 StringBuilder 实际上不是为我生成的，而是程序读取的文件的内容。我很高兴阅读过程有效，因为其中的信息在整个应用程序中被大量使用。我也做了一些探测，发现在保存之前，缓冲区是正确的容量，并且调用 toString() 时的输出是正确的长度（即它不包含空字符，长度为 16,363，而不是 19,999 ）。这会将错误原因置于生成字符串和保存 zip 文件之间。

Answer 1

终于找到原因了。设法重现该问题几次，并将原因追溯到代码的输入侧，而不是输出侧。我的文件读取功能本质上是这样的：

char[] buf;
int charcount = 0;
StringBuilder line = new StringBuilder(2048);
InputStreamReader reader = new InputStreamReader(stream);// provides a line-wise read
BufferedReader file = new BufferedReader(reader);
do { // capture loop
    try {
    buf = new char[2048];
    charcount = file.read(buf, 0, 2048);
    } catch (IOException e) {
    return null; // unknown IO error
    }
    line.append(buf);
} while (charcount != -1);
// close and output

问题是附加一个未满的缓冲区，因此后面的值仍为其初始值 null。我无法重现它的原因是因为有些数据很好地填充了缓冲区，有些则没有。

为什么我似乎无法在文本编辑器上查看问题，我仍然不知道，但我现在应该能够解决这个问题。欢迎任何有关最佳方法的建议，因为这是我的长期实用程序库之一的一部分，我希望使其尽可能通用和优化。