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

голоса
5

Я в настоящее время использую следующую функцию, чтобы сделать простой 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в этом случае?

Задан 28/08/2008 в 01:07
источник пользователем
На других языках...                            


4 ответов

голоса
4

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

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

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

    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 / наконец блоков.

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

Ответил 28/08/2008 в 16:03
источник пользователем

голоса
1

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

Ответил 18/01/2010 в 18:11
источник пользователем

голоса
1

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

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

Ответил 28/08/2008 в 01:16
источник пользователем

голоса
0

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

Ответил 28/08/2008 в 01:18
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more