mytxt.dat, mytxt.bin
closed account (SECMoG1T)
I pretty much know of text files and use them oftenly, my question is based on a file I just came accross but I don't know of it mytxt.dat. what format is used to store data in them? How do I read to and from them?
I have heard of bin files, they store data in form of binaries, if I were to store mixed data such a strings and integers how would I differentiate between them when I extract them from the file, how would I know I have read the actual size of an int, double, string.
Help will be much appreciated.
I have heard of bin files, they store data in form of binaries, if I were to store mixed data such a strings and integers how would I differentiate between them when I extract them from the file, how would I know I have read the actual size of an int, double, string.
Help will be much appreciated.
In order to interpret binary data, you must know beforehand exactly what the format of the data is. Which is to say that you either need to examine the code which wrote the file and then reverse engineer a program to read it, or have a written format description which tells you how to interpret the data.
Is your mytxt.dat really a binary file? Are you sure that it is not a text data with different extension?
closed account (SECMoG1T)
@esslercuffi that would make some sense a little but well I have never used a bin file . How would I reverse engineer the binaries if I stored only strings separated by whitespaces if possible
@minnippa mytxt.dat is something I have never seen before, I was just wondering about these n I would really appreciate a hint on how they are used, format used to store data in them , what do they have offer to me , are they like text files?
@minnippa mytxt.dat is something I have never seen before, I was just wondering about these n I would really appreciate a hint on how they are used, format used to store data in them , what do they have offer to me , are they like text files?
Say you had a program which wrote a binary file, and in that file it wrote an integer, a null terminated string, then a double.
To read that file, you would have to write it so that the first sizeof(int) bytes were read into an int, then parse single bytes as characters until you reached a 0 (the null terminator), and then read in sizeof(double) bytes in to a double variable. That's what I mean when I say reverse engineer the program that wrote the file. Writing programs that read/write binary data can be problematic, in that data sizes for various types vary on different systems and implementations. That is, the actual size of an int can vary widely depending on which system and which compiler you use. Also, whether numeric types are big-endian or little-endian can be different.
I'm aware that most students will have to do binary file I/O for the purposes of exercises and assignments, but in most real systems, if data can be reasonably represented as characters, then you're probably much better off using character data in file I/O.
Nobody can really tell you how to read that .dat file, as .dat is not a standardized format. If you look at standardized formats for anything, you'll usually find they're mind-numbingly pedantic about what all the bits & bytes mean. Take a look at this spec for .png files. http://www.w3.org/TR/PNG/ You might get 4 pages in before all the bit diagrams and tables make you really consider coughing up hard cash for a decent library rather than writing all that bullshit yourself :)
To read that file, you would have to write it so that the first sizeof(int) bytes were read into an int, then parse single bytes as characters until you reached a 0 (the null terminator), and then read in sizeof(double) bytes in to a double variable. That's what I mean when I say reverse engineer the program that wrote the file. Writing programs that read/write binary data can be problematic, in that data sizes for various types vary on different systems and implementations. That is, the actual size of an int can vary widely depending on which system and which compiler you use. Also, whether numeric types are big-endian or little-endian can be different.
I'm aware that most students will have to do binary file I/O for the purposes of exercises and assignments, but in most real systems, if data can be reasonably represented as characters, then you're probably much better off using character data in file I/O.
Nobody can really tell you how to read that .dat file, as .dat is not a standardized format. If you look at standardized formats for anything, you'll usually find they're mind-numbingly pedantic about what all the bits & bytes mean. Take a look at this spec for .png files. http://www.w3.org/TR/PNG/ You might get 4 pages in before all the bit diagrams and tables make you really consider coughing up hard cash for a decent library rather than writing all that bullshit yourself :)
Last edited on
closed account (SECMoG1T)
Thanks guys for the help, so would it be better if I stick to my old text file , they are easy-to-use qnd do everything quite simple not much hassle.
Yeah, stick to text if you can. Only use binary for things which can't easily be expressed in text (images, video, audio, etc...)
Topic archived. No new replies allowed.