NumberFormatException in erster Zeile

[mwanaheri]

Ich habe hier ein etwas eigenartiges Problem beim Auslesen einer Datei.
Die Datei enthält eine Tabell, die mit Tabulatoren getrennt ist. Jede Zeile wird in ein StringArray gesplittet

zeile = dieZeile.split("\t");
, anschließend wird die erste "Spalte", die immer eine Zahl enthält, in ein Integer umgewandelt mit

patient.setEnummer(new Integer(Integer.parseInt(zeile[0].toString().trim())));
(ich brauche das als Integer, um in der Datenbank nicht 0 eintragen zu müssen, sondern auch null haben zu können). Dabei tritt nun das Problem auf, dass immer in der ersten Zeile eine NumberFormatException ausgelöst wird, ohnde dass ich begreife, warum. Was da steht ist eindeutig eine Zahl. Stelle ich die Zeilen um, habe ich das gleiche Problem wiederum bei der ersten Zeile, während die vorherige erste Zeile nun problemlos verarbeitet wird. Es kann also nicht am String liegen, sondern muss an der Tatsache liegen, dass die erste Zeile verarbeitet wird. Hat jemand eine Idee, wo ich den ver**** Fehler gemacht haben könnte?

[michael.becker]

wäre ganz gut, wenn du einen auszug(am besten die ersten 10 zeilen) der datei, die du ausliesst hier posten würdest

[mwanaheri]

Einen Auszug aus der Originaldatei kann ich leider nicht anhängen (vertrauliche Daten), aber ich habe ein kleines Demo gebaut, in dem ich das Problem nachvollziehen konnte. Ich habe die java- und die txt-Datei in ein zip gepackt und angehängt (766 byte).
Beim Nachbauen ist mir aufgefallen, dass das Problem nicht auftritt, wenn die Datei 8-bit kodiert ist, wohl aber, wenn sie (wie die vorliegende) in utf8 kodiert ist. Die Originaldatei ist eine 8mb große kommaseparierte Datei und enthält einige Sonderzeichen, so dass ich sie möglichst nicht weiter anfassen möchte.

[anda_skoa]

Das Testprogramm funktioniert korrekt soweit ich das beurteilen kann.

Es hat in der ersten Zeile, wo im ersten "Feld" neben der Zahl auch noch andere Zeichen stehen, korrekterweise eine Parser Expection und parsed die anderen korrekten Zeilen einwandfrei.

Ciao,
_

[mwanaheri]

Falls du mit den 'anderen Zeichen' die Leerzeichen hinter der Zahl meinst, so kann ich sagen, dass es an denen nicht liegt (werden per .trim() abgetrennt). Die sind des Realismusses halber drin -- die Originaldatei ist voll davon.
Bei der Ausgabe fällt mir aber auf, dass das Zeichen, das vor dem entsprechenden Abschnitt ausgegeben wird, umrahmt ist. Es scheint also eine Art Zeichen vor dem Text vorhanden zu sein -- aber nur in der utf8-Version. In der Kommandozeile mit less ausgegeben beginnt die Datei stets mit der Folge
357273277 -- schwarz hinterlegt.
Das bleibt so, auch wenn ich die Zeilen umstelle. Lege ich eine neue Datei an, ist es dasselbe, wenn es eine utf-8-Datei ist. Also muss es etwas mit der Kodierung zu tun haben. Aber wie umschiffe ich diese Klippe beim Parsen?

[anda_skoa]

Die Datei, die du in deinem Testprogramm mitgeliefert hast, fängt in der ersten Zeile nicht mit einer Zahl an, sondern mit irgendwelchen anderen Zeichen.

Wenn du dir die Exception ausgeben läßt, siehst du auch, daß bereits beim ersten Zeichen die Exception geworfen wird.

Wenn das in deiner echten Datei anders ist, solltest du vielleicht ein entsprechendes Beispiel posten, denn mit der derzeitigen Testdaten Datei ist kein Fehler reproduzierbar sondern nur korrektes Verhalten beim Parsen von Zeichen die keine Ziffern sind.

Ciao,
_

[mwanaheri]

Das ist leider bei der echten Datei auch so. Und bei jeder anderen, die in utf-8 angelegt ist. Im Editor -- sowohl SciTE als auch vim -- ist da aber nix, das man löschen könnte. Es scheint sich also um eine Eigenheit von utf-8 zu handeln. Die Frage ist nun: Wie umgehe ich so was in Zukunft am besten. Hattest du noch nie Problemen mit utf-8?

[anda_skoa]

Spitze, d.h. das erstellende Programm produziert in der ersten Zeile einen Fehler.
:eek:

Ist echt verwunderlich daß es so schwer sein soll, wie bei jeder anderen Zeile auch mit einer Zahl statt irgendwelchen Steuerzeichen zu beginnen.

Vielleicht ist es immer nur ein Zeichen, bzw eine fixe, gleichbleibende Anzahl die du überspringen könntest um den Fehler des Produzenten zu korrigieren?

Ciao,
_

[mwanaheri]

Tja, da bin ich wohl meinem Gegentest aufgesessen. Dummerweise macht nämlich SciTE den gleichen Fehler und beginnt jede utf8-Datei mit EF BB BF. Und an die kommt man nur mit einem hex-editor ran. Nimmt man einen anderen und stellt die Zeilen um, so bleiben diese drei Zeichen da wo sie waren, so dass dann der Fehler in einer anderen Zeile -- eben immer der ersten -- auftreten. Na immerhin weiß ich jetzt, was ich umschiffen muss:rolleyes: .
Dabei ist SciTE sonst so ein guter Editor...

Vielen Dank
Mwanaheri