2016-09-26 6 views
25

Also, ich habe ein Problem, das mich wirklich stört. Ich habe einen einfachen Parser, den ich in Java gemacht habe. Hier ist das Stück einer entsprechenden Code:java.lang.NumberFormatException für Eingabezeichenfolge "1"

while((line = br.readLine())!=null) 
{ 
    String splitted[] = line.split(SPLITTER); 
    int docNum = Integer.parseInt(splitted[0].trim()); 
    //do something 
} 

Eingabedatei CSV-Datei, der erste Eintrag der Datei eine ganze Zahl ist. Wenn ich das Parsen beginnen, ich immidiately diese Ausnahme erhalten:

Exception in thread "main" java.lang.NumberFormatException: For input string: "1" 
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 
at java.lang.Integer.parseInt(Integer.java:580) 
at java.lang.Integer.parseInt(Integer.java:615) 
at dipl.parser.TableParser.parse(TableParser.java:50) 
at dipl.parser.DocumentParser.main(DocumentParser.java:87) 

überprüfte ich die Datei, hat es in der Tat 1 als erster Wert (keine andere Zeichen in diesem Feld sind), aber ich habe immer noch die Nachricht. Ich denke, dass es wegen der Dateicodierung sein kann: Es ist UTF-8, mit Unix-Endzeilen. Und das Programm läuft unter Ubuntu 14.04. Irgendwelche Vorschläge, um nach dem Problem zu suchen, sind willkommen.

+9

Schöne mit Kopieren und Einfügen, um den Fehler in der Frage zu setzen! –

Antwort

35

Sie haben eine BOM vor dieser Nummer; Wenn ich was wie "1" in Ihre Frage kopieren und in vim einfügen, sehe ich, dass Sie eine FE FF (z. B. eine BOM) davor haben. Von diesem Link:

Die genauen Bytes, aus denen die Stückliste besteht, werden unabhängig vom Unicode-Zeichen U + FEFF in das Transformationsformat konvertiert.

Also das ist das Problem, verbrauchen Sie die Datei mit dem entsprechenden Lesegerät für die Transformation (UTF-8, UTF-16 Big-Endian, UTF-16 Little-Endian, etc.) die Datei mit codiert. Weitere Informationen zum Lesen von Unicode-Dateien in Java finden Sie in this question and its answers.

+1

@Doval: ** Danke, ** Ich war absolut falsch zu sagen, es war eine UTF-8 BOM, und Sie haben Recht, dass die BOM für UTF-8 on-the-Wire ist EF BB BF. Aber was wir sehen, ist das * Endergebnis * des Lesens der Datei und dann das Sehen der Ausgabe in der Fehlermeldung. Die Datei kann sich in einer beliebigen Transformation befinden. Alle BOMs sind FE FF * einmal gelesen *. –

+0

Aber wenn es * roh * gelesen wurde, dann ... oh, ich weiß es nicht. :-) Könnte gut UTF-16 gewesen sein. :-) Es hängt alles davon ab, wie die Datei in den Stream eingelesen wurde. –

+1

"alle Stücklisten werden nach dem Lesen FE FF" - Nicht ganz. Alle BOMs sind U + FEFF (was nicht dasselbe ist wie 0xFE 0xFF, da es sich um einen Codepunkt und nicht um eine Bytefolge handelt), sobald * decodiert *. Vor der Dekodierung haben Sie nur noch Bytes, die in jeder Kodierung vorkommen können, die Unicode-Zeichen darstellen kann (meistens UTF-8 und UTF-16, aber andere existieren). – Kevin

Verwandte Themen