讀取所有字符時，是否有理由在InputStreamReader上使用BufferedReader？

Question

我目前使用以下功能來執行簡單的HTTP GET。

public static String download(String url) throws java.io.IOException {
    java.io.InputStream s = null;
    java.io.InputStreamReader r = null;
    //java.io.BufferedReader b = null;
    StringBuilder content = new StringBuilder();
    try {
        s = (java.io.InputStream)new URL(url).getContent();

        r = new java.io.InputStreamReader(s);
        //b = new java.io.BufferedReader(r);

        char[] buffer = new char[4*1024];
        int n = 0;
        while (n >= 0) {
            n = r.read(buffer, 0, buffer.length);
            if (n > 0) {
                content.append(buffer, 0, n);
            }
        }
    }
    finally {
        //if (b != null) b.close();
        if (r != null) r.close();
        if (s != null) s.close();
    }
    return content.toString();
}

我沒有理由使用BufferedReader因為我BufferedReader順序下載所有內容。 我是否認為在這種情況下BufferedReader沒有用？

Answer 1

在這種情況下，我將按照您的方式做（使用字節數組進行緩沖，而不要使用流緩沖區之一）。

但是也有例外。 Servlet API中是您看到緩沖區（這次輸出）的一個地方。 在調用flush（）之前，不會將數據寫入底層流，這使您可以緩沖輸出，但是如果發生錯誤，則轉儲緩沖區，而改寫錯誤頁面。 如果需要使用mark（int）和reset（）重置流以進行重新讀取，則可以緩沖輸入。 例如，在決定將流傳遞到哪個內容處理程序之前，您可能會檢查文件頭。

無關，但我認為您應該重寫流處理。 此模式最能避免資源泄漏：

    InputStream stream = new FileInputStream("in");
    try { //no operations between open stream and try block
        //work
    } finally { //do nothing but close this one stream in the finally
        stream.close();
    }

如果要打開多個流，請嵌套try / finally塊。

您的代碼正在做的另一件事是假設返回的內容已編碼為VM的默認字符集（盡管根據使用情況這可能就足夠了）。

Answer 2

InputStreamReader的read（）方法之一的每次調用都可能導致從基礎字節輸入流中讀取一個或多個字節。 為了實現字節到字符的有效轉換，與滿足當前讀取操作所需的字節數相比，可以從基礎流中提前讀取更多字節。

Answer 3

沒錯，如果您使用BufferedReader讀取HTTP內容和標頭，則需要InputStreamReader以便逐字節讀取字節。

在這種情況下，BufferedReader有時會做一些奇怪的事情……尤其是在讀取HTTP POST標頭時，有時您將無法讀取POST數據，如果使用InputStreamReader，則可以讀取內容長度並讀取那么多字節。 。

Answer 4

我的直覺告訴我，由於您已經在使用字節數組執行緩沖，因此使用BufferedReader是多余的。