Datei konvertieren - aber wie Dateiformat einlesen

[Guest]

Hallo,

habe zwar schon einmal eine kleinere Applikation mit JAVA geschrieben, bin aber trotzdem Anfänger. Aber gerade mein erstes Programm spornt mich an weiter zu machen.

Wir haben ein Messgerät dessen Daten wir gern als CSV hätten. Dies geht zwar auch vom Originalprogramm aus, aber nur sehr umständlich und z.B. ohne batch-Modus.

Ich möchte nun gern ein Konvertierungsprogramm schreiben um folgende Datei in ein CSV Format zu konvertieren:
http://www.uni-leipzig.de/~pflaphys/tmp/ Es ist dort die Datei RESP.DAT.

Im HEX Editor erkennt man zuerst ein paar Zeichen (z.B. Messzeitpunkt u.s.w.) dann wird es jedoch "kyrillisch". Diese Zeichen müssten eigentlich nichts anderes als X/Y-Werte sein. Ich habe keine Ahnung ob diese Datei gepackt ist - mit Zip entpacken funktionierte jedenfalls nicht - und auch sonst keine Informationen.

Wie kann ich dieses Problem nun angehen? Wie muss ich solch eine Datei einlesen? Was bedeuten diese "kyrillischen" Zeichen ....? Vielen Dank im voraus für die Hilfe. Tut mir Leid das ich nicht mehr Dokumentation zum Dateiformat habe, aber es müsste auch so gehen. Ein ähnliches Programm hat mit vermutlich denselben spärlichen Informationen ein Vorgänger von mir geschrieben den ich leider nicht mehr kennen gelernt habe.

 

[Anmeldeboykottierer]

HI,
sag mal bist du eigentlich mal auf die Idee gekommen dir die Datei auch ohne Hex-Edtitor anzuschauen?
Also dann bekommst du so etwas:

[GENERAL]
TITLE=Sample values
TYP=4
TIME=29.08.2006/11:10:51
XUNITS=nm
YUNITS=Abs
ZUNITS=
FIRSTX=400
LASTX=750
NPOINTS=351
NCYCL=1

[MESS]
ORIGIN=M500_MESSDLL V1.12
MESS_PAR_PATH=C:\ASPBUP\WINASP\_KASTERN.PAR
MESS_PAR_TIME=16.08.2006/12:07:48

[USER]
NOTE=

[DATA]
XDATA=
....
ZDATA=

Das sieht für mich weder sehr kryptisch noch sonderlich gepackt aus. Das wo hier ... steht, dürften deine Messdaten stehen. Allerdings siehst du (in deinem Editor) die Ascii oder Unicode Entsprechung der Bytes, die dort stehen. Wenn du also in den Hex-Teil schaust, wo du die sedezimale Darstellung finden solltest, dann hast du hier deine Messwerte. Die musst du nur als Zahl sehen. Ja, wie man die Daten dann interpretieren sollte siehst du sicher, wenn du sie mit dem Originalprogramm vergleichst.

Gruß

 

[Guest]

Mmmh, auch im Texteditor sieht es bei mir nicht anders aus als im Hex-Editor. Erst kommt Klartext mit Dateieigenschaften und dann kommen - allemöglichen ASCII-Zeichen.

Wie muss ich das denn genau verstehen in den ASCII-Zeichen-Bytes Daten zu sehen?

ASCII Code war für mich 256 Zeichen mit einer entsprechenden Nummer (z.B. ganzzahlig). Diese Daten sollten aber auf der X-Spalte ganzzahlig sein und auf der Y-Achse mit mindestens 3 Kommastellen zwischen 0 und 1 liegen.

Sorry, aber ich habe das noch nicht verstanden obwohl Du scheinbar die Lösung angesprochen hast.

Kannst Du es bitte noch einmal etwas ausführlicher machen? Was ist z.B. eine "sedezimale" Darstellung? Danke.

 

[Guest]

Ok, was sedezimal habe ich schonmal rausbekommen. Vielleicht fällt bei mir der Groschen auch noch für den Rest der Erklärung. Falls Du aber eher wieder auf meine Antwort stoßen solltest würde ich mich über Deine Antwort freuen - oder die eines jeden anderen.

 

[Guest]

Um ehrlich zu sein ist das auch nur so eine Art Pilotprojekt. Es gibt noch 2 andere Geräte/Dateitypen für die ein Konverter mehr als "schön" wäre.

 

[Wildcard]

ASCII Code war für mich 256 Zeichen mit einer entsprechenden Nummer (z.B. ganzzahlig).

ASCII sind nur 128 Zeichen.
Die Daten für X und Y sind vermutlich als Zahlen rausgeschrieben worden, der Editor versucht einfach nur diese Zahlen als Zeichen zu interpretieren, was natürlich nicht geht.
Da du sagst das die Y Werte keine natürlichen Zahlen sind könnte es schwierig werden diese Binärwerte zu interpretieren.

 

[Guest]

Also was heißt denn nun bitte "als Zahlen geschrieben"? Ist damit die Zahlendarstellung in "Maschinensprache" oder so gemeint und eben nicht der ASCII-Wert der Zahl? Sonst bräuchte er doch nicht versuchen irgendwas anzuzeigen sondern nur die Zahl.

Woran erkenne ich denn wann dieser Bytecode losgeht? Immerhin kann ich die ersten Zeichen ja auch lesen? Und am wichtigsten - wie lese ich diese Datei nun also ein - bei den dutzenden *Input*-Klassen. Vielleicht sollte ich die Datei einfach mal irgendwie einlesen und schauen was dabei rauskommt. Vielleicht verstehe ich es dann.

 

[Wildcard]

Also was heißt denn nun bitte "als Zahlen geschrieben"?

Damit ist die binäre Repräsentation einer Zahl gemeint .
Jede Datei ist eine große binäre Zahl. Es kommt nur darauf an wie man diese Zahl interpretiert.
Ein Texteditor versucht zum Beispiel bestimmte Teile dieser Zahl als Buchstaben zu interpretieren.
Für einige Teile deiner Datei funktioniert das auch, für die eigentlichen Daten aber nicht.
Bei den X-Werten könntest du noch Glück haben, das sieht nach Zahl gefolgt von Trennzeichen aus, aber bei den Y-Werten...
Good luck :wink:

 

[robertpic71]

Also:

1. Wie Wildcard schon geschrieben hat, vergiss die Textdarstellung des Datenteils. Das soll keine Zeichen darstellen, sondern nur Zahlen. Also ab in den Hexeditor.

2. Die Darstellung sieht mir verdächtig nach Little Endian (siehe wiki) aus, dabei werden die Zahlen "verdreht" gespeichert.

3. Von Vorteil wäre, wenn du dir von den gleichen Dateien, denn von dir angesprochnen CSV-Export machen würdest. Dann wäre im Vergleich wohl schnell ersichtlich, wie die Zahlen abgelegt sind.

4. Dir wird wohl nichts anders über bleiben, als das File byteweise zu parsen - ich habe zwar schön öfters "Patchprogramme" geschrieben, aber noch keines in Java - sollte aber kein Problem sein.

Wenn du das CSV hast, kannst du das noch einmal posten - beim Hacken ist es immer praktisch zu wissen, nach was man sucht...

Rob

 

[Guest]

Ok, vielen Dank für die Tipps. Die dazugehörige CSV-Datei habe ich jetzt im selben Verzeichnis abgelegt:
http://www.uni-leipzig.de/~pflaphys/tmp/ RESP.CSV

Dann werde ich mal byteweise einlesen und sehen was passiert.

 

[Guest]

Irgendwie mache ich was falsch.

package dat2csv;

import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;

public class Dat2CSV {

    public static void main(String[] args) {

        FileInputStream dat;
        boolean eof = false;
        int value;
        byte[] bV = new byte[10];
        
        try {
            dat = new FileInputStream("./extern/RESP.DAT");
            
            for (int i = 0; i < 10;i++) {
                int b = dat.read(bV); 
                System.out.print(" " + bV[1]);
                }
            dat.close();
        } catch (FileNotFoundException ex) {
            ex.printStackTrace();
        } catch (IOException ex) {
            ex.printStackTrace();
        }

    }
    
}

Ich lese doch in ein Byte, in der Ausgabe bekomme ich aber Integerzahlen also 79 128 -76 anstatt der 01... wie ich erwartet hatte. Außerdem bin ich ehrlich gesagt noch nicht schlauer geworden wie ich daraus nun die korrekten Zahlen/Zeichen bekomme. Kann ich noch einen Denkanstoß oder konkrete Tips erbitten? Ich bin kein Informatiker. ICh habe auch andere Ansätze probiert mit z.B. nur read(), die aber auch nicht zu wesentlich anderen Ergebnissen führten.

 

[robertpic71]

Das schaut ja recht übel aus....

1. Frage: sind das sicher die gleichen Datenreihen in CSV und DAT-File? Auf die Schnelle habe ich keine Übereinstimmung gefunden.

2. Frage: Was für ein Betriebssystem ist auf dem Messgerät? Linux-lastig? Dos-lastig? was eigenes?

3. Für die Verarbeitung von Fließkommazahlen reicht die byteweise Verarbeitung nicht aus! Die Angabe von Fließkommazahlen unterteilt die Angaben - leider nicht byteweise.

Hier ein kleine Beschreibung:

Eine Fließkommazahl mit einfacher Genauigkeit (float) wird intern durch vier Bytes (=32 Bits) dargestellt, von denen ein Bit das Vorzeichen, 8 Bit den Exponenten mit eigenem Vorzeichen und die restlichen 23 Bit die Mantisse darstellen. Fließkommazahlen mit doppelter Genauigkeit (double) werden unter Linux normalerweise durch acht Bytes mit 11 Bit Exponenten und 52 Bit Mantisse dargestellt.

Was mir nicht klar ist bei dem CSV, aus X-Wert und Y-Werten macht er nur eine Datenspalte? Die erste Datenspalte ist ja eine Laufnummer und wird im Kopf "angekündigt" (FIRSTX=400 LASTX=750).

BTW: Kennt jemand einen Hexeditor der Bit-Sequencen suchen kann? Ich glaube den könnte "Gast" gut brauchen...

Rob

 

[robertpic71]

Noch kurz zur Strategie, welche ich wählen würde:

1. Als erstes muß man wissen, wie die Zahlen zu interpretieren sind

2. Deine ausgewerteten Zahlen schauen eh gut aus - er intepretiert das 1. Bit als Vorzeichen. Wenn du bei den negativen 256 dazuzählst müssten die Werte umgerechnet als Hex, mit dem Hexeditor übereinstimmen.

3. Wenn die Datenfiles nicht zu groß werden, würde ich raten, das komplette File in ein ByteArray zu verlegen.

4. Außerdem musst du noch den Textteil und den Datenteil trennen. Du kannst ja die Bytes sammeln bis es ein CR/LF (0d/0a) kommt und einen String daraus machen. Wenn der String XDATA= heißt, weißt du wo die X-Daten beginnen.
Da am Ende der Daten auch ein CR/LF vorkommt, kannst du auf diese Art die Positionen der Daten (X,Y,Z) ermitteln.

Rob

 

[Guest]

Mmmh, sollte ich das hier mal hinkriegen werde ich mich wohl auch anmelden da ich dann wohl öfters mal was mit JAVA machen werde.

Ja, die CSV Datei ist mit der Export-Funktion des Programmes erstellt wurden. Es enthält halt nur die Datenreihen ohne die weiteren Informationen. Die X-Reihe gibt die Wellenlänge von 400-750 nm an (ist ein Spektrometer). Die Y-Reihe ist die Absorption.

Das gerätespezifische Programm läuft auf einem Win 3.11!!!

Allzu groß werden die Dateien wohl nicht.

 

[robertpic71]

Mmmh, sollte ich das hier mal hinkriegen werde ich mich wohl auch anmelden da ich dann wohl öfters mal was mit JAVA machen werde.

Hat auch den Vorteil, dass man Benachrichtigt (e-Mail) wird, wenn sich was tut.

Schön langsam dämmert mir mein (verdrängtes?) Wissen aus Assemblerzeiten wieder. Fließkommazahlen werden nicht einfach in Exponent und Mantnisse unterteilt sondern damit berechnet. Damit braucht man sich aber gar nicht herumschlagen, denn ab Java 1.4 gibt es dafür eine Funktion:

iimport java.nio.ByteBuffer;
import java.nio.ByteOrder;

public class TestFloat {

    public byte[] array = { (byte) 0x00, (byte) 0x00, (byte) 0xc8, (byte) 0x43,
                                 (byte) 0x06, (byte) 0x71, (byte) 0xd6, (byte) 0x3e };
    public int pointer=0;

    public TestFloat() {
    }

    public void run() {
    	float f = ByteBuffer.wrap( array, pointer, 4 ).order( ByteOrder.LITTLE_ENDIAN ).getFloat();
        System.out.println("X =  " + f);    
        pointer += 4;
        f = ByteBuffer.wrap( array, pointer, 4 ).order( ByteOrder.LITTLE_ENDIAN ).getFloat();
        System.out.println("Y = " + f); 
    }
    
    public static void main(String[] args) {
        new TestFloat().run();
    }


}

Hier habe ich den ersten X-Wert und ich glaube den 3. Y-Wert getestet.

Also:
- rein mit dem File in ein Byte-Array
- File parsen und Start- und Endadressen (Index) der Daten ermitteln
- Daten durchlaufen, pointer = Startindex der Daten, pointer immer um 4 erhöhen (1 Zahl = 4 Bytes)

Viel Spass

 

[Guest]

Danke. Hui, in den Code muss ich mich aber noch reindenken - aber man lernt ja was bei. Hoffe das ich das Wochenende mal dazu komme. Vielen Dank nochmals und ich melde mich bestimmt wieder.

Wenn Dein Programmteil tatsächlich den dritten Y-Wert od. zumindest irgendeinen Wert da herum in "normal" ausspuckt und ich dann auch verstehe wieso, wäre das, denke ich, der Durchbruch den ich gebraucht habe.

Vielen Dank nochmals.