Unbekanntes Dateiformat einlesen

[ryLIX]

Moin liebe DP User,
es geht sich um folgendes Problem.
Ich habe einen ganzen Haufen ein Dateien deren Format ich nicht kenne.
Es scheinen typisierte Dateien zu sein da der aufbau immer bzw so gut wie immer gleich ist.

Ich habe nun von einem Bekannten ein Programm bekommen mit dem man diese Dateien ins Txt-Format umwandeln kann.
Dem Anwendungsicon nach zu Urteilen ist es eine Exe die mit Delphi erstellt wurde.

Nun suche ich nach einer Möglichkeit dieses Programm quasi nach zu schreiben bzw die kovertierung Funktion.
Da ich diese gern in einem eigenen Programm verwenden möchte.

Leider komm ich nicht weiter :/
Die Datei scheint im Unicode Format vorzuliegen da sie sich nicht in ein Memo laden lässt (hab keine TNT Komponenten installiert).

Nun war mein erster Ansatz diese Datei über einen FileStream einzulesen aber wie gehts dann weiter? :gruebel:

Noch kurz was zu Zweg der ganzen Sache:
Die Dateien enthalten Informationen über Parameter und Schlüsselwörter die zur Fahrzeugcodierung verwendet werden.
Damit is nicht Tachojustierung oder so gemeint sondern Daten zur Ausstattung o.ä . des Fahrzeugs.
Um mit der Software zur Codierung besser arbeiten zu können würde ich gerne die Schlüsselwörter und deren Parameter im Klartext darstellen.

Ich habe mal ein Paket angehängt was 4 Dateien enthält jeweils 2 Originale und die Konvertierte Version dazu damit man sich vorstellen kann was ich meine.


Vielleicht hat jemand eine Idee oder Möglichkeit wie man diese Dateien konvertiert.

P.S.: Ich habe versucht den Programmierer des Programms zu erreichen um dort die Routine zu erfragen hababer leider keine Antwort erhalten.

[nahpets]

Hallo,

was es ist, weiß ich nicht: Kein Dbase (wenn auch Ähnlichkeiten vorhanden zu sein scheinen) kein Unicode.
Die Texte aus den Textdateien sind in den Binärdateien zu finden. Die einzelnen Zeichen zwischen den vielen Hex-Nullen spiegeln die Werte wieder, die in den Textdateien zu finden sind. Der "Kopf" der Dateien scheint bis etwa zu der Stelle zu gehen, an der der Dateiname in der Binärdatei steht. Bei hexadezimaler Betrachtung scheinen die Daten in der nächsten Zeile zu beginnen.

Versuch' mal, anhand der Textdateien, die Binärdateien zu lesen. Hex-Null ist immer das Ende (oder der Anfang?) eines neuen Wertes, tippe aber eher auf eine feste Satzlänge, das könntest Du dann mit 'nem Record lesen.
Die "Menge" der jeweils zu lesenden Bytes kannst Du eventuell auch den Textdateien entnehmen (ob 1 Byte, 2 oder wieviel auch immer).

PARZUWEISUNG_FSW : {00000000},00000000,0001,0608,{},(00 01),{68},{} findest Du in der Datei LSZ.C26 ab der Adresse 04d0, zwei aufeinanderfolgende Bytes musst Du dabei wohl in umgekehrter Reihenfolge lesen.
Probier mal, ob Du anhand dieser (unvollständigen) Info's den Inhalt der Datei LSZ.C26.txt in der Datei LSZ.C26 von "Hand" nachvollziehen kannst. Wenn das geht, solltest Du in der Lage sein, entsprechende Leseroutinen zu schreiben. Ist aber mit Sicherheit mehr Aufwand als so mal "eben" machen.

[nicodex]

Wie nahpets/stephan schon geschrieben hat, ist es "einfach" nur Arbeit und Zeit die man investieren muss. Dadurch dass dir bereits eine Textversion zur Verfügung steht, sollte es nicht mehr so schwer fallen, die Binärdaten in Längen-, Anzahl-, Typen- und Wertangaben zu zerlegen. Im ersten Block scheinen die "Funktionen" definiert zu werden (Index -> Name, Parameteranzahl/-typen/-namen) und im zweiten Block scheinen die "Aufrufe" (per "Funktions"-Index) zu stehen.

Da hilft nur ein (langer) Blick mit einem handelsüblichen Hex-Editor.

[ryLIX]

Danke schon mal für Antworten.
Da werd ich wohl erstmal die Grundlagen lernen müssen über die Filestreams usw.

Wenn ihr eventuell ein paar gute Links zu dem Thema habt wäre ich dankbar :)

Hatte beim Delphi-Treff zwei Tutorials gefunden zu typisierten Dateien und Binärdateien.
Aber bin mir noch nicht so sicher ob mich das weiter bringt.

[nahpets]

Hallo,
nein, fange nicht an zu Programmieren, versuche zuerst die Dateien soweit zu analysieren, dass Du eine möglichst genau Vorstellung von ihrem Aufbau hast. Lass Dir Zeit dabei.

Ich würde versuchen, mir einen Record zu bauen, der eventuell so aussehen könnte:

Delphi-Quellcode:

type
  TMyRecord = record
    a: Byte;
    b: Word;
    c: Array[1..10] of char;
    // ... bis er alles enthält, was auch in den Textdateien steht.
  end;

Wenn Du dann weißt, wie groß ein Satz ist, kannst Du eventuell mit BlockRead an's lesen gehen oder dann nochmal nachfragen, was am sinnvollsten ist. Bei einer festen Satzstruktur kannst Du sicherlich anders vorgehen, als wenn Du eine flexible Satzlänge zu verarbeiten hast. Je genauer Du diese "Vorarbeit" machst, um so einfacher wird es nachher, es ist immer ärgerlich, wenn man eine Lösung fast fertig hat und sie dann auf ein paar Exoten doch nicht zutriff und man nochmal von vorne anfangen muss. Momentan tippe ich noch darauf, dass es sich um eine typisierte Datei handelt (Sprich: Struktur erarbeiten, dann weiterschauen).

[ryLIX]

Ok Danke für den Hinweis.

Ich hatte Angefangen den "Header" zu analysieren wobei mir aufgefallen ist das ein Zeichen dort regelmäßig vorkommt.
Und zwar immer dann wenn in der Textdatei ein Zeilenumbruch ist.

Code:

0300

Also ein Zeichen + Hex Null
Das zieht sich bis zur letzten Zeile die hat aber wiederrum diesen Abschluss nicht.

Da suche ich noch nach einem eindeutigem Zeichen.

[nahpets]

Hallo,

schön, dass heißt doch, dass Du in der Lage bist, bei einer Datei festzustellen, wieviele Spalten die Datenbanktabelle hat. Die Namen der Spalten bekommst Du auch heraus, wie hören die Namen auf, alle mit 00? Was steht da bis zum nächsten Spaltennamen? Läßt sich daraus die Länge einer Spalte oder der Datentyp ableiten?
Hast Du irgendeine Software, die auf diese Dateien zugreift und Dir "durch Anschauen der Bedienoberfläche" irgendwelche weiteren Hinweise geben kann.
Wie muss man den Definitionsbereich der Textdatei interpretieren? Ist da jede Zeile als Satzart zu bewerten, wieviele Fahrzeuge sind in einer Datei, eins oder mehrere?
Sind die Köpfe aller Textdateien identisch?
Die beiden Textdateien, die Du uns da gezeigt hast, scheinen auf unterschiedliche "Speicherarten" der Daten hinzuweisen, einmal Block und einmal Frei, was immer das jetzt genau bedeuten mag. Die Dateien mit Block scheinen mir systematischer zu sein. Stürz Dich zuerst mal nur auf einen Typ, wähl' Dir davon ein paar Dateien aus und vergleiche sie mit Totalcommander, oder Windiff oder was Dir da immer am liebsten ist, suche systematische Übereinstimmungen und systematische Unterschiede.

Hinter den Spaltennamen steht irgendwo nochmal der Dateiname, davor gibt es ein $FFFF, ist das das von die gesuchte "Ende"?

Insgesamt: eine sportliche Fleißarbeit ;-)

P.S.: Prüfe jede von Dir gefundene Regel an mehreren Dateien. Deine 03 könnte auch ein Hinweis auf die Länge des Wertes oder den Datentyp sein.

[ryLIX]

Dann werd ich mal das große Vergleichen anfangen ;)

Noch kurz zu den Dateien:
Die Dateien gehören jeweils zu einem Fahrzeug bzw Modellreihe.
Die Angehängten Dateien sind Dateien zu zwei Steuergeräten für ein Fahrzeug.
Es gibt noch Dateien mit den Schlüsselwörtern bzw Parameterwörtern die anscheinend mehr wie der Header aufgebaut sind.
Ich muss da aber noch genauer reinschauen.

Insgesamt habe ich über 1000 Dateien zur verfügung um das Format zu entschlüsseln.
Ich denke das sollte reichen :zwinker:

[nahpets]

Hallo,

Okay, Du geht's mit 'nem fröhlichen Optimismus daran, dass ist sehr hilfreich.
Wünsche Dir viel Erfolg.

[Der.Kaktus]

hallo,
habe sowas auch frueher machen muessen. Als erstes habe ich immer versucht, die Satzlaenge rauszubekommen. Die Struktur ist dann ein kleineres Uebel. Aber nach den ersten 10 erfolgreich dekodierten Dateien..geht es flott :oops: Viel Glueck!

[ryLIX]

Ja bin immer optimistisch :)
Folgendes habe ich nun geschafft:

Code:

02010C00030000  --- Start Header?
00071300030100  --- Trennung Dateiname/SGID_CodierIndex
00101600030200  --- Trennung SGID CI/ SGID_Hardwarenummer
00101000030300  --- Trennung Hardwarenummer/SWNummer
00100E00030400   --- Trennung SWNummer/Speicherorg
00611200030500  --- Trennung Speicherorg/Anlieferungszustand
00141300030600   --- Trennung Anlieferungszustand/Codierdatenblock
00041700030700   --- Trennung Codierdatenblock/Herstellerdatenblock
00041700030800   --- Trennung Herstellerdatenblock/ReserviertDatenblock
00040C00030900   --- Trennung Reserviertdatenblock/Unbelegt1
006F0C00030A00   --- Trennung Unbelegt1/Unbelegt2
00140C00030B00   --- Trennung Unbelegt2/Kennung_K
003A0C00030C00   --- Trennung Kennung_K/Kennung_D
000F0C00030D00   --- Trennung Kennung_D/Kennung_X
000F0E00030E00   --- Trennung Kennung_X/Kennung_All
00321400030F00   --- Trennung Kennung_All/Parazuweisung_PSW2
004A1400031000   --- Trennung Parazuweisung_PSW2/Parazuweisung_PSW1
003E1300031100   --- Trennung Parazuweisung_PSW1/Parazuweisung_Dir
00181300031200   --- Trennung Parazuweisung_Dir/Parazuweisung_FSW

001E0000FFFF   --- Ende Header

Nun muss ich nur noch wissen wie das zu interpretieren ist. Dann hätte ich den Header entschlüsselt.
Denn das gefundene ist bei allen (20 Dateien kontrolliert) gleich.

Tante edit:
Ich hab noch was gefunden weiß nur noch nicht was ich damit Anfangen muss :gruebel:

Code:

02 01 0C 0003 0000
 |  |  |   |    |_ ID Im Header (0000 in diesem Fall)
 |  |  |   |_ Einleiten der neuen Zeile bzw Trennzeichen zwischen den Zeilen
 |  |  |_ Name (In diesem Falle DATEINAME)
 |  |_ Datenformat (S in diesem Fall)
 |_ Datenname (NAME in diesem Fall)

Und nochmal Edit:
Hab nun den Sinn der ID gefunden.
Man findet über die Hex ID z.b. 0500 den Anfang der zu der ID gehörenden Daten.
0500 = Auslieferungszustand.
Nun muss ich noch sehen wie diese Daten gespeichert sind.
Ich denke das lässt sich dann mit NAME Datenformat und Datenname finden.

[ryLIX]

Code:

02
010C00
03 Start Header

0000  --- Dateiname 00071300
03
0100  --- SGID_CodierIndex 00101600
03
0200  --- SGID_Hardwarenummer 00101000
03
0300  --- SGID_SWNummer 00100E00
03
0400  --- Speicherorg 00611200
03
0500  --- Anlieferungszustand 00141300
03
0600  --- Codierdatenblock 00041700
03
0700  --- Herstellerdatenblock 00041700
03
0800  --- ReserviertDatenblock 00040C00
03
0900  --- Unbelegt1 006F0C00
03
0A00  --- Unbelegt2 00140C00
03
0B00  --- Kennung_K 003A0C00
03
0C00  --- Kennung_D 000F0C00
03
0D00  --- Kennung_X 000F0E00
03
0E00  --- Kennung_All 00321400
03
0F00  --- Parazuweisung_PSW2 004A1400
03
1000  --- Parazuweisung_PSW1 003E1300
03
1100  --- Parazuweisung_Dir 00181300
03
1200  --- Parazuweisung_FSW 001E0000

FFFF  Ende Header

Das is was ich bisher habe.
Ich bin mir aber nicht sicher ob ich da richtig liege :gruebel:

[nicodex]

Zitat:

Zitat von ryLIX

Das is was ich bisher habe.
Ich bin mir aber nicht sicher ob ich da richtig liege :gruebel:

Bist du schon weiter? Oder anders gefragt, lohnt es sich noch, wenn jemand/ich einen Blick darauf wirft?

[nahpets]

Hallo,

das was Du im letzten Post stehen hast, sieht aber schon recht plausibel aus.
Dateiname hat die Nr. 00 und dann geht es aufsteigend nummeriert weiter bis Nr. 12, gefolgt vom Ende des Headers mit FFFF.

Damit bin ich nicht so ganz einverstanden, kann aber sein, dass ich mich heftig täusche:

Code:

02010C00030000  --- Start Header? 
00071300030100  --- Trennung Dateiname/SGID_CodierIndex 
00101600030200  --- Trennung SGID CI/ SGID_Hardwarenummer 
00101000030300  --- Trennung Hardwarenummer/SWNummer 
00100E00030400   --- Trennung SWNummer/Speicherorg 
00611200030500  --- Trennung Speicherorg/Anlieferungszustand 
00141300030600   --- Trennung Anlieferungszustand/Codierdatenblock 
00041700030700   --- Trennung Codierdatenblock/Herstellerdatenblock 
00041700030800   --- Trennung Herstellerdatenblock/ReserviertDatenblock 
00040C00030900   --- Trennung Reserviertdatenblock/Unbelegt1 
006F0C00030A00   --- Trennung Unbelegt1/Unbelegt2 
00140C00030B00   --- Trennung Unbelegt2/Kennung_K 
003A0C00030C00   --- Trennung Kennung_K/Kennung_D 
000F0C00030D00   --- Trennung Kennung_D/Kennung_X 
000F0E00030E00   --- Trennung Kennung_X/Kennung_All 
00321400030F00   --- Trennung Kennung_All/Parazuweisung_PSW2 
004A1400031000   --- Trennung Parazuweisung_PSW2/Parazuweisung_PSW1 
003E1300031100   --- Trennung Parazuweisung_PSW1/Parazuweisung_Dir 
00181300031200   --- Trennung Parazuweisung_Dir/Parazuweisung_FSW 
001E0000FFFF   --- Ende Header

Nehmen wir mal denhier:

Code:

00071300030100  --- Trennung Dateiname/SGID_CodierIndex

Wie wäre es mit

Code:

0100  --- Trennung Dateiname/SGID_CodierIndex
0010160003

Also hinter der 03 beginnt eine Spalte mit der laufenden Nummer, gefolgt von 00 und dann folgen noch Angaben zum Typ, zur Länge?
Würde die laufende Nummer der Spalten doch eher als ihren Anfang interpretieren und nicht quasi mitten drin. Zumal, wenn Du die Nr. als Anfang interpretierst, bekommst Du bis zu nächsten Nummer immer alle die Zeichenfolgen zu der Spalte zusammen, die auch in der Textdatei stehen. Und wenn Du die Nr. zusammen mit der folgende 00 betrachtest und die beiden Werte vertauschst, also 00+Nr., dann hast Du die gleiche Aufzählung, wie in der Textdatei.
Eventuell musst Du Deine Betrachtungsweise (von Teilen der Dateien) mal von einzelnen Bytes auf Wörter umstellen, dann scheint z. B. die Nummerierung der Spalten "offensichtlicher".

Habe jetzt zugegebenermaßen nicht die Zeit, um mich intensiver damit zu beschäftigen, werde aber heute und morgen ab und an nochmal vorbeischauen ;-)

[nicodex]

Wenn man die Daten etwas sortiert, dann wird es einfacher:

Code:

// header
07,00,01,00,01,00,01,01,01,63,65,01,00,02,02,01,0C,00

// definition 0
03,0000         // 03,<id>
'DATEINAME',00  // <name>
55,0002,04      // ?,sizeof(<data_format>),04
'S',00          // <data_format>
55,0005,05      // ?,sizeof(<data_names>),05
'NAME',00       // <data_names>
07,0013         // ?,?

//...

// definition 19
03,0012
'PARZUWEISUNG_FSW',00
07,0013,04
'{L}LWW{B}(B){B}{B}',00
16,0038,05
'BLOCKNR,WORTADR,BYTEADR,FSW,INDEX,MASKE,EINHEIT,INDIVID',00
1E,0000

FF,FF,08,00,00
'GM5.C01',00
5B,03,01,00,01,00,00,03,0A,04,00
'BYTE',00
//...

Damit kann man, trotz unbekannter Werte bereits die Definitionen lesen. Der Rest dürfte dann schwerer werden - mehr als 10min hatte ich leider auch nicht.

[ryLIX]

@nicodex
ja soweit hatte ich das gestern auch noch auseinander getüftelt.
Nur bin ich mir noch nicht sicher wie der Zusammenhang der Bytes mit den Schlüsselwörtern ist.

Code:

03 0000[ID] 'DATEINAME' 00 (55/U) 02 00 04 'S' 00 (55/U) 05 00 05 'NAME' 00 07 13 00

Die Werte in Klammern stehen als U im Text ich behaupte mal das es der Bindestrich ist.

Nur weiß ich nicht wozu die die anderen Werte gut sind.
Im Beispiel also 02 00 04 oder 05 00 05.

Sehe ich das richtig das 00 eine Leerzeile repräsentiert?

Find ich gut das ihr beiden mich hier etwas unterstüzt :)
Da es das erstemal ist das ich sowas mache und nicht genau weiß was ich mache :angel2:
Ich werd weiterhin meine beobachtungen hier posten.

[nicodex]

Zitat:

Zitat von ryLIX

Nur weiß ich nicht wozu die die anderen Werte gut sind.
Im Beispiel also 02 00 04 oder 05 00 05.

Wie ich oben schon geschrieben habe:

02 00 04 -> 0002 (litte-endian Word), 04 (Byte) -> Länge von data_format ("S") inklusive der abschließenden 00 (#0), Unbekannt (immer 04 für data_format)

05 00 05 -> 0005 (litte-endian Word), 05 (Byte) -> Länge von data_names ("NAME") inklusive der abschließenden 00 (#0), Unbekannt (immer 05 für data_names)

[nahpets]

Hallo,

die 00 interpretiere ich auf zwei Weisen:

Ende eines Strings (nullterminierte Zeichenfolgen) oder Teil eines zweibytigen Wertes.
Zugegebener Maßen habe ich noch keinen "Griff" gefunden, der auch nur eine dieser Annahmen definitiv bestätigt.

Deiner "Bindestrichtheorie" möchte ich widersprechen, die Bindestriche sind im Text der Optik wegen und nicht auf den Inhalt der Dateien zurückzuführen. Sonst müssten überall wo im Text Bindestriche sind auch in der Datei U's stehen. Habe nicht den Eindruck, dass die Textdatei den vollständigen Header widerspiegelt, sondern nur die Informationen, die der Programmierer mit ziemlicher Sicherheit entschlüsselt hat. Und das sind die lesbaren Zeichenfolgen.
Unklar ist mir, welchen Zusammenhang die Bytes zwischen den Zeichenfolgen mit dem Inhalt der Dateien hinter dem Header haben.

Nico's Erklärung klingt durchaus plausibel.

[nicodex]

Das Problem sind die vielen Interpretationsmöglichkeiten, die man erst durch möglichst viele Daten und sinnvolle "Muster" konkretisieren kann.

02 00 04 .. könnte zum Beispiel auch folgendes bedeuten: Länge des "Wertes" = 2, Typ des "Wertes" = 0 ( = String), Bedeutung des "Wertes" = 04 ( = Parametertypliste einer Definition), .. "Wert".

Um die Möglichkeiten einzuschränken, hilft nur die Auswertung aller zur Verfügung stehenden Informationen: Anzeigen/Ausgaben von offiziellen und inoffiziellen Anwendungen und Zurückentwicklung selbiger (und wenn es "nur" dazu dient, um festzustellen wie viele Bytes unter welchen Bedingungen gelesen werden - allein diese Information ist sehr hilfreich). Viele dieser Informationsquellen stehen den Leuten im Forum nicht zur Verfügung. Anhand von zwei Dateien ist keine Vollständige Analyse zu erwarten.

[ryLIX]

Also leider kann ich nur mit der inoffiziellen Software was machen da die offizielle sich die Daten zu einem mir unbekannten Zeitpunkt holt.

Was mir noch aufgefallen ist ist folgendes:
Das Konvertierungsprogramm macht einen CRC Check. Wenn man nun ein Zeichen hinzufügt bzw löscht kommt der CRC Fehler.
Wenn aber nur zwei Zeichen vertauscht geht es ohne Probleme.

Ich weiß leider nicht wie ich das Programm noch etwas mehr ausnutzen kann.
Asambler hab ich garkeine Ahnung von und mit Debugging hab ich auch nicht die große Erfahrung.

Edit:
Ich hab mir gerade mal eine der Schlüsselwort Dateien geladen.

Auch dort ist der Header nach dem selben Prinzip aufgebaut.
Enthält aber weniger Informationen weil der Inhalt der Datei nicht so komplex ist
Ich hab die Datei mal angehängt.

[nahpets]

Hallo,

Zitat:

Das Konvertierungsprogramm macht einen CRC Check. Wenn man nun ein Zeichen hinzufügt bzw löscht kommt der CRC Fehler.
Wenn aber nur zwei Zeichen vertauscht geht es ohne Probleme.

läßt auf eine feste Satzlänge schließen, der Inhalt scheint aber (in gewisser Weise) wursch zu sein.

[ryLIX]

Code:

07 00 01 00 01 00 01 01 01 63 65 01 
00 02

02 01 0C 00 03 0000 DATEINAME            00 55 02 00 04 S                  00 55 05 00 05 NAME
00 07 13 00 03 0100 SGID_CODIERINDEX     00 1F 05 00 04 B(B)               00 00 0B 00 05 WERT,WERT2
00 10 16 00 03 0200 SGID_HARDWARENUMMER  00 43 05 00 04 S(S)               00 00 0B 00 05 WERT,WERT2
00 10 10 00 03 0300 SGID_SWNUMMER        00 5E 05 00 04 S(S)               00 00 0B 00 05 WERT,WERT2
00 10 0E 00 03 0400 SPEICHERORG          00 40 03 00 04 SS                 00 07 0D 00 05 STRUKTUR,TYP
00 61 12 00 03 0500 ANLIEFERZUSTAND      00 49 04 00 04 (B)                00 43 05 00 05 WERT
00 14 13 00 03 0600 CODIERDATENBLOCK     00 13 07 00 04 {L}LWS             00 01 24 00 05 BLOCKNR,WORTADR,BYTEADR,BEZEICHNUNG
00 04 17 00 03 0700 HERSTELLERDATENBLOCK 00 0A 07 00 04 {L}LWS             00 01 24 00 05 BLOCKNR,WORTADR,BYTEADR,BEZEICHNUNG
00 04 17 00 03 0800 RESERVIERTDATENBLOCK 00 00 07 00 04 {L}LWS             00 01 24 00 05 BLOCKNR,WORTADR,BYTEADR,BEZEICHNUNG
00 04 0C 00 03 0900 UNBELEGT1            00 31 0C 00 04 {L}LW{B}(B)        00 5E 24 00 05 BLOCKNR,WORTADR,BYTEADR,INDEX,MASKE
00 6F 0C 00 03 0A00 UNBELEGT2            00 31 04 00 04 (B)                00 43 05 00 05 WERT
00 14 0C 00 03 0B00 KENNUNG_K            00 42 06 00 04 SS(S)              00 50 12 00 05 IDENT,WERT1,WERTN
00 3A 0C 00 03 0C00 KENNUNG_D            00 4A 07 00 04 WW(WW)             00 02 26 00 05 HEXWERT1,HEXWERT2,HEXWERTN1,HEXWERTN2
00 0F 0C 00 03 0D00 KENNUNG_X            00 57 07 00 04 WW(WW)             00 02 26 00 05 HEXWERT1,HEXWERT2,HEXWERTN1,HEXWERTN2
00 0F 0E 00 03 0E00 KENNUNG_ALL          00 4F 06 00 04 SW(W)              00 50 1A 00 05 KENNUNG,HEXWERT1,HEXWERTN
00 32 14 00 03 0F00 PARZUWEISUNG_PSW2    00 39 04 00 04 (B)                00 43 06 00 05 DATUM
00 4A 14 00 03 1000 PARZUWEISUNG_PSW1    00 25 05 00 04 W(B)               00 15 0A 00 05 PSW,DATUM
00 3E 13 00 03 1100 PARZUWEISUNG_DIR     00 19 11 00 04 {L}LWW{B}(B)(A)B   00 16 3A 00 05 BLOCKNR,WORTADR,BYTEADR,FSW,INDEX,MASKE,OPERATION,EINHEIT
00 18 13 00 03 1200 PARZUWEISUNG_FSW     00 07 13 00 04 {L}LWW{B}(B){B}{B} 00 16 38 00 05 BLOCKNR,WORTADR,BYTEADR,FSW,INDEX,MASKE,EINHEIT,INDIVID

00 1E 00 00 FF FF

Hab hatte mal wieder etwas Zeit und hab mich noch mal dem Header gewidmet und habe es so sortiert wie nicodex es forgeschlagen hat.
Noch ein wenig einrückung dazu und schon siehts schick aus :)
Nun habe ich mir das ganze in Ruhe angeschaut und folgende Theorie entwickelt:
Da man im Moment von einer festen Satzlänge ausgehen kann (durch den CRC Check) kommt folgende aufteilung als schlüssig vor:
03 -> Start ID und Bezeichner
04 -> Start Variablentyp
05 -> Start Variablenname
Also wie nicodex es auch schon meinte.
Was mich immer noch etas verwirrt ist die erste Zeile der Datei und warum startet die Zeile für 'DATEINAME' nicht mit 00

Zu dem Header habe ich mir heute auch mal den Databereich näher angeschaut.
Auch hier feste Satzlänge. Anfang und Ende von gleichen Zeilen (PSW1 z.B.) fangen immer gleich an und Enden gleich.

Code:

DATEINAME : ALC_DS2.C04
0C 0000 ALC_DS2.C04 00 51

SGID_CODIERINDEX : 04,(00)
03 0100 04 00 00 06

SPEICHERORG : BYTE,BLOCK
0B 0400 BYTE 00 BLOCK 00 4C

ANLIEFERZUSTAND : (00 00)
03 0500 01 00 00 07

CODIERDATENBLOCK : {00003000},00000000,0010,Grundkonfiguration_ALC-SG
25 0600 01003000 00000000 0010 00 Grundkonfiguration_ALC-SG 00 18

PARZUWEISUNG_FSW : {00003000},00000000,0001,02D6,{},(00 01),{68},{}
14 1200 01003000 00000000 0001 00 D602 000100 0101 68 00 8B

PARZUWEISUNG_PSW1 : 0002,(00 00)
05 1000 0200 01 00 00 16

PARZUWEISUNG_PSW1 : 0001,(00 01)
05 1000 0100 01 00 01 14

PARZUWEISUNG_FSW : {00003000},00000000,0001,02D4,{},(00 02),{68},{}
14 1200 01003000 00000000 0001 00 D402 000100 0201 68 00 8A

PARZUWEISUNG_PSW1 : 0002,(00 00)
05 1000 0200 01 00 00 16


PARZUWEISUNG_PSW1 : 0001,(00 01)
05 1000 0100 01 00 01 14

PARZUWEISUNG_FSW : {00003000},00000000,0001,0647,{},(00 04),{68},{}
14 1200 01003000 00000000 0001 00 4706 000100 0401 68 00 1B


PARZUWEISUNG_PSW1 : 0002,(00 00)
05 1000 0200 0100 00 16


PARZUWEISUNG_PSW1 : 0001,(00 01)
05 1000 0100 01 00 01 14

UNBELEGT1 : {00003013},0000000F,0001,{},(00 FF)
0F 0900 01 13300000 0F000000 0100 0001 00FF D4

UNBELEGT2 : (00 00)
03 0A00 0100 00 08

[ryLIX]

Zitat:

Zitat von Externes Forum

So, das mit dem CRC oder Checksumme ist geklärt :wink:
Der Code wird in Blöcke geteilt und von jedem Block eine Xor-Checksumme gebildet! Habe mir den Spaß erlaubt und eine kurze Datei als Test geschrieben, die man mit dem Datentool öffnen kann.

Code:

00000000 07 00 01 00 01 00 01 17 07 68 7E 01 00 02 02 01 .........h~.....
00000010 0A 00 03 00 00 4D 41 4C 49 42 4F 4F 00 42 02 00 .....MALIBOO.B..
00000020 04 53 00 55 07 00 05 46 4F 52 55 4D 20 00 61 00 .S.U...FORUM .a.
00000030 00 FF FF 04 00 00 52 41 44 00 53                .ÿÿ...RAD.S

Hier die Blöcke:

07 00 01 00 01 00 01 17 07 68 => 7E
01 00 02 02 01 0A 00 03 00 00 4D 41 4C 49 42 4F 4F 00 => 42
02 00 04 53 00 => 55
07 00 05 46 4F 52 55 4D 20 00 => 61
00 00 FF FF 04 00 00 52 41 44 00 => 53


...war doch ganz einfach :mrgreen:

:wall: :wall:

Naja nun ist die Lösung wahrscheinlich ganz nahe ;)
Ich glaube ich sollte mal schauen wie man das mit dem XOR mit Delphi macht...

Aso das Ergebnis der Testdatei sieht im Konverter so aus:

Code:

-definitions--------------------------------------------------------------------
[ id - name - data_format - data_names ]
0000 - MALIBOO - S - FORUM 
-daten--------------------------------------------------------------------------
MALIBOO : RAD
-eof----------------------------------------------------------------------------

[nicodex]

Zitat:

Zitat von ryLIX

Ich weiß leider nicht wie ich das Programm noch etwas mehr ausnutzen kann.
Asambler hab ich garkeine Ahnung von und mit Debugging hab ich auch nicht die große Erfahrung.

Nun, es gibt im Forum schon einige Leute, die mit einem Disassembler umgehen können :)

Offensichtlich wird das Format auch in einem anderen Forum analysiert - nur, dass dort das Datentool zur Verfügung steht...
(hättest du erwähnt, dass es eine CRC-Fehlermeldung gibt, hätte man auch danach suchen können)

[ryLIX]

Zitat:

Zitat von ryLIX

Was mir noch aufgefallen ist ist folgendes:
Das Konvertierungsprogramm macht einen CRC Check. Wenn man nun ein Zeichen hinzufügt bzw löscht kommt der CRC Fehler.
Wenn aber nur zwei Zeichen vertauscht geht es ohne Probleme.

Hab ich doch ;)
Schau dir mal den Ahang an vielleicht kannst du damit was Anfangen.

[nicodex]

Zitat:

Zitat von ryLIX

Schau dir mal den Ahang an vielleicht kannst du damit was Anfangen.

Jupp, kann ich - siehe Anhang.
(ist einfach nur nachprogrammiert, ich hätte diversen Typen/Funktionen/Variablen andere Namen gegeben und anstatt Assign/Reset/Read/Close mit Sicherheit TMemoryStream verwendet (auch für die Analyse der Datenblöcke)).

Kurzer Überblick:

Code:

while (!eof)
{
  uint8_t  Size;
  uint16_t ID;
  uint8_t  Data[Size];
  uint8_t  Checksum;  // xor Size,ID,Data[...]
};

Die Interpretation von Data[] hängt von der ID ab:

Code:

// ID(0x0100): // definition block start
// ID(0x0200): // definition block header
// ID(0x0300): // definition name
//      uint16_t ID;
//      uint8_t  Name[Size - sizeof(ID)];  // includes '\0'
// ID(0x0400): // definition data_format
//      uint8_t  DataFormat[Size];  // includes '\0'
// ID(0x0500): // definition data_names
//      uint8_t  DataNames[Size];  // includes '\0'
// ID(0xFF00): // data block start
// ID(<else>): // ID == Definition[x].ID
//      uint8_t  Data[Size];  // parse with Definition[x].DataFormat

Für die Implementation von ParseData() bin ich zu faul - viel Spaß ;)

[ryLIX]

Öhm ja
Erstmal danke nicodex :hello:

Dann werde ich mich mal über das ganze her machen und versuchen zu verstehen was da abgeht.
Einen kleinen Überblick habe ich mir gerade verschafft.
Ich hoffe das du mir noch in wenig zur Seite stehst wenn ich Fragen zu ParseData habe ;)

Aber ich will versuchen so viel wie möglich allein zu schaffen sonst war ja noch nicht mal ein lern Effekt dabei :D

:dp:

[ryLIX]

So nach dem ich nun einige Zeit damit verbracht habe zu verstehen was dort passiert :D sind noch ein paar Fragen offen.

Delphi-Quellcode:

GDefinitons[Index].ID := (ABlock.Data[1] shl 8) + ABlock.Data[0];

Hier ist mir der Sinn noch nicht ganz klar. Wie muss ich mir den Inhalt von ABlock.Data vorstellen?

Delphi-Quellcode:

ParseData(ABlock.Size, @ABlock.Data[0], GDefinitons[Index].DataFormat);

Hier wird nun Size übergeben. Aber von was? Von Data?

Bei der Implementation von ParseData() fehlt mir irgendwie noch der richtige Lösungsansatz.
Eine Fall Entscheidung mit case durch das mitgelieferte DataFormat ist nicht möglich da ein String nicht Ordinal ist.
Ich hab irgendwie das Gefühl ich seh den Wald vor lauter Bäumen nicht...
:wiejetzt:

[nicodex]

Zitat:

Zitat von ryLIX

Wie muss ich mir den Inhalt von ABlock.Data vorstellen?

Als Folge von Bytes, deren Interpretation von der ID des Datensatzes abhängt.
(in diesem Fall ein little-endian Word, welches aus zwei Bytes zusammengesetzt wird)

Zitat:

Zitat von ryLIX

Hier wird nun Size übergeben. Aber von was? Von Data?

Ja.

Zitat:

Zitat von ryLIX

Bei der Implementation von ParseData() fehlt mir irgendwie noch der richtige Lösungsansatz.
Eine Fall Entscheidung mit case durch das mitgelieferte DataFormat ist nicht möglich da ein String nicht Ordinal ist.

case AFormat[x] of würde funktionieren.

Welche Delphi-Version verwendest du? Und in welchem Kontext sind die Dateien zu betrachten (nur für BMW oder auch andere Fahrzeuge, sind es allgemeine Datensätze oder gehören sie nur zu einer einzigen Software, ...)?

[ryLIX]

Zitat:

Zitat von nicodex

case AFormat[x] of würde funktionieren.

:wiejetzt:
Dann müsste ich AFormat als neues Arry erstellen richtig?
Bin gerade etwas verwirrt da ich heut als ablenkung Angefangen hab die Oberfläche der Software zu designen (es wird noch mehr gemacht als nur das Parsen).

Zitat:

Zitat von nicodex

Welche Delphi-Version verwendest du?

Turbo Delphi Explorer 2006

Zitat:

Zitat von nicodex

Und in welchem Kontext sind die Dateien zu betrachten (nur für BMW oder auch andere Fahrzeuge, sind es allgemeine Datensätze oder gehören sie nur zu einer einzigen Software, ...)?

Nur BMW, nur eine Software.

Es ist ein komplettes Softwarepaket von BMW.
Bei den hier verwendeten Daten geht es nur um die Codierdaten die in den Beispieldateien abgelegt sind die im ersten Beitrag angehängt sind.

Diese Teilen sich in eine feste Ordnerstruktur auf Sortiert nach Baureihe.

Code:

Hauptordner
-Data
--E* // Baureihe 'E'+ zwei Zahlen
---Codierdaten_Datei.C* // Die Dateiendung gibt den Codierindex vor also quasi die Softwareversion des Steuergerätes

Kurz noch was zur Funktion des Programms:
Sinn ist es erst einmal aus den Codierdateien die Möglichen Funktionen des Steuergerätes mit den dazugehörenden Parametern auszulesen und sortiert in Klartext darzustellen.
Speichern kann man alle zwischen Schritte des Parsens also Funktionsschlüsselwort Datei, Parameter Datei, Steuergeräte Datei und die Klartextanzeige.

Performance ist erst einmal Nebensache die Funktion steht im Vordergrund. Obwohl ich wohl das einlesen der Rohdaten auf TMemoryStream umstellen werde weil es auch so geplant war. Aber du hast da was fertiges geliefert also verwende ich das vorerst.

So genug geschrieben 8)
Wenn noch mehr Fragen sind nich zurück halten... mach ich ja auch nich :D

[nicodex]

Zitat:

Zitat von ryLIX

Aber du hast da was fertiges geliefert also verwende ich das vorerst.

Ich habe zu Hause noch eine Testversion mit TMemoryStream (mit unvollständigem Parser)... also wenn du noch etwas anderes zu tun hast, dann kannst du ja warten ;)

[ryLIX]

Joar versuche grad rauszufinden wie ich Zirkuläre Unit-Referenz umgehe bzw verhindere :roll:

Und dann muss ich noch mal den Textparser überarbeiten.
Das mit dem RegEx läuft zwar gut aber irgendwie zu langsam.

Es gibt viel zu tun also lassen wirs liegen oder wie war des noch? :mrgreen:

[ryLIX]

Zitat:

Zitat von nicodex

Zitat:

Zitat von ryLIX

Wie muss ich mir den Inhalt von ABlock.Data vorstellen?

Als Folge von Bytes, deren Interpretation von der ID des Datensatzes abhängt.
(in diesem Fall ein little-endian Word, welches aus zwei Bytes zusammengesetzt wird)

Ok das is mir nun klar aber warum wir um 8 Zeichen nach links versetzt?

[ryLIX]

Hmm niemand der mir das erklären kann :?
Lasst mich nicht dumm sterben :stupid:

[nicodex]

Zitat:

Zitat von ryLIX

Ok das is mir nun klar aber warum wir um 8 Zeichen nach links versetzt?

8 Bits (ein Byte), nicht 8 Zeichen.

[ryLIX]

Oh da habe ich wohl die Delphi Docu etwas missverstanden :roll:
Also springe ich da nur ein Byte zurück. Jetzt erscheint mir das ganze auch logischer :)
Hatte schon den Verdacht das es die Bitebene ist wo sich shl bewegt.

Ich hab mich in der Woche noch mal mit dem Hinweis auf AFormat[x] beschäftigt.
Aber irgendwie will mir da nicht die zündende Idee kommen.

Vielleicht denke ich auch in die falsche Richtung.
Die Buchstaben in DataFormat repräsentieren ja eigentlich Variablentypen.

Also müsste ich eigentlich jedem Buchstaben eine Zahl zuweisen um etwas ordinales zu erhalten.
Oder liege ich da falsch?
Somit müsste ich auch die an ParseData übergebenen Variablen oder Elemente ändern.
Zumindestens 1
Aber mir ich dann immer noch nicht klar wie ich die Daten da rein bekomme.

Wenn ich eine bestimmte Anzahl Bytes aus dem Array gelesen habe stehen diese dann im nächsten Durchlauf wieder zur verfügung oder wurden diese dann entfernt bzw verschoben ins Result bzw den Array aus dem Result später gebildet wird?

Bspw: ich lese aus dem Array die ersten 10 Bytes von der Startposition -1. Ist das Array dann im nöchsten Durchlauf um 11 Bytes kleiner?


Ich weiß viele Fragen aber ich hab mich mit dieser Art der Datenverarbeitung noch nicht sehr intensiv beschäftigt und durch deine kompetente Hilfe habe ich grad die Möglichkeit viel zu lernen :)

[ryLIX]

*bump*
:angel:

Jemand eine Idee?

Ich müsste ja ein Array erstellen wo ich jeder Variable einen Eintrag zuweise damit ich das dann abarbeiten kann.
Aber wie kann ich den String mit den enthaltenen Variablen so zerlegen das ich dann weiß was im case Angesprochen wird?

Code:

{L}LWW{B}(B)(A)B

Leider ist das keine Liste ...
Ich steck irgendwie fest :?

[ryLIX]

Ich hab irgendwie das Gefühl ich bin Betriebsblind.
Keiner da der mich ein wenig unterstützen kann?

[nicodex]

Zitat:

Zitat von ryLIX

Ich müsste ja ein Array erstellen wo ich jeder Variable einen Eintrag zuweise damit ich das dann abarbeiten kann.
Aber wie kann ich den String mit den enthaltenen Variablen so zerlegen das ich dann weiß was im case Angesprochen wird?

Code:

{L}LWW{B}(B)(A)B

Der Einfachheit halber würde ich den Datenblock in einen Stream schreiben, und hintereinander die Daten einlesen (L = LongWord, W = Word, B = Byte, S = #0-terminierter String). Der Aufwand liegt in der Gruppierung mit Klammern. Ich gehe davon aus, dass es sich bei (xyz) um eine Liste handelt - also dürfte selbige mit einer Anzahl beginnen (wahrscheinlich Byte). Damit man alles über einen Kamm scheren kann, kann man sich eine rekursive Funktion schreiben, die bei einem "(" die Länge liest, die entsprechende ")" sucht und den enthaltenen Ausdruck wieder mit dieser Funktion einliest. Dazu kann man sich beim Start eine Länge von 1 und () um den gesamten Ausdruck "denken".
Was {x} bedeutet kann ich nicht abschätzen, da in den von dir gelieferten Daten immer nur ein Wert enthalten ist (Können es mehrere sein? Und wenn ja, warum werden sie parallel zu () verwendet?).

[ryLIX]

Die Werte in den Klammern haben immer die gleiche Zeichen länge.
Was mir aufgefallen ist das Bytes ignoriert werden.
Als Beispiel:

Code:

141200| 01 00300000  00000000 0100 D602 0001 00 01 01 68 00 |8B
          {00003000},00000000,0001,02D6,{}, (00 01), {68},{}

Für mich sind später nur wenige Werte interessant.
Bei dem oben gezeigten Beispiel ist es ein FSW Parameter.
Daraus brauche ich nur den Wert

Code:

02D6

Denn damit kann ich in der Namesliste den entsprechenden Textwert suchen.
Aber ich muss trozdem alle Werte aus der Datei haben da die Namenslisten nach dem gleichen Schema aufgebaut sind.

Zu dem Stream habe ich noch eine Verständnisfrage:
Du meinst ja wahrscheinlich eine von TStreams abgeleitete Klasse wie TMemorystream.
Mit Datenblock meinst du den Inhalt von AData?

Dann bleibt ja immer noch das Problem zu erkennen um welche Kombination von Variablen es sich handelt.
Also müsste ich was haben womit ich abgleichen kann ob der String von AArgs in AFormat[x] ist.

Ca. so:

Delphi-Quellcode:

for x := 0 to AFormat.Count -1 do
if AArgs = AFormat[x] then begin

fall := x // geht des eigentlich? kann ich hier den index erfassen?
end;
end;
case fall do
1: Do.Something

2: Do.Something.else
end;