Reading Bytes Encoded by a C Program
Hi,
I have a C-Index database. If anybody is familiar with C-Index, it's a database created using C structures. Only a C program that knows the structure of the database can access it. C-Index encodes its database files to a particular binary file format (e.g. MyDatabase.dat). I wanted my Java program to read MyDatabase.dat. Is it possible to do so? If it is, where will I begin? I don't have any idea on where to start. Hope anyone can help.
Thanks in advance!
edgardolito
I suggest that you run a C program as an external program.
example:
import java.io.*;
import java.util.*;
public class CmdProcessBuilder {
public static void main(String args[])
throws InterruptedException,IOException
{
List<String> command = new ArrayList<String>();
command.add(System.getenv("windir") +"\\system32\\"+"tree.com");
command.add("/A");
ProcessBuilder builder = new ProcessBuilder(command);
Map<String, String> environ = builder.environment();
builder.directory(
new File(System.getenv("temp")));
System.out.println("Directory : " + System.getenv("temp") );
final Process process = builder.start();
InputStream is = process.getInputStream();
InputStreamReader isr = new InputStreamReader(is);
BufferedReader br = new BufferedReader(isr);
String line;
while ((line = br.readLine()) != null) {
System.out.println(line);
}
System.out.println("Program terminated!");
}
}
Thanks for the suggestion but what I want to do is to manually read the binary file and let Java analyze it by itself. I wanted to read the stream of bytes from the C-Index database file... and I don't know what to do next... X-(
do you have the C code that created this database file ?
Google will find you Java implementations.
yes java_2006. I have the code that created the database files.
sabre150: I've tried google. But this forum is my last resort.
I think that you should read this code and implement a java program to read .dat database. btw, do you have the C code to access the db and retrieve data ?
yes I have the code that can access/retrieve data. i am thinking of implementing JNI, but if there is a little bit more elegant way of implementing it without relying on the C code that created the database, it would be a little bit more better. hope there is another way. X-(
the only way I think is the best, is to convert the C to a Java code.Unfortunatelly, there is no good swiss tool to do it, but you can write it manually and if necessary, post questions in this forum.
I was thinking about how software tools like openoffice being able to understand/decode/encode files written in micro$oft office format. If they were able to decode a proprietary format, the big question is: HOW DID THEY DO THAT? How did their programs decode alien binary encodings?
> I was thinking about how software tools like
> openoffice being able to understand/decode/encode
> files written in micro$oft office format. If they
> were able to decode a proprietary format, the big
> question is: HOW DID THEY DO THAT? How did their
> programs decode alien binary encodings?
There is no "alien" - it's all just ones and zeroes. If the format has a specification, then you can write a program that will read and use that format in any language, C, Java, or APL.
If you don't have a specification, then it's harder - someone has to look at the hex, and guess at what the format might be. Once they've done lots of investigation, you're at the "you have a format" step. This is where things like POI come in - the POI guys spent a lot of effort figuring out what an Excel file's internals looked like, and wrapped an API around it. They chose to write in Java - coulda been in anything.
There is no Magic Microsoft Sauce that makes Excel files unreadable by anyone else - they're just baroque and twisted. To a program, it's all binary bits, that have some higher semantic meaning only to the degree some programmer assigns it.
In your case, you have a huge leg up on the POI guys - you have the C source that encoded the files. That means you know the format - you just have to write another program to decode it. The hard part isn't that the encoder is in C - the hard part is that you have to write the decoder.If the encoder was all you had, and you needed to write the decoder from scratch in C, it would be almost as hard.
Grant
Thanks for the comment Grant! In a way it's been a help. Now I know where to start - and it's grassroots. It's going to be bloody low level i guess. Thanks anyway!
