[Gelöst] ReadXMLFile: Problem beim Parsen von XML Datei

[pluto]

Hallo

Ich habe eine XML Datei, in der hin und wieder sowas vor kommen kann:

<e2servicename><n/a></e2servicename>

Leider habe ich auf das erstellen, der XML Datei selbst kein Einfluss. Beim Suchen im Forum bin ich schon auf die neue Version von "Laz2_DOM, Laz2_XMLRead" und gestoßen...
Beim Aufruf von ReadXMLFile können zwar jetzt flags gesetzt werden, aber da ist nichts bei, was mir helfen würde, ich habe es auch ausprobiert....
Die Fehlermeldung lautet:

In 'stream:' (line 84 pos 19): Expected ">".

Press OK to ignore and risk data corruption.
Press Abort to kill the program.

Das ist genau diese besagte Zeile, wenn ich sie raus nehme in der Test Anwendung, geht es, später habe ich jedoch kein Einfluss auf das XML Dokument...

Als Einzigste Lösung würde mir im Moment einfallen: Alles in einen String einzulesen und <n/a> einfach zu löschen....wenn es dann auftaucht bzw. die ganze Zeile....

Kennt einer von euch eine Mögliche Alternative?

Edit2: Es gibt scheinbar keine andere Möglichkeit, außer den Tag durch was anders zu ersetzten... Daher habe ich den Thread als Gelöst markiert..... Danke für die Bestätigung.

[MacWomble]

Das n/a steht ja vermutlich für 'not available' (Nicht verfügbar). Dies wird so gemacht, um e2servicename als vorhnaden, aber nicht verwendet (im Moment) zu kennzeichnen.

Erstellst du nachher auch wieder XML? Falls nicht, dürfte die Zeile irrelevant sein.

Schöner wäre es jedoch, wenn du aus <n/a> für dein Programm einen anderen String machst. Du könntest z.B die <> durch Klammern ersetzen und im Falle eines wegschreibens der XML den umgekehrten Weg gehen. Damit geht der Eintrag nicht verloren. Das ersetzen könntest du eventuell auch in einem Rutsch in einer Kopie der Quelldatei machen und dann diese Kopie anstelle des Originals einlesen.

[pluto]

Das n/a steht ja vermutlich für 'not available' (Nicht verfügbar). Dies wird so gemacht, um e2servicename als vorhnaden, aber nicht verwendet (im Moment) zu kennzeichnen.

Ja, das habe ich mir auch gedacht...

Erstellst du nachher auch wieder XML? Falls nicht, dürfte die Zeile irrelevant sein.

Nein, die XML Datei erstelle ich nicht... Daher habe ich kein einfluss darauf... Nur zum testen, werden die XML Dokumente von der Platte geladen.... später ist es ein WebServer, auf den ich selbst kein Zugriff habe.... Leider macht mir aber der XML Parser genau hier Probleme

Schöner wäre es jedoch, wenn du aus <n/a> für dein Programm einen anderen String machst. Du könntest z.B die <> durch Klammern ersetzen und im Falle eines wegschreibens der XML den umgekehrten Weg gehen. Damit geht der Eintrag nicht verloren. Das ersetzen könntest du eventuell auch in einem Rutsch in einer Kopie der Quelldatei machen und dann diese Kopie anstelle des Originals einlesen.

Wenn es keinen Anderen Weg gibt, werde ich das wohl so machen müssen...
Es wird wohl auch nicht so häufig auftreten.... schön ist das aufjedenfall nicht....

[Warf]

Ja, leider ist der XML parser der RTL(FCL/LCL?) nicht sonderlich stabil und geht schon bei kleineren verstößen gegen das erwartete Format kaputt (zur verteidigung, so etwas ist glaube ich im XML standard sogar verboten). Die einfacheste Lösung ist wie du bereits gesagt hast, vorher einmal parsen und fixen. Wenn die Dateien aber größer werden bedeutet das aber doppelte Laufzeit (einmal drüberlaufen zum fixen von fehlern, einmal zum parsen). Daher wäre die "gute" lösung wohl eher sich den XML parser code mal anzuschauen und zu sehen ob du ihn augmentieren kannst. Vielleicht geht das ganz einfach durch das Ableiten einer neuen Klasse bei der du einfach eine Methode oder so überschreibst, eventuell musst du dafür auch tiefer in dern XML parser source einsteigen (und in den RTL dateien den source ändern) das wär zwar doof, aber wenn dir performance wichtig ist, führt dann wohl kaum ein weg dran vorbei.

Zu erst einmal würde ich aber deinen Ansatz verfolgen und mir die arbeit nur machen wenn die Performance signifikant leidet. Wenn du eh nur kleine Dateien (also im kb-mb bereich) parsen musst, und deine Zielplattform ein Moderner rechner und eventuell nicht sowas wie ein PI oder so ist, sollte das kein problem sein

[Timm Thaler]

Der Parser macht das genau richtig. Es ist halt kein gültiges XML. Kannst die XML-Datei ja mal im Firefox öffnen, der bricht das Parsen auch ab mit einer Fehlermeldung:

XML-Verarbeitungsfehler: nicht wohlgeformt
Adresse: file:///.../test.xml
Zeile Nr. 5, Spalte 21: <e2servicename><n/a></e2servicename>

Das dagegen geht:

<e2servicename>n/a</e2servicename>

Klar kann man das umgehen, indem man den String vorher danach durchsucht und das <n/a> ersetzt.

Besser wäre es allerdings dem Ersteller auf die Füße zu treten, dass er doch bitte gültiges XML da reinschreiben soll.

sich den XML parser code mal anzuschauen und zu sehen ob du ihn augmentieren kannst

Bitte nicht! Wir wollen ganz bestimmt nicht die 90er zurück, wo man zig Browserweichen in HTML brauchte, weil ein paar Leute glaubten irgendwas abseits vom Standard machen zu müssen und jeder Browser das irgendwie anders interpretiert hat. Es gibt den XML Standard und der Ersteller des XML soll sich bitte an den Standard halten.

[Warf]

Bitte nicht! Wir wollen ganz bestimmt nicht die 90er zurück, wo man zig Browserweichen in HTML brauchte, weil ein paar Leute glaubten irgendwas abseits vom Standard machen zu müssen und jeder Browser das irgendwie anders interpretiert hat. Es gibt den XML Standard und der Ersteller des XML soll sich bitte an den Standard halten.

Schön finde ich das auch nicht, aber wenn er die Daten so bekommt und nichts am Format ändern kann, bleibt ihm wohl nichts anderes übrig. Er sollte dann aber natürlich auf einer Kopie arbeiten, davon bin ich einfach mal ausgegangen

[MacWomble]

Das <n/a> gabe es schon als Kennzeichner für leere Zellen in Tabellen, bevor XML gefunden war, Wen ich mich recht erinnere, war das schon zu Zeiten von Multiplan

Das heute noch zu verwenden, trauen sich glaube ich nur noch SAP, Datev und Konsorten

[pluto]

Besser wäre es allerdings dem Ersteller auf die Füße zu treten, dass er doch bitte gültiges XML da reinschreiben soll.

Würde ich gerne tun, aber ich weiß a) nicht wer das erstellt und b) glaube ich das ihn das gar nicht mehr Interessiert...

OK! Dann weiß ich bescheid.... Da das nicht oft vorkommen wird, soweit ich bisher weiß, werde ich die Lösung nehmen, wo ich den Tag einfach ersetzen werden...
Hätte ja sein, können das es noch weitere Möglichkeiten gibt...Außer sich einen eigenen Parser zu schreiben...

[Timm Thaler]

Das <n/a> gabe es schon als Kennzeichner für leere Zellen in Tabellen, bevor XML gefunden war, Wen ich mich recht erinnere, war das schon zu Zeiten von Multiplan

Das können sie ja auch machen, aber dann müssen sie es für XML richtig umsetzen:

<e2servicename><n/a></e2servicename>

Ist kein Problem und gibt korrekt <n/a> als Eintrag für e2servicename zurück.

<e2servicename><n/a></e2servicename>

Hier ist <n/a> nunmal ein Tag, und zwar ein nicht erlaubtes mit dem Slash in der Mitte. Woher soll der Parser wissen, ob das ein Tag oder ein Eintrag sein soll und was er damit anfangen soll?

Und es ist nunmal so, dass bei XML auch die Interpretation der folgenden Tags mit sowas kaputtgemacht werden kann, deswegen darf es der Parser auch nicht einfach ignorieren.

[pluto]

Woher soll der Parser wissen, ob das ein Tag oder ein Eintrag sein soll und was er damit anfangen soll?

in HTML weiß der Parser sowas auch z.b. beim img tag, soweit ich weiß....
der tag wird "geöffnet" und sofort wieder "geschlossen".

Beim IMG Tag ist es doch ganz ähnlich
<IMG ... />
Ich gebe zu etwas anders, aber ähnlich....

[Timm Thaler]

<IMG ... />
Ich gebe zu etwas anders, aber ähnlich....

Dann schieb mal den Slash aus dem Beispiel aus der Mitte ans Ende: <na/> Ohhh, schon isses gültiges XML. Nur isses dann halt kein Eintrag mehr, der hier offenbar eingelesen werden soll, sondern ein Tag ohne Eintrag, der gleich wieder abgeschlossen wird.

Aber als <n/a> isses halt nicht gültig und der Parser meckert das zu Recht an. Du erwartest doch auch nicht, dass Dein Browser auf <IM/G...> ein Bild anzeigt, nur weils halt so ähnlich wie ein IMG-Tag aussieht.

[pluto]

Dann schieb mal den Slash aus dem Beispiel aus der Mitte ans Ende: <na/> Ohhh, schon isses gültiges XML. Nur isses dann halt kein Eintrag mehr, der hier offenbar eingelesen werden soll, sondern ein Tag ohne Eintrag, der gleich wieder abgeschlossen wird.

Aber als <n/a> isses halt nicht gültig und der Parser meckert das zu Recht an. Du erwartest doch auch nicht, dass Dein Browser auf <IM/G...> ein Bild anzeigt, nur weils halt so ähnlich wie ein IMG-Tag aussieht.

Hast ja recht... schon doof das mit dem <n/a>... warum müssen die das überhaupt in spitze klammern schreiben, ohne wäre es ja kein Problem....
Habe es jetzt aber gelöst....vorläufig aufjedenfall.

[Timm Thaler]

Der Slash ist hier nur das scheinbare Problem, an dem hängt sich halt der Parser - wie auch der Firefox - auf, weil er an dieser Stelle in einem Tag nichts zu suchen hat.

Das eigentliche Problem sind die Klammern, die hier nicht umcodiert wurden und damit dem Parser einen Eintrag als Tag vorgaukeln. Utf-8 hat uns ja schonmal den Krampf abgenommen, jedes Ä, Ö, Ü umcodieren zu müssen, aber einige Zeichen wie halt <> gehen in HTML und XML trotzdem nicht durch.

[Socke]

Das heute noch zu verwenden, trauen sich glaube ich nur noch SAP, Datev und Konsorten

Nein, die von SAP schreiben einfahc #20#20#20#20#20 ... die kennen kein NULL in der Datenbank.

[MacWomble]

Ich bearbeite regelmäßig Stücklisten von SAP, in welchen <n/a> vorkommt...