sirve scanner que para nextint example java file-io java.util.scanner

scanner - Escáner Java no pasa por todo el archivo



scanner java int (8)

Estoy escribiendo un programa en Java y una de las cosas que debo hacer es crear un conjunto de cada ubicación válida para un problema de ruta más corta. Las ubicaciones se definen en un archivo .txt que sigue un patrón estricto (una entrada por línea, sin espacios en blanco adicionales) y es perfecto para usar .nextLine para obtener los datos. Mi problema es que 241 líneas en el archivo (de 432) el escáner deja de funcionar 3/4 del camino a través de una entrada y no reconoce ninguna línea nueva.

Mi código:

//initialize state space private static Set<String> posible(String posLoc) throws FileNotFoundException { Scanner s = new Scanner(new File(posLoc)); Set<String> result = new TreeSet<String>(); String availalbe; while(s.hasNextLine()) { availalbe = s.nextLine(); result.add(availalbe); } s.close(); return result; }

Los datos

Shenlong Gundam Altron Gundam Tallgee[scanner stops reading here]se Tallgeese II Leo (Ground) Leo (Space)

Por supuesto, "el escáner deja de leer aquí" no está en los datos, solo estoy marcando donde el escáner deja de leer el archivo. Esto es 3068 bytes en el archivo, pero eso no debería afectar a nada porque en el mismo programa, con un código casi idéntico, estoy leyendo un archivo .txt de 261 líneas y 14 KB que codifica las rutas. Cualquier ayuda sería apreciada.

Gracias.


Deberías usar esto:

Escáner escáner = nuevo Escáner (fileObj) .useDelimiter ("/ z");
System.out.println (scanner.next ());


Encontré el mismo problema y esto es lo que hice para solucionarlo:

1.Saved the file I was reading from into UTF-8 2.Created new Scanner like below, specifying the encoding type: Scanner scanner = new Scanner(new File("C:/IDSBRIEF/GuidData/"+sFileName),"UTF-8");


Estaba teniendo el mismo problema. El escáner no lee hasta el final de un archivo, en realidad se detiene justo en el medio de una palabra. Pensé que era un problema con algún límite establecido en el escáner, pero tomé nota del comentario de rfeak sobre la codificación de caracteres.

Volví a guardar el .txt que estaba leyendo en UTF-8 , resolvió el problema. Resulta que el Bloc de notas había predeterminado a ANSI.


Hay un problema con el escáner que lee tu archivo pero no estoy seguro de qué es. Cree erróneamente que ha llegado al final del archivo cuando no lo ha hecho, posiblemente debido a algún tipo de codificación String. Intente usar un objeto BufferedReader que envuelva un objeto FileReader en su lugar.

p.ej,

private static Set<String> posible2(String posLoc) { Set<String> result = new TreeSet<String>(); BufferedReader br = null; try { br = new BufferedReader(new FileReader(new File(posLoc))); String availalbe; while((availalbe = br.readLine()) != null) { result.add(availalbe); } } catch (FileNotFoundException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } finally { if (br != null) { try { br.close(); } catch (IOException e) { e.printStackTrace(); } } } return result; }

Editar
Intenté reducir su problema al mínimo, y solo esto fue suficiente para provocar el problema:

public static void main(String[] args) { try { Scanner scanner = new Scanner(new File(FILE_POS)); int count = 0; while (scanner.hasNextLine()) { String line = scanner.nextLine(); System.out.printf("%3d: %s %n", count, line ); count++; }

Revisé el objeto Scanner con un printf:

System.out.printf("Str: %-35s size%5d; Has next line? %b%n", availalbe, result.size(), s.hasNextLine());

Y demostró que pensaba que el archivo había terminado. Estaba en el proceso de eliminar progresivamente las líneas de los datos al archivo para ver qué líneas causaron el problema, pero se lo dejaré a usted.


Mi caso:

  • en mi programa principal (A) siempre lee 16384 bytes de un archivo de 41021 bytes. El carácter en el que se detiene está en el medio de una línea con texto de impresión normal
  • Si creo un pequeño programa separado (B) solo con el escáner e imprimí líneas, se lee el archivo completo.
  • especificando "UTF-8" en (A) todavía lee 16384
  • especificando "ASCII" en (A) todavía lee 16384
  • especificando "Cp1252" en (A) lee todo el archivo
  • los usuarios envían mis archivos de entrada de texto y no puedo estar seguro de que los escribirán en cualquier codificación particular

Conclusiones

  • El escáner parece leer el archivo bloque por bloque y escribe los datos correctamente leídos en la cadena de retorno, pero cuando encuentra un bloque con una codificación diferente de la que espera, sale silenciosamente (ouch) y devuelve la cadena parcial
  • el archivo txt que trato de leer es Cp1252, mi (A) archivo fuente es UTF-8 y mi (B) archivo fuente es Cp1252, por eso (B) funcionó sin especificar una codificación

Solución

  • olvidarse de escáner y usar

String fullFileContents = new String(Files.readAllBytes(myFile.toPath()));

Por supuesto, los caracteres que no son ascii no se pueden leer de manera confiable, ya que no se conoce la codificación, pero los caracteres ascii se leerán con seguridad. Úselo si solo necesita los caracteres ascii en el archivo y la parte que no es ascii se puede descartar.


También tuve un problema similar en mi servidor Linux y, finalmente, el código debajo del que funcionaba para mí.

Escáner escáner = nuevo Escáner (nuevo archivo (nombre de archivo), "UTF-8");


Tuve el mismo problema con un archivo csv: funcionó en Windows pero no funcionó en Linux

Abra el archivo con nodepad ++ y cambie la codificación, elija: Codificar en UTF8 (con BOM). Se solucionó el problema en mi caso.


Tuve un archivo txt en el que Scanner dejó de leer en la línea 862, fue un problema extraño. Lo que hice fue crear un archivo diferente (para intentar replicar el problema). Lo agregué menos de 862 líneas primero, luego agregué más de 862 y funcionó bien.

Así que creo que el problema fue que en mi archivo anterior, en la línea 862, había algo mal, como algún personaje o símbolo que podría haber confundido a Scanner para terminar de leer antes.

En conclusión: en base a esta experiencia, recomiendo encontrar la línea exacta donde el escáner deja de leer para encontrar una solución para los problemas.