IXMLDocument und Sonderzeichen

[Blamaster]

Hi,

ich habe eine kurze Frage bezüglich Sonderzeichen und dem IXMLDocument.

Delphi-Quellcode:

procedure xmlTest();
var
  xml: IXMLDocument;
  rootNode, childNode: IXMLNode;
  logNode: IXMLNode;
  logMessage: string;
  logWideString: Widestring;
begin
  logMessage := 'Test äöüß<>"&';

  // write xml data
  xml := NewXMLDocument();
  xml.Encoding := 'iso-8859-1';
  xml.Options := [doNodeAutoIndent];
  rootNode := xml.AddChild('result');
  logNode := rootNode.AddChild('logData');
  logNode.AddChild('message').Text := logMessage;
  logWideString := xml.XML.Text;

  ShowMessage(logWideString);

  // read xml data
  xml := LoadXMLData(logWideString);
  rootNode := xml.DocumentElement;
  childNode := rootNode.ChildNodes[0];
  logWideString := childNode.childNodes['message'].Text;
  logMessage := logWideString;

  ShowMessage(logMessage);
end;

Das zwischenwandeln auf WideString ist lediglich enthalten da es der späteren Einsatzumgebung entspricht (xml wird vom Hauptprogramm erzeugt und als WideString an eine dll übergeben)

Das Erste ShowMessage gibt die Sonderzeichen alle in der korrekten XML Notation aus (< > ...)
Das zweite ShowMessage hingegen verschluckt das "&" Zeichen die anderen Sonderzeichen werden korrekt angezeigt. Woran liegt das ? Die Wandlung der unerlaubten Sonderzeichen in erlaubte XML Notation funktioniert ja scheinbar.

[himitsu]

Warum vergisst man eigentlich immer die wichtigsten Informationen?

• Welche Delphi-Version?
• Welche Windows-Version? (du verwendest hier der MS-XML-DOM und die Version hängt vom Windows ab)
• Installierte Windows-Updates? (speziell welche XML-Versionen installiert sind)
• Und vorallem was sagt der Debugger? (ist wirklich kein & im String drin)
  Für mein System kann ich bestätigen, daß das & im String und in der Memo-Ausgabe vorhanden ist.

Ach ja, außschließlich xml.SaveToStream und xml.SaveToFile beachten das Encoding.
Aber dir ist ja bestimmt noch nicht aufgefallen, daß in deinem logWideString kein Encodeing angegeben ist. (Standard ist UTF-8 und in diesem Fall von WideString natürlich UTF-16)

[Blamaster]

Zitat:

Welche Delphi-Version?

Delphi 7

Zitat:

Welche Windows-Version?

Windows 7

Zitat:

Installierte Windows-Updates?

Servicepack 1

Zitat:

Und vorallem was sagt der Debugger?

Debugger sagt das & Zeichen ist im logMessage String enthalten.
Wenn ich den Messagetext im Message Fenster mit Str+C Strg+V in einem Texteditor einfüge ist das & wieder da.

Zitat:

Für mein System kann ich bestätigen, daß das & im String und in der Memo-Ausgabe vorhanden ist.

Bedeutet das XML ist Systemabhängig ? Ich dache genau dafür ist XML da um plattformübergreifend zu kommunizieren. Genau dafür ist XML doch auch standardisiert. Wo liegt da der Ermessensspielraum für ein Windows-Update oder sonstiges aufeinmal den Standard anders auslegen zu wollen ?

Zitat:

Aber dir ist ja bestimmt noch nicht aufgefallen, daß in deinem logWideString kein Encodeing angegeben ist. (Standard ist UTF-8 und in diesem Fall von WideString natürlich UTF-16)

Ist das xml.Encoding := 'iso-8859-1' dann im Beispiel völlig überflüssig ?

Verstehe nicht was damit gemeint ist ? Bei der reinen Wandlung String -> WideString -> WideString -> String dürften doch eigentlich keine Informationen verloren gehen. Zumindest sagt das die Delphi Dokumentation so.

[mjustin]

Testweise würde ich das Dokument mal als Datei speichern und sehen, was Notepadd++ als Kodierung erkennt: iso-8859-1 oder utf-8?

[Blamaster]

Hi,

Notepad++ erkennt es als iso-8859-1

Edit.

Aber wenn das encoding sich wirklich nur auf xml.SaveToStream und xml.SaveToFile beziehen dürfte das ja auch keinen Unterschied machen.
Was aber viel interessanter ist. Ich konnte das Problem noch weiter reduzieren. Wie es aussieht das die XML und WiderString Geschichte nicht mit dem eigentlichen Problem zu tun.

Nichtmal das hier funktioniert:

Delphi-Quellcode:

logMessage: String;
logMessage := 'Test äöüß<>"&';
ShowMessage(logMessage);

Auch dabei wird das "&" nicht angezeigt. Zusätzlich ist mir noch aufgefallen das wenn das & nicht am Ende steht sondern am Anfang sprich logMessage := '&Test äöüß<>"'; dann wird im ShowMessage Fenster das T mit einem Strich drunter angezeigt.

[himitsu]

XML ist systemunabhängig, aber nicht alle "String"-Ausgaben sind unabhängig, sondern "absichtlich" für das jeweilige Ausgabemedium ausgelegt ... drum ist in xmldoc.xml.irgendwas der String vor D2009 immer ANSI und danach immer Unicode, da .XML eine TStringList ist.

Siehe TLabel.ShowAccelChar: Es gibt einige Komponenten, welche das & etwas anderes behandeln, beim Anzeigen, darum sollte man da erstmal im Debugger nachsehn, was wirklich im String ist.
Dazu zählen z.B. einige ältere Dialoge, wie z.B. ShowMessage, wo intern auch ein TLabel für die Anzeige genutzt wurde und bei dem man vergaß diese &-Behandlung zu deaktieren. :stupid:

[Blamaster]

Okay vielen Dank das erklärt natürlich das gezeigte Verhalten :)

Nochmal eine Rückfrage zu folgendem Punkt:

Zitat:

Ach ja, außschließlich xml.SaveToStream und xml.SaveToFile beachten das Encoding.

Heißt das wirklich das ich das xml.Encoding := 'iso-8859-1' nicht benötige ? Im Kopf des XML String wird es ja gesetzt.

Delphi-Quellcode:

<?xml version="1.0" encoding="iso-8859-1"?>

Ich hatte jetzt vermutet das hier das encoding benötigt wird um sicher zu gesehen das die Gegenseite sprich die dll an die der XML-String als WideString übergeben wird weiß wie die Zeichen zu interpretieren sind. (Die dll könnte ja durchaus in einer andere Programmiersprache oder einer anderen Delphi Version erstellt werden also mit anderem default Zeichensatz)

[himitsu]

Wenn der Text/String immer als Unicode (WideString aka UTF-16 oder als UTF-8) behandelt wird, dann ist das nicht nötig.
Es wäre sogar "falsch", wenn iso-8859-1 drinstünde und es dann doch als Unicode-Text gespeichert würde, drum lässt MS-XML dabei auch das Encoding weg.

xmldoc.SaveToString in einen WideString/UnicodeString ist immer Unicode, genauso wie seit Delphi 2009 auch xmldoc.xml.Text .

XML-Dateien, bzw. ANSI-Strings ohne Encodingangabe sind per Standard UTF-8.

[Blamaster]

Okay vielen Dank :)