TEncoding.UTF8 ändert Reihenfolge in einer XML-Datei

Gerd Kayser · Verfasst: Do 08.08.13 02:12

Hallo,

beim Einlesen von XML aus einem MemoryStream in ein Memo stelle ich hier verwundert fest, dass sich dabei die Reihenfolge der einzelnen Einträge in den einzelnen Zeilen ändert.

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:

var
  Adresse : string;
  Ort     : string;
  Mem     : TMemoryStream;
  PNGBild : TPngImage;
begin
  Ort := 'Frankfurt%20am%20Main';
  Adresse := 'http://openweathermap.org/data/2.5/weather?q='
             + Ort
             + '&mode=xml'
             + '&units=metric'
             + '&lang=de';
  Mem := TMemoryStream.Create;
  try
    IdHttp.Get(Adresse, Mem);
    if Idhttp.ResponseCode = 200 then // 200 = okay
      begin
        Mem.Position := 0;
        Memo1.Lines.LoadFromStream(Mem);
      end
    else
      ShowMessage('Fehler beim Abruf der Wetterdaten!');
  finally
    Mem.Free;
  end;

Dann bekomme ich angezeigt: <humidity unit="%" value="82"/>.

Ändere ich den Source zu

markieren

Delphi-Quelltext

1:	Memo1.Lines.LoadFromStream(Mem, TEncoding.UTF8);

dann bekomme ich jedoch <humidity value="82" unit="%"/> angezeigt. Es sind mehrere Zeilen von der Umstellung der Reihenfolge betroffen.

Seltsamerweise führt ein

markieren

Delphi-Quelltext

1:
2:
3:
4:

Mem.Position := 0;
Memo1.Lines.LoadFromStream(Mem);
Mem.Position := 0;
Memo2.Lines.LoadFromStream(Mem, TEncoding.UTF8);

dazu, dass in beiden Memos die Reihenfolge geändert wird. Hier hätte ich eigentlich erwartet, dass sich die Reihenfolgen in Memo1 und Memo2 unterscheiden. Es sieht so aus, als wenn durch das TEncoding.UTF8 direkt der MemoryStream verändert wird. Aber diese Anweisung erfolgt doch erst nach dem Einlesen in das Memo1.

Dieses Verhalten ist für mich nicht plausibel. Hat jemand vielleicht eine Erklärung für mich? Im Internet habe ich dazu nichts gefunden.

jaenicke · Verfasst: Do 08.08.13 06:08

Das Lesen aus dem Stream ändert sicher nicht die Reihenfolge. Die Daten werden schlicht nicht immer in der gleichen Reihenfolge vom Server kommen. Warum auch? Das ist in XML-Daten doch vollkommen egal...

Du kannst den Stream ja einfach in eine Datei speichern und dir dort anschauen oder die Daten gleich als String abrufen:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:

  ReceivedText := IdHttp.Get(Adresse);
  if Idhttp.ResponseCode = 200 then // 200 = okay
    Memo1.Lines.Text := ReceivedText
  else
    ShowMessage('Fehler beim Abruf der Wetterdaten!');

Du wirst mit sehr hoher Wahrscheinlichkeit sehen, dass die Daten so vom Server kommen.

Gerd Kayser · Verfasst: Fr 09.08.13 00:00

jaenicke hat folgendes geschrieben :

Du wirst mit sehr hoher Wahrscheinlichkeit sehen, dass die Daten so vom Server kommen.

Mit dem Programm SmartSniff habe ich mir mal angesehen, was genau über die Leitung kommt. Dabei habe ich festgestellt, dass die Antwort auf eine Anfrage durch den Internetexplorer immer gepackt erfolgt (DataSize 1063 Bytes), die Antwort auf "IdHttp.Get" jedoch immer ungepackt (DataSize 4478 Bytes). Die Reihenfolge in meinem Programm stimmt mit der Reihenfolge, wie sie SmartSniff anzeigt, überein. Also werden die Daten in meinem Programm so dargestellt, wie sie über die Leitung kommen.

Beim Internetexplorer ist die Reihenfolge immer die gleiche. Sie weicht zur Zeit von der Reihenfolge in meinem Programm ab. Aber so lange die von meinem Programm empfangenen Daten vollständig sind, kann ich mit diesem Phänomen leben.

jaenicke · Verfasst: Fr 09.08.13 06:34

Gerd Kayser hat folgendes geschrieben :

Dabei habe ich festgestellt, dass die Antwort auf eine Anfrage durch den Internetexplorer immer gepackt erfolgt (DataSize 1063 Bytes), die Antwort auf "IdHttp.Get" jedoch immer ungepackt (DataSize 4478 Bytes).

Dann macht es durchaus Sinn die Komprimierung auch in IdHttp zu aktivieren. ;-)

Gerd Kayser · Verfasst: Sa 10.08.13 14:14

jaenicke hat folgendes geschrieben :

Dann macht es durchaus Sinn die Komprimierung auch in IdHttp zu aktivieren. ;-)

Ich habe mir noch einmal das Ganze mit SmartSniff angesehen und bei der Anzeige die gepackten Daten im Klartext darstellen lassen. Die Reihenfolge stimmt mit dem überein, was ich unkomprimiert mittels IdHTTP.Get in meinem Programm angezeigt bekomme. Der Internetexplorer stellt die Daten aber falsch dar. Bislang war ich immer der Ansicht, dass gepackte Daten nach dem Entpacken mit den ursprünglichen Daten übereinstimmen. Anscheinend gilt das wohl nicht für Microsoft. Oder bildlich gesprochen: Jeder wechselt eine Glühbirne durch anfassen und herausdrehen der Birne. Bei Microsoft hält man jedoch die Glühbirne fest und dreht die Lampe oder bei einer Deckenlampe gleich die Decke mit.

jaenicke · Verfasst: Sa 10.08.13 15:04

Gerd Kayser hat folgendes geschrieben :

Der Internetexplorer stellt die Daten aber falsch dar.

Was der Internet Explorer anzeigt ist die geparste Version der Seite, nicht das Original...
Dass die Anordnung der Attribute usw. dort anders sein kann, ist klar, denn der speichert beim Parsen natürlich nicht in welcher Reihenfolge die in der Datei standen. Wofür auch?

MSCH · Verfasst: Sa 10.08.13 17:04

Ist das nicht wurscht, welche Reihenfolge die Attribute/Nodes einer XML Datei haben? In der Regel parst man(n) das doch mit einer DOM Implementierung und nicht simple via plaintext.
Cheers Mathias

_________________
ist das politisch, wenn ich linksdrehenden Joghurt haben möchte?

jaenicke · Verfasst: Sa 10.08.13 17:23

MSCH hat folgendes geschrieben :

In der Regel parst man(n) das doch mit einer DOM Implementierung und nicht simple via plaintext.

Klar, das sollte selbstverständlich sein. Mit Pos und Copy usw. da heranzugehen macht keinen Sinn.

Gerd Kayser · Verfasst: Sa 10.08.13 20:06

jaenicke hat folgendes geschrieben :

Klar, das sollte selbstverständlich sein.

Mit dem Auslesen habe ich ja kein Problem. Ein XML-Parser arbeitet nach bestimmten Regeln, um eine XML-Datei darzustellen usw.

Zitat:

Ein XML-Dokument besteht aus Textzeichen, im einfachsten Fall in ASCII-Kodierung, und ist damit menschenlesbar.

Quelle: de.wikipedia.org/wik...ible_Markup_Language

Das Problem, was ich damit habe: Ich kann nicht nachvollziehen, nach welcher Regel die Attributnamen und -werte hier in einigen (nicht in allen) Zeilen durcheinander gewürfelt werden. Die Daten sind weder umfangreich noch komplex aufgebaut. Simpler Aufbau trifft es wohl eher. Sortierung nach Alphabet der Attributnamen trifft nicht zu. Sortierung nach Länge der Einträge auch nicht. Sortierung nach Attributwerten (Text vor Ziffern usw.) auch nicht. In einer Zeile werden die Attributnamen mit den dazugehörenden Werten in der Reihenfolge umgestellt, in der nächsten aber nicht. Ich kann da beim besten Willen keine Logik entdecken.

So, und jetzt gehe ich mit meiner Madame die Bäumchen im Park düngen und bewässern. Und danach schaue ich mir das JSON-Format einmal genauer an.

jaenicke · Verfasst: Sa 10.08.13 20:59

Gerd Kayser hat folgendes geschrieben :

Das Problem, was ich damit habe: Ich kann nicht nachvollziehen, nach welcher Regel die Attributnamen und -werte hier in einigen (nicht in allen) Zeilen durcheinander gewürfelt werden. [...] Ich kann da beim besten Willen keine Logik entdecken.

Da gibt es ja auch keine zu entdecken. Es gibt keine Logik. Es ist dem Parser schlichtweg vollkommen egal und auch dem Tool, das die Daten zusammenstellt.

Es gibt ja auch an keiner Stelle einen Grund eine bestimmte Reihenfolge einzuhalten. :nixweiss:

Wozu ist dir das denn wichtig?

Gerd Kayser · Verfasst: Sa 10.08.13 22:25

jaenicke hat folgendes geschrieben :

Wozu ist dir das denn wichtig?

Weil ich einfach verstehen möchte, was da genau passiert. Wenn ich mich mit einem neuen Thema befasse, dann versuche ich im Vorfeld immer, so viele Informationen wie möglich zu bekommen und diese auch zu verstehen.

jaenicke · Verfasst: Sa 10.08.13 23:42

An der Stelle gibt es jedenfalls nichts zu verstehen.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme