Есть ли причина использовать BufferedReader вместо InputStreamReader при чтении всех символов?

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 в данном случае?

Answer 1

В этом случае я бы поступил так, как делаете вы (использовал массив байтов для буферизации, а не один из потоковых буферов).

Однако есть исключения.Единственное место, где вы видите буферы (на этот раз выходные), находится в servlet API.Данные не записываются в базовый поток до тех пор, пока промывка() вызывается, позволяя вам буферизировать выходные данные, но затем сбрасывать буфер, если возникает ошибка, и вместо этого записывать страницу ошибки.Вы могли бы буферизировать входные данные, если вам нужно было сбросить поток для повторного чтения с помощью знак (int) и сброс ().Например, возможно, вы бы проверили заголовок файла, прежде чем принимать решение о том, какому обработчику содержимого передавать поток.

Не связано, но я думаю, вам следует переписать свою обработку потока.Этот шаблон работает лучше всего, чтобы избежать утечки ресурсов:

    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();
    }

Если вы открываете несколько потоков, nest блокирует try/finally.

Еще одна вещь, которую делает ваш код, - это предположение, что возвращаемое содержимое закодировано в наборе символов вашей виртуальной машины по умолчанию (хотя этого может быть достаточно, в зависимости от варианта использования).

Answer 2

Вы правы, если вы используете BufferedReader для чтения содержимого HTTP и заголовков, вам понадобится InputStreamReader, чтобы вы могли читать байт за байтом.

BufferedReader в этом сценарии иногда делает странные вещи ... особенно когда дело доходит до чтения заголовков HTTP POST, иногда вы не сможете прочитать данные POST, если вы используете InputStreamReader, вы можете прочитать длину содержимого и прочитать столько байтов...

Answer 3

Каждый вызов одного из InputStreamReader ( Входной поток чтения)методы read() могут привести к считыванию одного или нескольких байтов из базового потока байтового ввода.Чтобы обеспечить эффективное преобразование байтов в символы, из базового потока может быть прочитано больше байтов, чем необходимо для выполнения текущей операции чтения.

Answer 4

Моя интуиция подсказывает мне, что, поскольку вы уже выполняете буферизацию с помощью массива байтов, использование BufferedReader излишне.