forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Suggestion for a binary file reader

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1803
Location: Sydney

PostPosted: Sat Sep 24, 2016 7:53 am    Post subject: Reply with quote

I am not sure I understand your request.

Briefly, a binary file consists of groups of bytes that are basically memory images.
These groups of bytes can be enclosed in a header and footer ( 1, 4 or 5 bytes long) to describe the size of each record, but not always.
The memory image can be of any variable type, eg 4 byte integers, 8 byte reals or a character string.
For real or integer variables, the byte order is important ( big or little endian )

The two main forms of Fortran binary files are:
1) Unformatted sequential access files, which have a record header and trailer. FTN95 header syntax (1 byte for small, 5 byte for large records) is different from most other compilers, that use 4 bytes.
2) direct access fixed length binary files, which have no header/trailer info, are simply a memory image.

If written with Fortran, the memory image is based on the I/O variable list in the WRITE statement.

Importantly you need some knowledge of the data and record structure.

You can open the file for stream I/O (FTN95 access='transparent') to interrogate the file information, but an idea of the data is most important.

The best place to start with FTN95 is to use access='TRANSPARENT' to read files one byte at a time and have some files of known structure to review.

My preference is to use binary files when transferring information between closely related programs only.

If I want to transfer data between different packages or computers, I always use a text file which has a simple structure. One useful approach is that if you are providing a list of numbers, first provide the count, as this allows the program reading to first allocate a known space to read the data.
Also, make each line of text short; lots of <CR> <LF> will not flood a modern disk.
Use formats that provide adequate precision. The following always works:

write (lu,*) '#TITLE it is good to give each group of data a title that can be skipped when read'
write (lu,*) n
do I = 1,n
write (lu,*) a(I)
end do
write (lu,*) ' ' ! ending with a blank line also helps clarity

A text file is easy to look at to check what is in the file and so easy to then write a program to read.

Hopefully this answers some of your question.


Last edited by JohnCampbell on Sun Sep 25, 2016 3:50 am; edited 2 times in total
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 594

PostPosted: Sat Sep 24, 2016 10:34 am    Post subject: Reply with quote

I'm totally with you John on the 'ascii is best 'cause you can see it' philosophy, the only problem possibly being when the files are large becasue they use up much more disc space no?

I guess it's difficult to give a specific guidance unless newuserftn can give an example of the data format he's trying to read.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1668
Location: Yateley, Hants, UK

PostPosted: Sat Sep 24, 2016 11:07 am    Post subject: Reply with quote

I didn't understand the request, because you could easily write a couple of programs to write a file and read it back - or even do it in the same program.

ASCII might be readable, but it is very accessible to a user, who can quickly make it unreadable.

As to length, that depends. A single digit is one byte, but that could be read into a REAL*8 or INTEGER*8, which are 8 bytes. I'm not sure that file length is much of an issue on most computers, nor indeed is there much of an issue in speed of reading or writing formatted v. unformatted for most practical purposes.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 594

PostPosted: Sat Sep 24, 2016 12:04 pm    Post subject: Reply with quote

... oh your comment about ASCII REadable files is so true Eddie, reminds me of the old tried and tested adage ...

Quote:
"When it comees to input data, don't trust ANYONE, not even your Grandma !!! " ... oh, and especially NOT YOURSELF !!!


LOL
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 383
Location: Morrison, CO

PostPosted: Mon Sep 26, 2016 4:16 pm    Post subject: Reply with quote

I'm not usre I fully understand what you are needing, but here's an alternative.

A text editor that can also read (and update!) binary files is EditPad (from Just Great Software). I've used this for years, and am very pleased with it for editing ASCII files of all kinds AND for it's ability to display and edit binary files.

When debugging/viewing binary files, you can "drag-and-drop" them into the editor. It will recognize that the file is binary and show you the file as hexadecimal data on the left and character representation on the right (a lot like many DUMP utilities). You can change the data (edit or add in hex) or delete data. It is the ability to change the data that I've found useful when I've had a programming issue and needed to edit the file slightly, or to introduce an error in a data file.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group