¿Existe alguna razón para utilizar BufferedReader en lugar de InputStreamReader al leer todos los caracteres?

Question

Actualmente utilizo la siguiente función para realizar un HTTP GET simple.

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

No veo ninguna razón para usar el BufferedReader ya que solo voy a descargar todo en secuencia.¿Estoy en lo cierto al pensar que no sirve de nada BufferedReader ¿en este caso?

Answer 1

En este caso, haría lo que usted está haciendo (usar una matriz de bytes para el almacenamiento en búfer y no uno de los búferes de flujo).

Sin embargo, hay excepciones.Un lugar donde ve los buffers (salida esta vez) es en la API del servlet.Los datos no se escriben en la secuencia subyacente hasta enjuagar() se llama, lo que le permite almacenar en el búfer la salida, pero luego volcar el búfer si se produce un error y escribir una página de error en su lugar.Puede almacenar en búfer la entrada si necesita restablecer la transmisión para volver a leerla usando marca(int) y reiniciar().Por ejemplo, tal vez debería inspeccionar el encabezado del archivo antes de decidir a qué controlador de contenido pasar la transmisión.

No está relacionado, pero creo que deberías reescribir el manejo de tu transmisión.Este patrón funciona mejor para evitar fugas de recursos:

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

Si está abriendo varias transmisiones, anide los bloques try/finally.

Otra cosa que hace su código es asumir que el contenido devuelto está codificado en el conjunto de caracteres predeterminado de su VM (aunque eso podría ser adecuado, según el caso de uso).

Answer 2

Tiene razón, si usa BufferedReader para leer contenido y encabezados HTTP, necesitará InputStreamReader para poder leer byte por byte.

BufferedReader en este escenario a veces hace cosas raras... especialmente cuando se trata de leer encabezados HTTP POST, a veces no podrás leer los datos POST, si usas InputStreamReader puedes leer la longitud del contenido y leer esa cantidad de bytes. .

Answer 3

Cada invocación de uno de un Lector de flujo de entradaLos métodos read() pueden hacer que se lean uno o más bytes del flujo de entrada de bytes subyacente.Para permitir la conversión eficiente de bytes a caracteres, se pueden leer más bytes del flujo subyacente de los necesarios para satisfacer la operación de lectura actual.

Answer 4

Mi instinto me dice que dado que ya estás realizando el almacenamiento en búfer usando la matriz de bytes, es redundante usar BufferedReader.