Java Korrektes auswerten von Zeichen aus TXTs?

[ooAlbert]

Hi,

ich hab eine Frage zum Auswerten von Textdateien mit Java.
Ich hab hier nämlich einen Datenlogger der eine Serielle Schnittstelle bedient und die daten als TXT ablegt. Normal stehen da einfach nur zeilenweise bestimmte zahlenwerte drin die mir das Java Programm auswerten soll. Die zeilen sind normal immer gleich lang.

Jetzt mußte ich mit der anwendung auf ein anderes system umziehen und plötzlich hab ich keinen korrekten zeilenumbruch mehr in der TXT wenn ich die im editor öffne im wordpad hab ich ihn aber. Die einstellungen der COM schnittstelle etc sind aber identisch. Ich kann aber auch keine aussage darüber treffen wie die TXT kodiert ist da der datenlogger etwas spartanisch ist.

die anwendung hat bis jetzt noch nicht gemurrt das was "falsch" wäre aber ich bin mir unsicher deswegen.
Der zeilenumbruch ist in der TXT zu sehen als Kästchen ich glaub das ist auch das korrekte steuerzeichen dafür, seh ich aber nur im editor.

Kann da wer eine aussage machen der sich etwas mit den internas von java auskennt ob java den zeilenumbruch korrekt sehen wird oder nicht? eingelesen wird es mit dem üblichen bufferedreader ohne spezielle parameter.

[Der_Donnervogel]

Ich könnte mir vorstellen, dass es mit der Codierung von Zeilenumbrüchen zu tun hat. Es gibt ja die Variante CR+LF (DOS) und die mit nur LF (Unix). Mit folgender Funktion kann man zusätzlich zum Text auch noch den Asciiwert des Zeichens sehen.
public void test(String name) {
try {
InputStream in = new FileInputStream(name);
int rd;
while ((rd = in.read()) != -1) {
System.out.println(rd + ": #" + (char)rd + "#");
}
} catch (Exception e) {
e.printStackTrace();
}
}
Je nach Codierung kann dann etwas in der Art rauskommen, wobei ein CR den Wert 13 hat und das LF den Wert 10:
84: #T#
101: #e#
115: #s#
116: #t#
13: #
#
10: #
#
116: #t#
oder
84: #T#
101: #e#
115: #s#
116: #t#
10: #
#
116: #t#
Falls sich die alten von den neuen Dateien dann wirklich nur in der Codierung des Zeilenumbruchs unterscheiden sollten, kann man die schnell umcodieren.

Ansonsten sollte man das Kästchen auch identifizieren können und anhand des ASCII Wertes im Internet recherchieren können, um was für ein Zeichen es sich handelt.

[Köppchen]

Hallo Albert,
das hört sich wirklich so an wäre deine Datei Unixartig kodiert.
Notepad zeigt bei solchen Dateien alles in einer Zeile an. Wordpad dagegen bricht richtig um (es reicht das Unix LF).
Donnervogel hat dir ja schon geschrieben wie du das prüfen kannst. Er hat auch gleich ein Windows/Dos beispiel mitgeschrieben (Datei hat 0D/0A resp. dezimal 13/10 oder CR/LF am Zeilenende).
Ich schreibe zum ansehen von Dateien allerdings normalerweise keine eigenen Programme, sondern sehe mir Dateien mit einem Editor (z.B. Pspad unter Windows, oder VI Win und Unix) an. Programmier Editoren kennen üblicherweise einen Hex Mode.

Gruß Markus

[Der_Donnervogel]

Ich schreibe zum ansehen von Dateien allerdings normalerweise keine eigenen Programme, sondern sehe mir Dateien mit einem Editor (z.B. Pspad unter Windows, oder VI Win und Unix) an. Programmier Editoren kennen üblicherweise einen Hex Mode.
Ich normalerweise auch nicht ;)

Allerdings will er die Daten sowieso in Java weiterverarbeiten und nicht im Hexeditor. Deshalb hab ich kurz gezeigt, wie man das in Java feststellen kann. Java kann beim Texte lesen/schreiben durchaus Ärger machen, wenn man nicht weiß was da passiert. Beispielsweise wenn man es mal mit einem abweichenden charset zu tun hat. Ich hab zB nicht sofort rausgefunden, dass der Konstruktor von String so überladen ist, dass man damit zwischen verschiedenen charsets konvertieren kann (US-ASCII, ISO-8859-1 und verschiedene UTF-8-Varianten) sondern erst mal die ganzen Streamklassen abgeklappert.

[Gast]

Kann da wer eine aussage machen der sich etwas mit den internas von java auskennt ob java den zeilenumbruch korrekt sehen wird oder nicht? eingelesen wird es mit dem üblichen bufferedreader ohne spezielle parameter.Wenn du das ganze per readline einliest, bekommst dui keine Probleme:
"A line is considered to be terminated by any one of a line feed ('\n'), a carriage return ('\r'), or a carriage return followed immediately by a linefeed." (doc (http://java.sun.com/javase/6/docs/api/java/io/BufferedReader.html#readLine()))
Also ist egal, ob *ix: Line Feed, Mac: Carriage Return oder Windows: beide Zeichen (Carriage Return und Linefeed) als System genutzt wird.

hth, mfg