Omgaan met een onbekend file format

[Verwijderd]

Oud computer programma, nog net win32 gehaald, gebruikt door een bedrijf. Echter, de maker van het programma is al jaren gestopt en eindelijk wordt er in gezien dat overstappen naar een nieuw systeem (met support) een must is.

Nu is er een groot klantenbestand opgebouwd (>5600 klanten). Deze staan in een bestand klnt genaamd. Het bestand heeft geen extensie of iets dergelijks.
Nu heb ik het bestand eens geopend en kom daar duidelijk een file formaat tegen, alleen welke heb ik geen flauw idee van. De gegevens zijn wel keurig gestructureerd en deels leesbaar echter er zitten ook een hoop binaire tekens tussendoor.

In beginsel had ik het vermoeden dat het een pervasive sql bestand was, de bekende DBMgrv viewer gaf echter aan dat het een ongeldig bestand was.

Zijn er Tweakers die ervaring hebben met het omgaan met een onbekend file formaat ?
Misschien zien er stappen om toch een logische indeling van het bestand te achterhalen ?

[Sleepie]

Wilde gok natuurlijk, maar is het geen DB3 file ?

[j-w]

kun je het bestand niet openenen in de orginel app. en dan exporteren naar iets simples, CSV oid?

[Verwijderd]

Nee, geen export mogelijkheden in het programma

[Jazzy]

Misschien is het makkelijker meedenken als je vertelt welk programma het is. Of is het iets customs?

[TRON]

Open het bestand eens met een texteditor en plaats de eerst 10 karakters eens

Daar kunnen we meestal wel mee verder.

[Verwijderd]

Het is een custom app , de makers heb ik via via via opgespoord maar niemand weet waar de orginele source is terecht gekomen of welke programmeurs er destijds aan gewerkt hebben

[Verwijderd]

Sleepie schreef op vrijdag 21 oktober 2005 @ 15:41:
Wilde gok natuurlijk, maar is het geen DB3 file ?

Helaas, geprobeerd om een DB3 file te viewen .... unknown file format . .

[Rukapul]

Voor je het formaat gaat reverse engineeren (wat op zich mogelijk te doen is als het slechts een platte tabel is en je bovendien van minstens een record weet wat de waarde is van alle velden) lijkt het me zeer de moeite waard om de oude maker toch nog eens een belletje te geven.

Grote kans dat er standaard database support bij de toolkit/IDE zat waar het programma mee is gemaakt (te achterhalen via file properties van de executable en bijbehorende .dll's?).

Desnoods loop je door de executable heen voor herkenbare database termen waarop je kan googlen. Hetzelfde kun je doen met teken/hex reeksen in de header van het database bestand.

En toen bleek de ontwikkelaar z'n eigen yads (yet another database system) gemaakt te hebben In dat geval succes

edit: type en eens met de vele snelle suggesties hierboven

[ Voor 6% gewijzigd door Rukapul op 21-10-2005 15:49 ]

[Verwijderd]

Ik kom in de data directory wel wat DDF files tegen, ook staat er op de werkstations een versie van Pervasive SQL. Vandaar dat ik dacht dat het pervasive SQL files betrof.
Kunnen pervasive SQL files ook versleuteld zijn ?

BTW ik kan in het bestand wel velden herkennen, de velden zijn leesbare tekst...

[Freee!!]

Zoals je het beschrijft, klinkt het bijna als een bestand met wat tekstvelden en wat numerieke velden die op een ruimte-besparende manier zijn ingericht. Kijk eens met een hex-editor hoe die vreemde velden eruit zien.

In welke taal is het programma geschreven? Als het in COBOL is, kan ik waarschijnlijk het bestand zo decoderen.

[Verwijderd]

het programma is volgens mij in MS c++ geschreven, wanneer ik kijk naar de 'calls' van het programma bij opstart laad het ongeveer de hele MFC bibliotheek.

[Freee!!]

Sommige HLL compilers op de PC produceren C of C++ tussencode (en nog smerige ook).

[Speeder]

mmm, kan je het bestand niet importeren naar excel? Soms kan je een bestand met alleen plain-tekst er in gescheiden door andere tekens nl. importeren naar excel en dan aangeven wat de scheidingstekens zijn.

[Freee!!]

Speeder schreef op vrijdag 21 oktober 2005 @ 15:54:
mmm, kan je het bestand niet importeren naar excel? Soms kan je een bestand met alleen plain-tekst er in gescheiden door andere tekens nl. importeren naar excel en dan aangeven wat de scheidingstekens zijn.

Het bestand is niet alleen plain-text, lezen.

[leuk_he]

SOms is het type file te herkennen aan de eerste paar bytes. plaats eens een hexdump (ofzo) van de eerste 20 bytes. Als het met een tool gemaakt is hekent iemand die misschien.

Tja, en anders moet je met de hand reverse engineren, of je redirect de pinter output van een goede lijst naar een text bestand (text printer aanmaken) en filtert daar de info uit die je moet hebben.

[Rukapul]

Overigens: houd er rekening mee hoeveel dit je werkgever waard is. Een beetje uitzendkracht typet die 5600 records in een week makkelijk over (met een zekere errorrate). Dat geeft dus een beetje de bovengrens aan hoeveel tijd je er in zou moeten steken.

[Freee!!]

Inderdaad, ruim minder dan een week (de meeste uitzendkrachten voor dit soort klusjes kosten een stuk minder dan beter geschoold vast personeel).

[Speeder]

Mr. Liu schreef op vrijdag 21 oktober 2005 @ 15:55:
[...]

Het bestand is niet alleen plain-text, lezen.

Mja, wat zet ik er nou achter: er in gescheiden door andere tekens...

[Freee!!]

Speeder schreef op vrijdag 21 oktober 2005 @ 16:02:
[...]
Mja, wat zet ik er nou achter: er in gescheiden door andere tekens...

Uit de TS:

Verwijderd schreef op vrijdag 21 oktober 2005 @ 15:35:
<knip>
De gegevens zijn wel keurig gestructureerd en deels leesbaar echter er zitten ook een hoop binaire tekens tussendoor.
<knip>

Die hoop binaire tekens maken het dus allesbehalve plain-text.

[RobIII]

Mr. Liu schreef op vrijdag 21 oktober 2005 @ 16:04:
[...]

Uit de TS:

[...]

Die hoop binaire tekens maken het dus allesbehalve plain-text.

Dat kunnen natuurlijk ook gewoon "record separators" zijn ofzo van 1 of andere braque implementatie...

@TS: Post nou gewoon effe de eerste 10, 20 of 1024 bytes ofzo. Misschien dat wij iets herkennen?

[ Voor 16% gewijzigd door RobIII op 21-10-2005 16:14 ]

[Speeder]

Mr. Liu schreef op vrijdag 21 oktober 2005 @ 16:04:
[...]

Uit de TS:

[...]

Die hoop binaire tekens maken het dus allesbehalve plain-text.

Lees mijn zin nou eens nog een keer goed. Ik zet daar precies hetzelfde. Ik zal mijn stukje zin dan in ietwat andere woorden formuleren: alleen plain-text maar dan gescheiden door andere tekens.

[the_stickie]

een wilde gok hoor, maar heb je al eens geprobeerd het bestand te bekijken met een tool zoals Quickview plus?

[Freee!!]

RobIII schreef op vrijdag 21 oktober 2005 @ 16:10:
[...]
Dat kunnen natuurlijk ook gewoon "record separators" zijn ofzo van 1 of andere braque implementatie...

Speeder schreef op vrijdag 21 oktober 2005 @ 16:10:
[...]
Lees mijn zin nou eens nog een keer goed. Ik zet daar precies hetzelfde. Ik zal mijn stukje zin dan in ietwat andere woorden formuleren: alleen plain-text maar dan gescheiden door andere tekens.

Record-separators zijn over het algemeen één teken lang en voor het hele bestand hetzelfde. Ik begrijp uit de TS dat het meerdere tekens achter elkaar zijn en lang niet altijd dezelfde reeks.

Verder heb ik zelf al een paar keer met dit soort geintjes te maken gehad, dus ik denk dat ik echt wel weet waar ik het over heb.

[Verwijderd]

Hier zie je het begin stukje uit de hex viewer

code:

FCCcmÿÿÿÿÿÿÿÿÿÿÿÿrÿÿÿÿ!ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ}€€moë»Ç_/ÿÿ€_/€
_/
€:
€
5=#€

[Freee!!]

Dat is geen hex-code.

Edit:
Download de hex-editor eens van HHD Software en post een scherm-printje.

[ Voor 75% gewijzigd door Freee!! op 21-10-2005 16:19 ]

[RobIII]

Mr. Liu schreef op vrijdag 21 oktober 2005 @ 16:15:
Verder heb ik zelf al een paar keer met dit soort geintjes te maken gehad, dus ik denk dat ik echt wel weet waar ik het over heb.

Ik ook
Ik heb in mijn bijna 10 jarige carriere vele conversies van en naar vele bestandsformaten geschreven, en deed dat zelfs al voordat ik aan die carriere begon En ik heb dus ook heel wat brak spul gezien (Record seperators als ~@~ of <SEPA> of |@#(*&!@#@! om maar zeker te zijn dat de string nooit door "de gebruiker" werd ingevoerd... )
(Ik zeg dus niet dat je vermoeden niet klopte, ik had hetzelfde idee... maar je weet het pas zeker als je het kan zien). Gezien de eerste zoveel bytes die nu gepost zijn kun je dus inderdaad met grote zekerheid stellen dat het om een "binary file" gaat.

[ Voor 40% gewijzigd door RobIII op 21-10-2005 16:27 ]

[Freee!!]

RobIII schreef op vrijdag 21 oktober 2005 @ 16:19:
[...]
Ik ook
Ben al ruim 10 jaar programmeur en heb conversies van en naar vele bestandsformaten geschreven En ik heb heel wat brak spul gezien (Record seperators als ~@~ of <SEPA> of |@#(*&!@#@! om maar zeker te zijn dat de string nooit door "de gebruiker" werd ingevoerd... )
(Ik zeg dus niet dat je vermoeden niet klopte, ik had hetzelfde idee... maar je weet het pas zeker als je het kan zien).

Dat zijn inderdaad walgelijke separators. Mijn favoriete (op PC's tenminste) is nog steeds x"0D0A".

Gegeven de omschrijving in de TS en het ontbreken van numerieke gegevens daarin, denk ik dat die binaire data de numerieke gegevens betreft die als packed-decimal of iets dergelijks zijn opgeslagen om ruimte te besparen.

We zullen wel zien.

[Gerco]

Sommige oude apps kennende en aan de filename te ruiken, denk ik dat dit gewoon C structs zijn die verbatim naar schijf zijn gedumpt. Geen separators, gewoon vaste lengte records en de getallen zijn dan opgeslagen zoals ze in het geheugen staan.

Meestal is dat mis-of-meer makkelijk te ontcijferen, op de reference data na (magic numbers, verwijzingen naar andere tabellen, etc). De naam, adres, woonplaats info is meestal prima te achterhalen.

Om het zeker te weten zouden we een beetje data moeten hebben in een handzaam formaat (de eerste kilobyte van de file bijvoorbeeld, en dan niet uit een text editor gekopieerd )

[ Voor 17% gewijzigd door Gerco op 21-10-2005 16:31 ]

[Verwijderd]

Screenshotje:

[Verwijderd]

Ik heb wel is eerder met allerlei vage formaatjes gewerkt.

Als we het oude programma nog aan de praat kregen proberden we alles te printen naar een omgeleide lpt1: poort. We hadden dan alles alls platte tekst. Als daar een beetje een indeling in zat had je zo alles bij elkaar.

heb je MS Foxpro al geprobeerd daar werden toendertijd allerlei db progsels in gebakken.

doe is een dumpje van de laatse kilobyte

[ Voor 7% gewijzigd door Verwijderd op 21-10-2005 16:36 ]

[Gerco]

Je zou ook GNU File er eens naar kunnen laten kijken, die kan ook een hoop formaten ontcijferen. Het zal echter wel een vrij bekend formaat moeten zijn voor file het gaat snappen.

Start op met een knoppix cd en tik in een terminal:
# file /mnt/hda1/bestandje

Misschien is dit ook wel wat: GNU utilities for Win32

[ Voor 23% gewijzigd door Gerco op 21-10-2005 16:41 ]

[j-w]

Verwijderd schreef op vrijdag 21 oktober 2005 @ 16:34:
Ik heb wel is eerder met allerlei vage formaatjes gewerkt.

Als we het oude programma nog aan de praat kregen proberden we alles te printen naar een omgeleide lpt1: poort. We hadden dan alles alls platte tekst. Als daar een beetje een indeling in zat had je zo alles bij elkaar.

Dat is idd wel een heel goed idee.

Ik neem dat de oude app in ieder geval wel kon printen!

[TRON]

Verwijderd schreef op vrijdag 21 oktober 2005 @ 16:34:
Ik heb wel is eerder met allerlei vage formaatjes gewerkt.

Als we het oude programma nog aan de praat kregen proberden we alles te printen naar een omgeleide lpt1: poort. We hadden dan alles alls platte tekst. Als daar een beetje een indeling in zat had je zo alles bij elkaar.

heb je MS Foxpro al geprobeerd daar werden toendertijd allerlei db progsels in gebakken.

doe is een dumpje van de laatse kilobyte

'k Moet zeggen dat dit inderdaad als een leuke oplossing klinkt Het is de moeite waard om dit te proberen.

[Verwijderd]

probleem is alleen dat de print out van het programma super grafisch is (logo's , lijnen, boxen).. de geproduceerde file na de print is dus nog steeds alles behalve 'leesbaar'

[TRON]

Kan je een foto laten zien van een printje? (natuurlijk zonder belangrijke info te laten zien)

[leuk_he]

Verwijderd schreef op vrijdag 21 oktober 2005 @ 18:03:
probleem is alleen dat de print out van het programma super grafisch is (logo's , lijnen, boxen).. de geproduceerde file na de print is dus nog steeds alles behalve 'leesbaar'

Maak dan eens een windows "generic/text" printer aan en print het daar heen. Het was toch een windows app?

[Verwijderd]

Allereerst een nieuwe ontwikkeling
Wanneer ik het programma opende zag ik dat er een bestand werd gecreeerd, te weten mglock.dat .
Even googlen leerde mij dat mglock.dat een btrieve oplossing is voor het locken van de records.

Btrieve is tegenwoordig Pervasive SQL, na raadpleging van een Pervasive SQL expert kreeg ik het programma BUTIL.EXE, tooltje om betrieve files o.a. te dumpen. De ene foutmelding na de andere maar welke enkele juist geexporteerde records!

Zojuist krijg ik de gegevens uit de loon administratie van een voormalig programmeur.
Gebeld, hij bevestigde mij dat er inderdaad btrieve gebruikt werd echter met een door hun gemodificeerde header (waar hij nogal trots op was maar wat het nut was.... ).
Door nog een beetje te spelen met butil.exe kreeg ik wel een succesvolle dump.

Omdat jullie zoveel reacties gaven, waarvoor mijn dank, heb ik ook nog even gespeeld met de generieke text printer. Na installatie van deze printer, een print van het complete klantenbestand kreeg ik eveneens een goed leesbaar geheel!

Zo zit je met je handen in het haar en zo heb je een luxe probleem: wat is nu de eenvoudigste oplossing om te gebruiken Bedankt iedereen!