Unterschiede der DBF Arten

[Manfred]

Ich hatte in einem anderen Thread eine PDF hochgeladen, in dem es um die Erkennung von DBF Dateien geht mittels Auslesen des Headers.
Dazu hätte ich aber noch ein paar Fragen:

Code: Alles auswählen

METHOD datenbank:pruefeDbEngine(cFileName)
       LOCAL cBytes    := Space(30)
       LOCAL cDBEDatei := ""
       LOCAL nHandle

       IF File(cFileName)
          nHandle := FOpen(cFileName,FO_EXCLUSIVE)
          IF nHandle > 0
             FSeek(nHandle, 0, FS_SET)
             FRead(nHandle,@cBytes,Len(cBytes))
             IF cBytes[1] $ Chr(0x02)     // FoxBase
                cDbeDatei := "1"
             ELSEIF cBytes[1] $ Chr(0x03) // FoxBase+/dBase3+ ohne Memo
                cDbeDatei := "2"
             ELSEIF cBytes[1] $ Chr(0x30) // VisualFoxPro
                cDbeDatei := "3"
             ELSEIF cBytes[1] $ Chr(0x31) // Visual FoxPro mit Autoincrement
                cDbeDatei := "4"
             ELSEIF cBytes[1] $ Chr(0xF5) // das ist eine FoxPro mit Memo
                cDbeDatei := "FOXCDX"
             ELSEIF cBytes[1] $ Chr(0x83) // FoxBase+/dBase3+ mit Memo
                cDbeDatei := "6"
             ELSE
                ::cDbe := "DBFNTX"
                ::lNeueDbErzeugen := .T.
             ENDIF
          ENDIF
          FClose(nHandle)
       ENDIF
RETURN self

wo liegt denn z.B. der Unterschied zwischen Foxbase, Dbase3+ und FoxPro? Ist FoxBase und dBase3+ das gleiche Format?

[brandelh]

Im Prinzip ja

Der Header verwendet einige der bisher reservierte Bytes für Zusatzinfos,
man kann andere Typen von Feldern anlegen und die Memodatei wird besser verwaltet.

Aber im Prinzip (Header mit Infos gefolgt von Feldinfos gefolgt von Daten im "Textformat" hat sich nix geändert.

Wobei Foxbase ... kenn ich jetzt nicht.

Kompatibel sind sie aber nicht untereinander (die FOXDBE gleicht Unterschiede aus).

[Jan]

FoxBase ist FoxPro, bevor das von MS übernommen wurde.

Jan

[Jan]

Manfred,

als Ergänzung zu Deinem Byte-Auslesen oben: Wenn ich das richtig ausprobiert habe dann ist Byte 30 das, was Xbase++ angibt für ASCII und ANSI. Wobei dann 02 = ASCII und 03 = ANSI beduetet.

Das dürfte aber nur interessant sein um festzustellen, ob eine dbf ASCII oder ANSI ist. Denn das korrekte Erstellen einer dbf in ASCII/ANSI macht Xbase++ ja alleine, wie Tom vergangene Woche in dem entsprechenden Thread auf meine Frage klargestellt hatte.

Jan

[HaPe]

Code: Alles auswählen

 ... ist Byte 30 das, was Xbase++ angibt für ASCII und ANSI. Wobei dann 02 = ASCII und 03 = ANSI beduetet.

Oder anders ausgedrückt:
0 = Keine CodePage-Markierung
1 = MS-DOS, USA
2 = MS-DOS, International
3 = Windows, USA und West-Europa
4 = Macintosh, USA
...

[brandelh]

hier habe ich mal dazu eine Klasse veröffentlicht:

http://www.xbaseforum.de/viewtopic.php?f=16&t=2313

[Manfred]

aber so wie ich das vorhin bei mir einmal getestet habe, nutzt das alles nichts. Ich war eigentlich der Meinung, dass ich über diesen Weg prüfen kann, ob ich eine DBF von OEM auf ANSI konvertieren muß. Das klappt aber alles nicht. Es geht in meinem Fall um die Umlaute. Die sind falsch obwohl die DBF das ANSI Merkmal drin stehen hat. Irgendwas ist da vor langer Zeit mal schief gelaufen und mir qualmt jetzt der Kopf.

[brandelh]

wie gesagt, AmiPro hat normale DBF Dateien (nix Foxpro) einfach mit Ansi Texten geschrieben ...
das machen andere eventuell auch.

[Jan]

Manfred,

es kann da einen Fehler gegeben haben: Man nehme eine dbf mit Byte 30 = 02 = ASCII. Und fülle das Feld mit ConvToAnsiCP(cWert). Dann ist die dbf ASCII, der Feldinhalt aber verkrüppelt.

Ich würde mal einen Hex-Editor nehmen und nachsehen, was genau in dem Byte mit dem Umlaut drin steht. Ist die dbf ASACII, der Umlaut aber ANSI-Codiert, dann müsstest Du die dbf vermutlich erstmal wieder Feld für Feld zurück-konvertieren.

Jan

[Manfred]

das befürchte ich auch. Wattn Mist.

[Tom]

Wenn man in einer OEM-Anwendung einen String hat und den in einer OEM-Tabelle mit ConvToAnsiCP() speichert, dann ist dieser String in OEM, aber es hat eine Zeichenersetzung stattgefunden. Die DBE kann ja nicht wissen, wie der String richtig wäre - es wird immer konvertiert. Eine mit ConvToAnsiCP() gereichte Zeichenkette wird dennoch als OEM interpretiert, wenn alle Schalter so stehen (also in diesem Fall zweimal nach ANSI konvertiert). Diese Funktionen sollte man tunlichst nicht hierfür verwenden; sie sind nur dann wirklich sinnvoll, wenn man Low Level Dateien erzeugt (also z.B. eine ANSI-Textdatei aus einer OEM-Anwendung heraus schreiben will) oder mit 3rd-Party-DLLs redet, die nicht in Xbase geschrieben und statisch gelinkt sind (für eXpress++ beispielsweise muss man NICHT konvertieren, da die Libs statisch gelinkt werden und die CHARSET-Schalterstellungen kennen). Beim Umgang mit Tabellen sind sie in aller Regel nicht hilfreich, außer, man hat sie bereits einmal auf die Tabelle angewendet. Ob dann allerdings wieder das gleiche bei rauskommt, wenn man zurückkonvertiert, hängt sehr davon ab, in welchem Bereich sich die Zeichenwerte bewegt haben. ANSI -> OEM -> ANSI erzeugt nicht immer die Ausgangswerte. Die Zuordnungen sind nicht eindeutig. Ganz haarig wird es, wenn zweimal nach ANSI konvertiert wurde (oder umgekehrt). Das dürfte hier der Fall sein.

[HaPe]

Code: Alles auswählen

Ist die dbf ASACII, der Umlaut aber ANSI-Codiert, dann müsstest Du die dbf vermutlich erstmal wieder Feld für Feld zurück-konvertieren.

das befürchte ich auch. Wattn Mist.

Wenn ich das richtig verstanden habe, geht es Manfred um die Umlaute.

Mit meinem Editor (Semware Editor) kann ich in einer DBF auf einen Rutsch die Umlaute von ANSI nach ASCII und umgekehrt umsetzen.
Dabei wird umgesetzt:
Ä <=> CHR(196)
Ö <=> CHR(214)
Ü <=> CHR(220)
ä <=> CHR(228)
ö <=> CHR(246)
ü <=> CHR(252)
ß <=> CHR(223)

Damit habe ich immer dBase IV/V-Tabellen (von DOS) nach FoxPro (Windows) umgesetzt.

Hier sind die Zeichensatz-Tabellen sehr gut beschrieben: https://de.wikipedia.org/wiki/Zeichensatztabelle

[AUGE_OHR]

wie gesagt, AmiPro hat normale DBF Dateien (nix Foxpro) einfach mit Ansi Texten geschrieben ...
das machen andere eventuell auch.

JA ... PHP-BBs auch ...

ANSI oder OEM macht keinen Unterschied solange die Zeichen < 128 sind.
für die Amis ist "ihr" OEM für uns gleich ANSI. erst mit den deutschen Sonderzeichen > 128 wird es interessant ... und das "verstehen" einige amerikanische Programme eben nicht.

p.s. ich speichere chinesische Zeichen in einer OEM und "konvertiere" mit der Codepage !