Hallo,

ich habe ein ziemlich lästiges Problem mit XML.

Ich lese die Daten aus einem Memo-Feld einer mySQL-Tabelle aus:

markieren

Delphi-Quellcode:

var myXMl: IXMLDocument;
..
myXML := newXMLDocument;
      
showmessage(fieldbyname('MEM_XML').asstring);
myXMl.LoadFromXML(fieldbyname('MEM_XML').asstring);
showmessage(myXML.xml.text);

Die erste Message liefert korrekt das was auf der Datenbank steht:

markieren

Code:

<?xml version="1.0" encoding="ISO-8859-1"?>
<Formula>
<Item Typ="6">
<DBItem>
<ProcLabel>W?rzek?hlen</ProcLabel>
...
</DBItem>
</Item>
</Formula>

Nach dem Laden in das XML-Dokument sieht es aber so aus:

markieren

Code:

<?xml version="1.0"?>
<Formula>
<Item Typ="6">
<DBItem>
<ProcLabel>W?rzek?hlen</ProcLabel>
...
</DBItem>
</Item>
</Formula>

D. h. mein encoding verschwindet und ich bekomme Fehler.
Was kann die Ursache sein?

Gruss

myXML.xml.text ... zu liest es ohne Encoding aus, in Delphi also als Unicode? und da wäre diese Ansi-Codepage jedenfalls total falsch.


Die Umlaute sehen aber schon am Anfang irgendwie kaputt aus. :grubel:
LATIN-1 sollte in einem deutschen Windows jedenfalls korrect argestellt werden.

Wenn ich UTF-8 verwende ist das Problem das gleiche. Sobald ein Umlaut in den Daten auftaucht gibt es einen Fehler.
Ohne encoding oder mit UTF-8 stehen die Umlaute als solche im Text.

Texte mit Codepage durch Unicode durchzugagen kann aber auch nicht immer gut gehn.

myXML.XML = TStrings, also Unicode
myXML.LoadFromXML = gibt es als "ANSI"-Version und das solltest du besser verwenden, wenn das Encoding erhalten bleiben sollte, also vermutlich AsAnsiString (falls die DBKomponente es nicht nach "ANSI" umwandelt, sonder die Codepage belässt)

In Deinem Fall entweder ohne Encoding (Unicode oder UTF-8 in der DB) speichern und ohne Encoding als Unicode an LoadFromXML übergeben
oder als Binär-Blob speichern und via Stream laden.

Setzen der Encoding -Eigenschaft und speichern in einen Stream:

zusammenfalten · markieren

Delphi-Quellcode:

procedure justXmlThings();
const
   xmlContent: String =
      '<?xml version="1.0" encoding="ISO-8859-1"?>' + sLineBreak +
      ' <Formula>' + sLineBreak +
      ' <Item Typ="6">' + sLineBreak +
      ' <DBItem>' + sLineBreak +
      ' <ProcLabel>W?rzek?hlen</ProcLabel>' + sLineBreak +
      ' ...' + sLineBreak +
      ' </DBItem>' + sLineBreak +
      ' </Item>' + sLineBreak +
      ' </Formula>';
var
   xmlDoc:   IXMLDocument;
   output: TStringStream;
begin
   xmlDoc := NewXMLDocument();
   xmlDoc.Active := True;
   xmlDoc.LoadFromXML(xmlContent);

   xmlDoc.Encoding := 'ISO-8859-1';
   output := TStringStream.Create();
   xmlDoc.SaveToStream(output);
   WriteLn(output.DataString);
end;

Mit dem Stream funktioniert es jetzt ohne dass ich ein encode angebe.
Ich speichere jetzt über einen TMemorystream in ein BLOB-Feld.

markieren

Delphi-Quellcode:

str := TMemoryStream.Create;
if not ((state = dsedit) or (state=dsinsert)) then edit;
myxml.SaveToStream(str);
str.Position := 0;
TBlobField(fieldbyname('BLO_XML')).LoadFromStream(str);
post;
str.Free;

Danke für die Unterstützung

Auch mit dem schönen Speicherleck, wenn not (State in [dsEdit, dsInsert]) oder not (State in dsEditModes) ist ?

Resourcenschutzblöcke sind schon was Feines, bzw. eine "passende" Reihenfolge der Befehle.

Zitat von himitsu:

Auch mit dem schönen Speicherleck, wenn not (State in [dsEdit, dsInsert]) oder not (State in dsEditModes) ist ?

Resourcenschutzblöcke sind schon was Feines, bzw. eine "passende" Reihenfolge der Befehle.

Ich seh kein Speicherleck ... aber ein try finally gehört da auf jeden Fall hin.
Da steht Edit und nicht Exit

Ups, hatte da wirklich ein Exit gelesen ... bin aber auch nicht auf die Idee gekommen, daß jemand da hinten ein Edit verstecken würde,
denn das Edit prüft selber den Edit-Status und macht nichts, wenn es schon im Edit-Modus (Insert/Edit) ist.

Dennoch, wenn Edit nicht möglich ist, oder wenn es beim Speichern knallt, dann bleibt der Stream natürlich zurück.

Ihr habt ja beide recht ...

Zitat:

not (State in [dsEdit, dsInsert]) oder not (State in dsEditModes) ist ?

Zitat:

Ich seh kein Speicherleck ... aber ein try finally gehört da auf jeden Fall hin.

Es steht jetzt im Code auch so drin

Auf den State prüfe ich eigentlich routinemässig, da ich in etlichen Fällen zuerst den Datensatz speichern muss und dann erst aktualisieren kann weil Abhängigkeiten geprüft werden müssen.

Aber (State in [dsEdit, dsInsert]) ist natürlich besser als
not ((state = dsedit) or (state=dsinsert))
Danke für die Tips.