On Wed, 2004-10-27 at 23:19, Jim wrote:
>
> > Have any backups? Paper reports?
> >
> > If all else fails, you could always hire some interns and
> > turn it into a massive data [re-]entry project, provided that
> > a paper trail exists...
> >
>
> LOL! If I don't figure it out tonight, gonna
> > Tried that and also tried the unix strings command. No help
>
> I didn't mean to suggest that it would be *easy*, but at this
> point I think your only way of getting any traction -- short
> of getting the vendor to help you or getting your new vendor
> to take a look -- is to just sit do
>
> Does "strings file" give you any clues?
>
nope, just the ascii header I already know about. I just downloaded a ultra
edit, I will see what that does
[EMAIL PROTECTED] ~]$ strings LPAS188.RED | more
2004 by Mortgage Information Corp, San Francisco, CA
2004080
00Prime ERED MARKET
65533
1
On Wed, 27 Oct 2004, Jim wrote:
> > At that point, the next recourse I can think of is to open up
> > the file in a good hex editor (or a text editor that won't
> > mangle things up like Vim or Emacs) and see if you can puzzle
> > out any patterns.
>
> Tried that and also tried the unix string
> There are a lot of different versions of the magic number
> database floating around out there, but if the file format
> you're dealing with is some kind of weird proprietary thing,
> then you may be stuck...
Yea, I am getting that feeling :(
>
> At that point, the next recourse I can thi
On Wed, 27 Oct 2004 17:59:39 -0400
"Jim" <[EMAIL PROTECTED]> wrote:
>
> > Any ideas where to start? Generally I try and determine
> > record size and delimiter first. Are they fixed length
> > records? newline or null delimited? CSV ??
> >
> > more input.
> >
>
> I have no idea. It does n
> Any ideas where to start? Generally I try and determine
> record size and delimiter first. Are they fixed length
> records? newline or null delimited? CSV ??
>
> more input.
>
I have no idea. It does not seem to be newline delimited (. Is there some
trick to try to determine the record s
> If you do manage to find out the file contains some sort of "standard"
> binary format per the 'file' command, you can also visit
> http://www.wotsit.org/ which contains "very detailed"
> information about the binary structure for hundreds of
> different known file formats.
>
Nice link.
Un
>
> The best place to start is with the `file` command, and the
> magic numbers behind it, which not nearly enough people know
> about these days.
Hi
Sorry to so long to post back. I did not have access to the list today at
work
I should have mentioned, I tried unix file command and it only r
>
> > I have a binary file that I have been tasked to discover
> the format of
> > and somehow convert the records to readable text. Is there
> any way I
> > can find out what binary format the file is in, so I can create an
> > template for unpack() to convert the binary to text?
>
> The be
Assuming the file isn't some known standard which is discovered by interrogating
the header (ala unix 'file ') you will need to understand the
format of the
file before we can help defined an unpack template.
Any ideas where to start? Generally I try and determine record size
and delimiter
first.
On Tue, 26 Oct 2004, Jim wrote:
> I have a binary file that I have been tasked to discover the format of
> and somehow convert the records to readable text. Is there any way I
> can find out what binary format the file is in, so I can create an
> template for unpack() to convert the binary to t
Hi
I have a binary file that I have been tasked to discover the format of and
somehow convert the records to readable text. Is there any way I can find
out what binary format the file is in, so I can create an template for
unpack() to convert the binary to text?
Thanks
Jim
---
Outgoing mail is
13 matches
Mail list logo
