Zeichensatz in dbf [Erledigt]

[Jan]

Hallo,

zur Zeit bin ich etwas irritiert. Bei einem Kunden gibt es mehrere dutzend dbf, die sind alle FOXCDX. Manche der dbf sind schon uralt, andere erst relaiv neu erstellt, manche der neueren auch von anderen Entwicklern. Wenn ich die dbf mit einem Datenbanktool (VDBU von DS-Datasoft) öffne, sehen die alle OK aus. Alle Umlaute werden korrekt dargestellt. Öffne ich die aber mit einem Hex-Editor, dann sind in manchen der dbf die Umlaute falsch dargestellt, in manchen korrekt. Ich habe das immer darauf geschoben, das einige dbf aus welchem Grund auch immer ANSI sind, andere OEM. Die meisten der neueren dbf scheinen ANSI zu sein, die uralten zum Großteil OEM.

Ich habe mir also eine kleine Routine geschrieben, die die OEM-dbf nimmt und in andere dbf umkopiert, und hierbei alle Inhalte von Text- und Memo-Feldern nach ANSI konvertiert.

Im Hex-Editor sieht das jetzt sauber aus. Im Datenbanktool jetzt aber falsch! Wie ANSI nochmal nach ANSI konvertiert.

Was mich ebenfalls irritiert: Warum werden in den Programmen, die alle ohne ein SET CHARSET TO laufen, alle Datenbankinhalte korrekt dargestellt? Egal ob nun OEM oder ANSI? Es gibt ja kein Byte in den dbf das aussagt, ob die nun OEM oder ANSI sind. Und das Xbase++ auslesen könnte um das korrekt zu interpretieren.

Jan

[brandelh]

Es gibt solche Bytes

Allerdings sind die bei DBFNTX nicht standardkonform, bei FOX DBFs müsste das aber schon ein Standard sein.
Das Problem bei Xbase++ ist dass er diese Regelung beim Anlegen als "automatik" macht und man nicht per parameter steuern kann was man will.

DBFDBE_ANSI a .F. L Ist die Einstellung .T., wird für
DBF/DBT-Dateien das ANSI-Format verwendet

Irgendwo habe ich auch noch rumliegen welches Byte das war (21 oder so) ...

Das erste mir bekannte Programm, das DBF Dateien mit ANSI Zeichensatz nutze war AmiPro

[Manfred]

Byte 12-27 steht reserviert.

ich habe mal eine Liste angefügt, die mir weitergeholfen hat.

[Tom]

FOX-Tabellen sind ANSI oder OEM. Wenn sie in Xbase++ erzeugt werden, entscheidet die Einstellung von SET CHARSET, die im Moment der Erzeugung aktiv war, darüber, ob es sich um das eine oder andere handelt. Eine OEM-DBF wird nicht zur ANSI-DBF, indem man die Strings mit ConvToAnsiCP() konvertiert! Eine OEM-DBF wird zur ANSI-DBF, indem man mit SET CHARSET TO ANSI eine DBF erzeugt und in diese die Daten aus der alten Tabelle kopiert. Wichtig ist, dass die neue Tabelle mit DbCreate() erzeugt wird - und nicht mit COPY TO oder so. Eine OEM-DBF bleibt so lange eine OEM-DBF, wie sie lebt. Die Schalterstellung von SET CHARSET ist hier unerheblich; die DBE sorgt immer für die richtige Konvertierung.

[Jan]

Hallo Tom,

um ehrlich zu sine - ungefähr das war auch mein Grundgedanke. Aber da nirgends zu erfahren war wie ich erkenne, ob eine DBF nun OEM oder ANSI ist, hatte ich das wieder verworfen. Und einfach mit dem Hex-Editor nachgesehen, was denn nun in der DBF drin stand.

Stellt sich dann also noch die Frage: Wie kopiere ich das nach ANSI um? Ich kann ja leider nicht angeben, das ein Programm zwsichen SET CHARSET TO ANSI oder OEM umswitcht (oder doch???). Also erstmal alle dbf neu erstellen mit SET CHARSET TO ANSI, und dann mit einem Programm ohne diese Einstellung die Daten rüber kopieren?

Jan

[Jan]

Ich hab jetzt mal den Gedanken von Tom aufgegriffen. Alle dbf die Struktur ausgeklesen und mit SET CHARSET TO ANSI neue dbf erstellt. Dann die Inhalte rüber kopiert, ebenfalls mit SET CHARSET TO ANSI. Das sieht in der neuen dbf erstmal sauber aus, sowohl mit VDBU als auch mit Hex-Editor.

VDBU behauptet bei beiden Versionen, die wären OEM.

Der Hexeditor macht an Pos. 30 einen Unterschied: Die alten dbf haben da eine 02, die neuen eine 03. Wobei 30 und 31 lt. Doku reserviert sind. Für was auch immer.

Das scheint also der richtige Weg zu sein. Warum einfach wenn es auch kompliziert geht ... oder andersrum ...

Danke Tom für den Hinweis. Und all den anderen für ihre Ideen zu dem Thema.

Jan

[Tom]

Hallo, Jan.

SET CHARSET beeinflusst bestehende Tabellen nicht. Wenn eine Tabelle mit OEM erzeugt wurde, Deine Software aber auf ANSI steht, konvertiert die DBE. Wenn Deine Software auf OEM steht, konvertiert sie nicht - es sei denn, die Tabelle ist in ANSI. Du kannst natürlich jederzeit umschalten, solltest aber in den "natürlichen" Zustand zurückkehren, weil sonst Deine GUI und die Interaktion mit Fremd-DLLs Schaden nehmen kann. Hierfür ist übrigens völlig unerheblich, ob Dein Quellcode in ANSI oder OEM vorliegt.

Also. Du hast eine Tabelle, die in OEM erzeugt wurde. Du holst Dir die Struktur, schaltest, insofern das nicht standardmäßig der Fall ist, den Zeichensatz auf ANSI, und erzeugst die neue Tabelle. Du kannst auf ANSI bleiben, während die Daten umkopiert werden. Danach kehrst Du, insofern nötig, auf OEM zurück. Wenn die Software sowieso mit ANSI arbeitet, musst Du überhaupt nichts tun. Die neue FOX-DBF wird automatisch in ANSI sein, wenn sie in der Sofware erzeugt wird. Die Daten aus der OEM-Tabelle werden korrekt konvertiert.

[HaPe]

Hallo Zusammen !

IN VFP-Tabellen kann man mittels CPZero.prg das CodePage-Byte anpassen/einstellen.

In der PDF gibts eine Doku der VFP-Header-Beschreibung und anschließend den Quellcode von CPZero.

http://www.schwaben-team.de/downloads/d ... cpzero.pdf

Vielleicht bringt das noch weiteres Licht ins Dunkel

[brandelh]

Stellt sich dann also noch die Frage: Wie kopiere ich das nach ANSI um?
Ich kann ja leider nicht angeben, das ein Programm zwsichen SET CHARSET TO ANSI oder OEM umswitcht (oder doch???).

VOR der Erstellung kannst du natürlich mit SET CHARSET schnell umstellen und danach zurücksetzen !

Das schreiben von ANSI Daten (mit Funktionen) in eine OEM-DBF funktioniert deshalb nicht, weil ja die DBE mit einer Art rechnet und diese konvertiert ...
Alles was zusätzlich konvertiert, führt im Schlimmsten Fall zu Datenmüll.