java - teclado - ¿Por qué la clase Scanner no tiene un método nextChar?

scanner java int

Question

Esto es realmente una curiosidad más que un problema ...

¿Por qué la clase Scanner no tiene un método nextChar() ? Parece que debería ser así cuando se tiene en cuenta el hecho de que tiene el método next , nextInt , nextLine , etc.

Me doy cuenta de que simplemente puede hacer lo siguiente:

userChar = in.next().charAt(0);
System.out.println( userChar  );

Pero ¿por qué no tener un método nextChar() ?

Answer 1

La razón es que la clase de escáner está diseñada para leer en tokens separados por espacios en blanco. Es una clase de conveniencia que envuelve un flujo de entrada subyacente. Antes del escáner, todo lo que podía hacer era leer en bytes individuales, y eso es un gran problema si quiere leer palabras o líneas. Con Scanner pasa en System.in, y realiza una serie de operaciones de lectura () para tokenizar la entrada por usted. Leer un solo personaje es una operación más básica. Source

Puede usar (char) System.in.read(); .

Answer 2

De acuerdo con el javadoc un Scanner no parece estar destinado a leer caracteres individuales . Adjunta un Scanner a un InputStream (u otra cosa) y analiza la entrada por usted. También puede despojar a los personajes no deseados. Entonces puede leer números, líneas, etc. fácilmente. Cuando solo necesita los caracteres de su entrada, use un InputStreamReader por ejemplo.

Answer 3

La clase Scanner se basa en la lógica implementada en el método String next(Pattern) . El método API adicional como nextDouble() o nextFloat() . Proporcione el patrón adentro.

Entonces la javadoc clase javadoc :

Un simple escáner de texto que puede analizar tipos primitivos y cadenas utilizando expresiones regulares.

Un escáner divide su entrada en tokens usando un patrón de delimitador, que por defecto coincide con el espacio en blanco. Los tokens resultantes se pueden convertir en valores de diferentes tipos utilizando los diversos métodos siguientes.

Por la descripción, puede ser triste que alguien se haya olvidado de los caracteres porque es un tipo primitivo.

Pero el concepto de clase es encontrar patrones, un char no tiene patrón es solo el siguiente personaje. Y esta lógica en mi humilde opinión hizo que nextChar no se haya implementado.

Si necesita leer un char por char, puede usar una clase más eficiente.

Answer 4

Me imagino que tiene que ver con la codificación. Un char es de 16 bytes y algunas codificaciones utilizarán un byte para un personaje, mientras que otro usará dos o más. Cuando se diseñó originalmente Java, supusieron que cualquier carácter Unicode cabría en 2 bytes, mientras que ahora un carácter Unicode puede requerir hasta 4 bytes (UTF-32). No hay forma de que Scanner represente un punto de código UTF-32 en un solo char .

Puede especificar una codificación en Scanner cuando construye una instancia, y si no se proporciona, usará el conjunto de caracteres de la plataforma. Pero esto todavía no soluciona el problema con los caracteres Unicode de 3 o 4 bytes, ya que no se pueden representar como una única primitiva de caracteres (ya que el char es de solo 16 bytes). Entonces terminarías obteniendo resultados inconsistentes.

Answer 5

Para obtener una razón definitiva, debe preguntarle al diseñador (es) de esa API.

Pero una posible razón es que el intento de un nextChar (hipotético) no encajaría muy bien en el modelo de escaneo.

• Si nextChar() comportó como read() en un Reader y simplemente devolvió el siguiente carácter no consumido del escáner, entonces se comporta de manera incoherente con los otros métodos next<Type> . Omiten los caracteres delimitadores antes de intentar analizar un valor.

• Si nextChar() comporta como (por ejemplo) nextInt entonces:

  • el salto del delimitador sería "inesperado" para algunas personas, y

  • existe la cuestión de si debe aceptar un solo carácter "en bruto", o una secuencia de dígitos que son la representación numérica de un char , o tal vez incluso soportar el escape o algo así ¹ .

No importa qué elección hicieron, algunas personas no serían felices. Mi suposición es que los diseñadores decidieron mantenerse lejos del tarpit.

^{1 - Votaría con fuerza por el enfoque de los caracteres crudos ... pero el punto es que hay alternativas que deben analizarse, etc.}