Einlesen einer FORTRAN Binärdatei mit Delphi

[Tenobaal]

Hallo,
für eine Studienarbeit soll ein altes Fortran77 Programm nach Pascal übersetzt werden (Entwicklungsumgebung ist RadStudio XE5).
Momentan hänge ich beim Einlesen von Datensätzen aus Binärdateien.
Zu Testzweck habe ich in Fortran eine Subroutine angelegt, die vier Integerwerte (NPUNKT,NPVAR,NZELLE,NSTR und KPER) in eine Binärdatei schreibt.
Es handelt sich um 32-Bit Integerzahlen, welche bei Fortran als Integer*4 definiert werden. Somit sollte der Fortran Integer*4 dem "normalen" Integer aus Pascal entsprechen!?!
Im nachfolgenden Code-Block ist der zugehörige Fortran-Code abgebildet.
Hinweis: NNET ist das Dateihandle. Das Öffnen und Schließen der Datei ist nicht Bestandteil der Subroutine OUTNET. Es geschieht an einer anderen Stelle im Programm.

Code:

      SUBROUTINE OUTNET
C**********************************************************************
C
C
C
C IMPLICIT
C
      IMPLICIT DOUBLE PRECISION (A-H,O-Z)
C
      COMMON /STEUER/ IERR,LIN,KPER,NPRINT,MPRINT,MAXP,MAXT,IRECH,IB2,
     ,                NSPG,NROT1,NROT2,NSTROM
      COMMON /TEXTE/  TITEL
      COMMON /NETZP/  NPMAX,NPUNKT,NPVAR,NZMAX,NZELLE,NSMAX,NSTR,MMAX
      COMMON /NETZD/  X(10000),Y(10000),A(10000),NUE(20000),SD(20000),
     ,                GAM(20000),
     ,                D(20000),GK(3,20000),NACHBZ(60000),ENDZ(10000),
     ,                NPER(10000),MGEB(20000),
     ,                ECKP(3,20000),RANDZ(3,20000),RANDS(3,20000),
     ,                AP(30000),EP(30000),GL(30000),GR(30000),
     ,                RAND(30000),ZL(30000),ZR(30000)
      COMMON /KONTUR/ GECKP(3,4000),IGECKP
      COMMON /IODEF / VERSIO,NTEST,IKART,NLIST,ND1,INET,NNET,NPLOT,
     ,                NUEPL
C
      DOUBLE PRECISION    NUE,GAM
      COMPLEX*16 A,SD
      CHARACTER*80 TITEL
      REAL*8 VERSIO
      INTEGER*4 NACHBZ,ENDZ,NPER,MGEB,ECKP,RANDZ,RANDS
      INTEGER*4 AP,EP,GL,GR,RAND,ZL,ZR
C
      WRITE (NNET) NPUNKT,NPVAR,NZELLE,NSTR,KPER
C
      RETURN
      END

Nun habe ich mit Delphi eine Prozedure geschrieben, die die erzeugte Fortran Binärdatei einlesen soll. Dabei entsteht allerdings nur Datensalat.
Zuvor habe ich schon mit der Klasse TFileStream gearbeitet und konnte erfolgreich Binärdateien anlegen und einlesen.:wink:
Ich vermute daher, dass Fortran die Binärdatei anders strukturiert? Im Internet konnte ich keine Informationen dazu finden.

MFG Tenobaal

Delphi-Quellcode:

procedure TNetgen.ReadNet(Directory,Filename:String);
var
  Stream:TFileStream;
Begin
Stream:=TFileStream.Create(Directory+Filename+'.NET',fmOpenRead);
try
  try
    //NPUNKT,NPVAR,NZELLE,NSTR,KPER sind vom Datentyp Integer
    Stream.Read(NPUNKT,SizeOf(NPUNKT));
    Stream.Read(NPVAR,SizeOf(NPVAR));
    Stream.Read(NZELLE,SizeOf(NZELLE));
    Stream.Read(NSTR,SizeOf(NSTR));
    Stream.Read(KPER,SizeOf(KPER));
  except
    on E: Exception do
      begin
      ErrorMessagesINOUT.Add('Fehler beim anlegen der Netzdatei ('+Filename+'.NET)');
      ErrorMessagesINOUT.Add(E.ClassName+' Fehler aufgetreten mit Nachricht : '+E.Message);
      end;
  end;
finally
  Stream.Free;
end;

End;

[Der schöne Günther]

Zitat:

Zitat von Tenobaal (Beitrag 1265653)

Es handelt sich um 32-Bit Integerzahlen, welche bei Fortran als Integer*4 definiert werden. Somit sollte der Fortran Integer*4 dem "normalen" Integer aus Pascal entsprechen!?!

Ich habe noch nie was mit Fortran gemacht, aber eine Suche nach "Fortran integer range" sieht mir eher danach aus, als sei der Typ INTEGER einfach nur ein Byte mit Vorzeichen? INTEGER*4 demnach 32 Bit.

[Mavarik]

Also... Ich mache sowas immer so:

Delphi-Quellcode:

{$A1} // Wichtig

Const
   Recordlaenge = 2245; // Filesize / Recordlaenge passt!

type
    TStruct = Record
                A    : Byte; // Bin ich mir sicher
                B    : Word; // Bin ich mir sicher
                C    : Byte; // Bin ich mir sicher
                Rest : Array[1..Recordlaenge-4 {Sizeof A-C} ] of Byte;
              end;
var
  F : File;

Procedure Readit;
var
  Struct : TStruct;
begin
  Assignfile(F,'Bla.dat');
  Reset(F,1);
  Blockread(F,Struct,sizeof(Struct));
  Closefile(F);
end;

So kannst Du schön mit dem Debugger durch gehen und im ganz schnell alles ändern.

Mavarik

[Tenobaal]

Ich habe mit Delphi und Fortran jweils die Integerzahl "735" (Dezimal) in eine Binärdatei geschrieben. Beide Dateien wurden dann mit nem Hex-Editor geöffnet.

Fortran:

Code:

04 DF 02 00 00 04

Delphi:

Code:

DF 02 00 00

Ich habe zuvor noch nie mit einem Hex-Editor gearbeitet :oops: ,aber meine "735" Dezimal entspricht 2DF (Hex). 2DF steht allerdings in keiner der Dateien :shock:
Abgesehen davon, ist im Fortran-Code am Anfang und am Ende jeweils zusätzlich ein '04' (Hex) vorhanden. Laut ASCII-Tabelle bedeutet dies dem Zeichen 'EOT' - End of Transmission.
Ich versuche mal die Position beim lesen der Datei zu verändern, sodass meine Delphi Prozedur erst beim 2 Byte anfängt die Daten zu lesen.

[Der schöne Günther]

Deine 00 00 02 DF ist doch die DF 02 00 00, nur zweimal umgedreht, oder?

(00 00) (02 DF) -> (02 DF) (00 00) -> (DF 02) (00 00)

[Tenobaal]

Problem gelöst. Ich habe "Stream.Position:=1;" vor den ersten Read-Befehl meiner Delphi Prozedur gehangen, damit erst ab dem 2 Byte gelesen wird :lol:

[Uwe Raabe]

Zitat:

Zitat von Tenobaal (Beitrag 1265666)

Problem gelöst. Ich habe "Stream.Position:=1;" vor den ersten Read-Befehl meiner Delphi Prozedur gehangen, damit erst ab dem 2 Byte gelesen wird :lol:

Das sieht mir aber nicht nach einer generellen Lösung aus. Zeig doch mal den Hexdump der gesamten Fortran-Datei oder hänge sie hier an.

[Tenobaal]

War auch zu früh gefreut. Bei mehreren Datentypen in der Binärdatei funktioniert die Lösung nicht mehr. Scheinbar werden weitere EOT-Zeichen wahllos eingestreut :wink:

[Klaus01]

.. kann es sein, dass jedes Integer*4 Datenfeld mit 04 beginnt oder ist es ein Feldtrenner?

Code:

04 DF 02 00 00 04

Anhand der wenigen Daten ist das schwer zu erkennen.

Grüße
Klaus

[Uwe Raabe]

Zitat:

Zitat von Tenobaal (Beitrag 1265692)

Scheinbar werden weitere EOT-Zeichen wahllos eingestreut :wink:

Na eben nicht wahllos! Aber wir können anhand der gezeigten sechs Bytes natürlich auch nur was ahnen.