Problem beim Lesen von XML Daten

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MariaDB/MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
Antworten
Brainsucker
User
Beiträge: 68
Registriert: Mittwoch 16. November 2011, 23:20

Hallo liebe Python-Gemeinde!


Ich habe folgendes Problem beim lesen von XML Daten.


Ich möchte von dieser Seite [Link vom Author entfernt] Daten auslesen, die dort im XML Format gespeichert sind.

Nur leider erhalte ich dann immer folgenden Fehler:

Code: Alles auswählen

ParseError: not well-formed (invalid token): line 2, column 9
das liegt wohl an dem = zeichen. Meine bisherigen Google-Ergebnisse haben mich auf die Spur gebracht, dass das angegebene encoding nicht stimmt.


Hier noch der Codeschnipsel mit dem ich das oben genannte Experiment gewagt habe:

Code: Alles auswählen

import urllib2
import xml.etree.ElementTree



u = urllib2.urlopen('*Link entfernt*')
xml_data = u.read()
u.close()

etree_data = xml.etree.ElementTree.XML(xml_data) # ERROR

Selbstverständlich hab ich es natürlich auch mit den anderen parsern versucht des xml Moduls (dom und sax). Aber trotzdem immer selber fehler.


Kann mit bitte jemand ein wenig auf die sprünge helfen?

Vielen Dank und liebe Grüße

Brainsucker
Zuletzt geändert von Brainsucker am Donnerstag 17. November 2011, 00:30, insgesamt 1-mal geändert.
Benutzeravatar
pillmuncher
User
Beiträge: 1484
Registriert: Samstag 21. März 2009, 22:59
Wohnort: Pfaffenwinkel

Soweit ich das sehen kann, ist die Quelle kein gültiges XML. Der Fehler besteht allerdings nicht in dem =-Zeichen, sondern im fehlenden Quoting danach. Attribut-Werte müssen in XML immer in Gänsefüßchen (") gesetzt werden. Statt einen Parser zu suchen, der ungültiges XML verstehen kann, wäre es nicht einfacher, die Fehler im XML-Quelltext zu reparieren? BZW. den Leutz von Musicbase.FM solange auf die Nerven zu gehen, bis sie ordentliches XML auspucken.
In specifications, Murphy's Law supersedes Ohm's.
Brainsucker
User
Beiträge: 68
Registriert: Mittwoch 16. November 2011, 23:20

Hey, vielen dank für die schnelle Antwort.

Dann werd ich wohl das tun, was ich am besten kann und dem Kollegen auf die nerven gehn! :)
Brainsucker
User
Beiträge: 68
Registriert: Mittwoch 16. November 2011, 23:20

Hmm nun habe ich wieder selbes Problem. Dieses mal liegt es an den Sonderzeichen wie ä,ö,ü usw...


Kann mir jemand sagen, wie ich dem ElementTree Parser sage, dass ich mit UTF-8 lesen will?




Edit:
Habs schon gefunden.... Dann muss ich wohl oder übel wieder nerven anfangen Oo

http://openbook.galileocomputing.de/pyt ... .htm#t2t31
BlackJack

@Brainsucker: Das musst Du nicht extra sagen. Wenn für's Parsen eine andere Kodierung verwendet wird, dann ist die im XML vorgegeben. Und wenn die dort angegebene Kodierung nicht zum Inhalt passt, ist wieder beziehungsweise immer noch das XML kaputt.

Wie wird das denn erzeugt? Es gibt Bibliotheken dafür und Validatoren um das Ergebnis zu prüfen…
Brainsucker
User
Beiträge: 68
Registriert: Mittwoch 16. November 2011, 23:20

Jo, danke habs schon gesehn.


Diese zeile fehlt wohl im XML Code

Code: Alles auswählen

<?xml version="1.0" encoding="UTF-8"?> 
Brainsucker
User
Beiträge: 68
Registriert: Mittwoch 16. November 2011, 23:20

One of the most common mistake when editing an XML document is to add some extended characters and forget to set the encoding declaration at the top of the document.

Sagt das nicht schon alles, wenn mich meine Englisch kenntnisse nicht enttäuschen?
deets

Noe, tut es nicht. Es sagt nur, dass ein encoding Pflicht ist, wenn man etwas *anderes* als UTF-8 verwendet, bzw. eine der BOM-basierten encodings. Dafuer muss man natuerlich auch das BOM schreiben.

Da du den Link ja weggenommen hast, kann man das jetzt pruefen. Ich wuerde aber mal eher davon ausgehen, dass wer auch immer das XML produziert Umlaute reinrendert in einem anderen encoding, wie zB iso-8859-1 oder gar einer windows codepage. Wo dann das encoding in den header muss.

Und dann kracht's natuerlich. Da muesstest du schon mal den exakten Fehler zeigen.
Brainsucker
User
Beiträge: 68
Registriert: Mittwoch 16. November 2011, 23:20

deets hat geschrieben:Noe, tut es nicht. Es sagt nur, dass ein encoding Pflicht ist, wenn man etwas *anderes* als UTF-8 verwendet, bzw. eine der BOM-basierten encodings. Dafuer muss man natuerlich auch das BOM schreiben.

Da du den Link ja weggenommen hast, kann man das jetzt pruefen. Ich wuerde aber mal eher davon ausgehen, dass wer auch immer das XML produziert Umlaute reinrendert in einem anderen encoding, wie zB iso-8859-1 oder gar einer windows codepage. Wo dann das encoding in den header muss.

Und dann kracht's natuerlich. Da muesstest du schon mal den exakten Fehler zeigen.

Dann spricht deine aussage allerdings gegen das, was hier steht:

http://openbook.galileocomputing.de/pyt ... .htm#t2t31

Ich zitiere:
Durch Angabe des Encodings, in diesem Fall UTF-8, können auch Umlaute und andere Sonderzeichen korrekt verarbeitet werden.
Wenn das stimmt, was du sagst, wäre diese Zeile in dem Beispiel das dort aufgeführt wird überflüssig.

Deine Aussage und die des Pythontuturials beißt sich ein wenig.
deets

@BrainSucker

Ja, aber deine Schlussfolgerung, dass ich nicht recht haette, ist halt falsch. Das Galileo Openbook ist aus vielerlei Gruenden nicht empfehlenswert. Du hast einen weiteren gefunden.

Aber weil du ja mehr Beweise brauchts:

http://www.w3.org/TR/2008/REC-xml-20081 ... codingDecl

"""
... it is also a fatal error if an XML entity contains no encoding declaration and its content is not legal UTF-8 or UTF-16.
"""

Mit anderen Worten: UTF-8 und UTF-16 (welches ein BOM vorraussetzt) brauchen kein EncodingDecl

Nun zufrieden?
deets

Noch ein Nachtrag: die Aussage des Galileo-Books ist ja nicht voellig falsch. Sie ist halt nur nicht vollstaendig. UTF-8 *kann*, muss aber halt nicht deklariert werden.

Und um nochmal auf dein eigentliches Problem zurueckzukommen: wenn der encoding-Eintrage tatsaechlich dein Problem reparieren wuerde, dann haettest du einen Fall von einem nicht-standardkonformen XML-Parser. Nix, was es nicht gibt. Aber im konkreten eher unwahrscheinlich.
Brainsucker
User
Beiträge: 68
Registriert: Mittwoch 16. November 2011, 23:20

naja ich gehe doch mal stark davon aus, das der xml.etree.ElementTree ein standartkonformer XML parser ist.


Trotzdem stoße ich weißterhin auf diesen Fehler:

Code: Alles auswählen

ParseError: not well-formed (invalid token): line 9, column 28

Das im Fehler angegebene Zeichen in der oben genannten Zeile der XML Datei ist wie schon beschrieben ein umlaut.

Wenn du sagst, dass das hinzufügen eines Encodings in der XML Datei nicht mein Problem löst, was löst es dann?
deets

Du hast das immer noch nicht verstanden: es kann *sein*, dass das hinzufuegen einer solchen Deklaration dein Problem loest. Aber *NICHT*, dass du "encoding='UTF-8'" hinzufuegst, und dann geht alles - so wie du das behauptet hast.


Sondern zB iso-8859-1 oder cp1252 oder sowas als encoding. Welches genau haengt von den Daten ab.

Und solange du uns nicht zeigst, wie das XML tatsaechlich aussieht, oder zumindest wie die Bytes, die an Zeile 9, Spalte 28 stehen, aussehen, kann man dir da auch nicht weiterhelfen.

Und natuerlich bleibt es nach wie vor so, dass wer auch immer das XML generiert, es nicht richtig generiert.
Brainsucker
User
Beiträge: 68
Registriert: Mittwoch 16. November 2011, 23:20

Hier hab ich mal ein pastebin link, wie die XML Daten aktuell aussehen.


Nätürlich ändern sich die Daten regelmäßig und somit stimmt die Zeile/Spalte nicht mehr exakt. Aber das tut ja der sache nichts zu trotz.

http://pastebin.com/3K2cFhgj
BlackJack

@Brainsucker: Sag dem der das erzeugt das man XML nicht wie eine Zeichenkette ansehen darf, sondern mit den richtigen Werkzeugen arbeiten soll. :roll: Das Anfangstag von ``<showpic>` ist mit schöner Regelmässigkeit falsch.

Teste das XML doch einfach mal mit einem „XML validator“ auf Fehler.

Bei der Kodierung hilft es uns nicht weiter wenn Du das über ein Pastebin veröffentlichst, weil wir damit nicht mehr wissen wie denn die Bytes bei den ursprünglichen Daten ausgesehen haben. Das kann auf dem Weg von dort ja diverse Male umkodiert worden sein.
Brainsucker
User
Beiträge: 68
Registriert: Mittwoch 16. November 2011, 23:20

Hey, sorry für meine späte antwort.

Das problem ist nun gelöst und die ursache war tatsächlich das nicht deklarierte encoding. Kaum war es auf UTF-8 gesetzt, hats schon funktioniert.


Trotzdem vielen dank an alle die gewillt waren mir zu helfen. Eure tipps waren gold wert :)
BlackJack

@Brainsucker: Das kann nicht sein. Es war ganz bestimmt nicht die Kodierungsangabe. Und wenn es jetzt funktioniert, dann *muss* sich ja auch am Inhalt etwas geändert haben, denn da waren „kaputte“ Tags in der Datei.
Brainsucker
User
Beiträge: 68
Registriert: Mittwoch 16. November 2011, 23:20

BlackJack hat geschrieben:@Brainsucker: Das kann nicht sein. Es war ganz bestimmt nicht die Kodierungsangabe. Und wenn es jetzt funktioniert, dann *muss* sich ja auch am Inhalt etwas geändert haben, denn da waren „kaputte“ Tags in der Datei.
Ja, diese wurden auch behoben. Allerdings erst nachdem das encoding deklariert wurde. Und nachdem dies geschehen ist, trat zumindest nicht mehr der fehler auf wegen dem ich das toppic eröffnet hatte. Alles weitere waren 'schönheitsfehler' in der XML die sich sehr schnell beheben liesen. Und seit dem funktionierts.
deets

@BrainSucker

Wie dir schon mehrfach dargelegt wurde: das encoding von utf-8 ist nicht notwendig. Punkt. Wenn wer auch immer dieses "XML" verbrochen hat, daran rumgespielt hat, um das encoding reinzupacken, der hat dann vielleicht aus versehen, oder klammheimlich, das eigentliche Problem geloest. Schoen fuer dich. Aber hoer bitte, bitte endlich auf zu glauben, es liegt an dem encoding-header.
Antworten