ClientDataSet mit XML und UTF8

[Redeemer]

Was soll dieses UTF8ToString bringen (außer dass sich der Compiler zurecht darüber beschwert)? Da ist weit und breit kein UTF-8 in dem Programm, du verwendest ausschließlich WideStrings und UTF-8 kommt standardmäßig in Delphi-Anwendungen überhaupt nicht vor. Das ergibt doch überhaupt keinen Sinn und ohne das funktioniert das Programm dann auch vernünftig. Zumindest unter D2009. Das entsprechende Kompilat ist angehängt. Einzige Änderung ist das Entfernen von UTF8ToString in der einen Zeile und das Entfernen von Namespaces, da D2009 so gut wie keine Namespaces kennt.

/Edit: Ups, falscher Anhang (war das fehlerhafte Programm).

[urdelphist]

Naja, im Programm kommt es nicht vor, aber in der XML-Datei, die zu importieren ist.

BTW, mein Screenshot mit exakt denselben Daten sieht etwas anders aus. Wenn konvertiert wird, ist die Ansicht teilweise korrekt, aber eben nicht immer, siehe oben.

[urdelphist]

und nochmal: die Zeichenketten, die die Datenelemente des ClientDataSet repräsentieren, sind vom Typ AnsiString. Vielleicht ist das bei D2009 ja anders.
Insofern macht die Konvertierung von UTF8 nach Ansi sehr wohl Sinn.

UTF8ToString wird ja beim Laden nicht benutzt. Einzig dann, wenn über den Button2 eine Knovertierung versucht werden soll.

Wie man am Screenshot erkennen kann, klappt selbst das unkonvertierte Einlesen überhaupt nicht.
Dein Erfolgsfall wird wohl an der Delphi Version liegen.

[urdelphist]

@Redeemer:

Bitte schau doch mal nach, welchen Typ die ClientDataSet Datenelemente haben, also zum Beispiel "ClientDataSet1company". Dieses ist hier vom Typ TStringField, welches die Eigenschaft Value vom Typ AnsiString hat. Wenn es bei D2009 als WideString definiert ist, könnte ich die VCL eventuell anpassen. Wobei das ziemlich umständlich werden könnte, weil da etliche Dateien von abhängen, die im Interface als Antwort AnsiString erwarten.

[Redeemer]

Das ist auch in D2009 ein AnsiString. Daher können Nicht-Ansi-Zeichen auch nicht angezeigt werden. Die vorliegende XML-Datei enthält nur ANSI-Zeichen.
Ist ja schön, dass die XML in UTF-8 ist, aber das Programm hat mit der XML-Datei doch überhaupt nichts am Hut. Das wird irgendwie vom XMLTransformProvider1 gehandelt, wie interessiert einen nicht. Du solltest eher mal schauen, wie man das Teil dazu kriegt, UTF-8 zu unterstützen. In Delphi 2009 funktioniert das sofort. Da die entsprechenden Komponenten aber nicht Unicode-fähig sind, kannst du natürlich auch die XML in ANSI abspeichern...

[urdelphist]

Hm, das sehe ich etwas anders.

Die beiliegende XML-Datei ist keine ANSI-Datei! Einfach mal mit einem HEX-Editor öffnen, schon sieht man, dass die Umlaute mit 16 Bit kodiert sind. Ganz simples UTF8.

Der Fehler liegt vermutlich in der Umsetzung des ganzen Unicode-Getöses.

In der Datei DB.data.pas habe ich an einer Stelle gefunden (getter/setter Methoden), dass explizit TEncoder.ANSI benutzt wird. Das habe ich mal testweise auf UTF8 umgestellt, schon klappt das Laden einwandfrei. Nur das Speichern noch nicht, wo wahrscheinlich das gleiche Problem nochmal auftritt. Trotz der von mir geänderten Konvertierung dort werden zwar die Bytes des UTF8-Strings erzeugt, aber nicht korrekt in die XML-Datei geschrieben.

EDIT die Datei heißt data.db.pas

[urdelphist]

Aber vielen Dank natürlich für Deine Mithilfe und Vorschläge.

Wenn Du mehrere Delphi-Versionen hast, die zu unterschiedlichen Ergebnissen führen, dann wäre es hilfreich zu sehen, wo die Unterschiede zwischen den Dateien liegen. Also besonders bei der data.db.pas Datei. Bin mir ziemlich sicher, dass es unterschiedliche Interfaces bzw. Konvertierungen zwischen den String-Typen gibt.

[Redeemer]

Zitat von urdelphist:

Hm, das sehe ich etwas anders.

Die beiliegende XML-Datei ist keine ANSI-Datei! Einfach mal mit einem HEX-Editor öffnen, schon sieht man, dass die Umlaute mit 16 Bit kodiert sind. Ganz simples UTF8.

Ich habe nie etwas anderes behauptet. Ich habe nur gesagt: Wenn Delphi eh keine WideStrings unterstützt und dein Delphi kein UTF-8, dann kodiere deine Datei doch einfach in ANSI Windows-1252 (solange das Programm nicht auf Systemen mit anderer Locale ausgeführt werden soll).

Dein Delphi lädt die Datei falsch. Meins lädt sie richtig, auch mit anderen Encodings. Es geht hier nur um das Laden der Datei, das hat mit deinem Programm überhaupt nichts zu tun sondern wird von Delphi erledigt – oder in deinem Fall eben nicht. Aber es ist nicht die Aufgabe deines Programms, die Datei zu dekodieren.

Es gibt ein Feld für WideString, aber ich bekomme mein Delphi nicht dazu, das zu unterstützen. Es meint, das Feld sei kein Widestring sondern ein String. Ich verstehe nicht, woran es das festmacht.

[urdelphist]

Leider ist die Vorgabe, dass die XMl-Dateien als UTF8 kodiert sind, weil diese aus anderen Systemen stammen. Anfangs habe ich mit unterschiedlichen Kodierungen einiges ausprobiert, hat aber nie zum Erfolg geführt. Es war immer das gleiche fehlerhafte Verhalten.

Und ich bin mir relativ sicher, dass es in der Datei db.data.pas liegt. Und was meinst Du mit "erledigt Delphi"? Wer ist Delphi? Das Programm sollte den Code ausführen, den ich programmiere bzw per Komponenten einfüge. Der Fehler liegt in der VCL.

Es kann doch nicht angehen, dass das Funktionieren von der Delphi-Version abhängt. Ich sehe in meinen 5 Zeilen Code keinen Fehler, was Du mit der D2009 ja auch bestätigt hast. Leider haben die wieder irgendwo was verschlimmbessert, und das zieht sich bis in neueste Version. Eigentlich ein schlechter Scherz und ein sicheres Zeichen dafür, dass nicht vernünftig getestet wird. Stattdessen Featuritis an allen erdenklichen Stellen. Fehlerfreiheit und Robustheit zählen nicht mehr. Hauptsache mindestens im Jahrestakt neue Versionen raushauen, die wieder neue Fehler beinhalten. Und das bei diesen Preisen...
Man stelle sich nur vor, in größeren Projekten sich durch ein Update der IDE so was schönes einzufangen.

[Redeemer]

Ja, ich meine mit "erledigt Delphi" eigentlich "erledigt die VCL".

An deinem Code ist einfach falsch, dass du die Eingabe des Nutzers vor dem Speicher noch konvertierst. Das ist eben auch nicht dein Job, zumindest an dieser Stelle. Ich habe in meiner DB.pas von D2009 keine Referenz auf irgendein Encoding gefunden.