Es gibt immer wieder mal das Problem, dass man eine HTML-Datei
aus dem Internet laden will und bestimmte Informationen
daraus extrahieren will.
Wie kann man dies am Besten machen? Gibt es da einen einfachen Ansatz?
Oder gar eine (Open Source) Library, die einem hier hilft?
Beispiel: Aktueller Aktienkurs, Wetter (Temperatur eines Ortes),
Umrechnungskurse, oder was auch immer.
Die Seite mit wget/curl zu laden ist kein Problem.
Aber wie geht es dann innerhalb der HTML-Datei weiter?
Der Aufbau ist klar, body, head, usw.
Aber dann, wie komme ich auf die richtigen Informationen?
Bisher habe ich mir immer dabei geholfen,
dass ich nach irgendwelchen (hoffentlich gleichbleibenden)
Merkmalen vor der gewünschten Information und Merkmalen
daheinter gesucht habe und denn die Information dazwischen
mehr oder weniger Problem-Spezifisch aufbereitet habe,
bis ich diese Information alleine hatte.
Aber dann vergehen ein paar Tage und die Lösung geht wieder nicht
mehr, weil der Webseiten-Betreiber etwas am Layout/Inhalt der Seite
geändert hat...
Ich vermute ja schon, dass dies ein generelles Problem von HTML ist,
da die Information nicht so klar kategorisiert ist, wie z.B. in XML.
Dummerweise geht die Entwicklung genau in die entgegengesetzte Richtung.
Die Daten gehen in den immer aufwendigeren Javascript-Spielereien unter.
Bei deiner bisherigen Strategie wäre das am wenigsten aufwendige, du
nimmst einen Parser der mit XPath zusammenarbeitet. Am besten in eine
Script-Sprache integriert, damit du den Rest, der sich nicht in XPath
machen lässt dranfrickeln kannst.
Nur liefern immer mehr Seiten die Daten als Javascript. Mit etwas Glück
bekommt man das mit Regulären Ausdrücken zerlegt.
Oder wenn du Glück hast, holt die Seite die Daten als Json über Ajax. Du
kannst dann die Daten direkt holen.
Gibt ein Programm namens Xidel, was diese ganzen Strategien
zusammenfasst. Bin aber der Meinung, ein Script schreiben geht
schneller.
Noch einer schrieb:> Bei deiner bisherigen Strategie wäre das am wenigsten aufwendige, du> nimmst einen Parser der mit XPath zusammenarbeitet. Am besten in eine> Script-Sprache integriert, damit du den Rest, der sich nicht in XPath> machen lässt dranfrickeln kannst.
WENN es denn wohlgeformtes XML ist...
Erfahrungsgemäß kommst du (leider) am schnellsten und/oder robustesten
voran, wenn du mit reguläre Ausdrücke draufschießt. Ein "Vorfilter" mit
einem Perl-Skript bietet sich da oft an. Das muss ja nicht schön
programmiert sein und kann auch prinzipiell keine Sicherheitslücken
haben, wenn man sich darauf beschränkt, nur von der Standardeingabe
etwas zu lesen und ein Ergebnis in die Standardausgabe zu schreiben.
Ist ja ohnehin ein Wegwerf-Programmteil. Morgen baut der Betreiber die
Webseite um und dann... eben.
Nase schrieb:> WENN es denn wohlgeformtes XML ist...
HTML5 ist nicht mehr zwangsläufig als eine art wohlgeformtes xml parsear
(komisches wort), da z.b. inline-tags nicht mehr als solche markiert
werden müssen.
wem auch immer der schwachsinn eingefallen ist gehört mal richtig eine
geschmiert (m.m.)
Noch einer schrieb:> Oder wenn du Glück hast, holt die Seite die Daten als Json über Ajax. Du> kannst dann die Daten direkt holen.
jep, für sowas ist ajax super (wenn die daten nicht als gerendertes html
übertragen werden - dann ist nix gewonnen). habe das mal mit ein paar
aufgezeichneten ajax-call und ein paar scripts drumherum gemacht, hat
perfekt funktioniert...
Probier mal lynx. Der hat eine --dump Option mit der er die fertig
gerenderte Seite als Text ausgibt. Das könnte unter Umständen die Arbeit
sehr vereinfachen.
Peter P. schrieb:> Aber dann vergehen ein paar Tage und die Lösung geht wieder nicht> mehr, weil der Webseiten-Betreiber etwas am Layout/Inhalt der Seite> geändert hat...>> Ich vermute ja schon, dass dies ein generelles Problem von HTML ist,> da die Information nicht so klar kategorisiert ist, wie z.B. in XML.
Das liegt wohl daran, dass Webseiten primär zum Ansehen und nicht zum
maschinellen Auslesen gedacht sind.
Webdienste, die wissentlich/absichtlich Informationen für andere Systeme
anbieten, halten dafür eine dokumentierte API bereit, die sich nat.
nicht "alle Nasen lang" ändert.
Frank Esselbach schrieb:> Das liegt wohl daran, dass Webseiten primär zum Ansehen und nicht zum> maschinellen Auslesen gedacht sind.> Webdienste, die wissentlich/absichtlich Informationen für andere Systeme> anbieten, halten dafür eine dokumentierte API bereit, die sich nat.> nicht "alle Nasen lang" ändert.
Das ist natürlich richtig. Der TE fragt aber sicher nicht, weil er
leiber HTML parsen will anstatt die API zu benutzen.
Ich habe auch schon viele Daten aus HTML-Seiten extrahiert, weil es
keine API gab und habe natürlich auch 'alle Nase lang' meine
XPATH-Austrücke angepasst.
Was soll man denn Deiner Meinung nach machen, wenn der Anbieter
eigentlich gar nicht möchte, dass man die Daten aus seinen Seiten
extrahiert?
BTT: Bei einigen Seiten, die das DOM erst per JavaScript aufbauen, kommt
man an die Daten, indem man per Microsoft-COM-Schnittstelle auf das DOM
zugreift und ausliest.
Dazu hatte ich mir mal einen DOM - zu - XML - Konverter gebaut. Das hat
gut funktioniert, da man nicht immer die SW anpassen musste, sondern nur
XPATH-Austrücke, wenn mal wieder was geändert wurde.
Die einzige Lösung für dieses Problem: Webdesigner bekommen elektrische
Bürostühle und der Browser hat einen Notfallbutton, mit dem sich der
elektrische Stuhl fernsteuern lässt.
Peter P. schrieb:> Es gibt immer wieder mal das Problem, dass man eine HTML-Datei> aus dem Internet laden will und bestimmte Informationen> daraus extrahieren will.>> Wie kann man dies am Besten machen? Gibt es da einen einfachen Ansatz?> Oder gar eine (Open Source) Library, die einem hier hilft?
Entweder mit regulären Ausdrücken drübergehen oder mit einem xmlparser
(DOMDocument, DOMXpath z.B. in PHP)
Je nach Aufbau der Seite ist das eine oder andere einfacher.
Unter Perl gibts eine extra Bibliothek für sowas die einem das meiste
abnimmt, die liefert dann ganz einfach schon alle Links von Bildern,
Formularhandling.... WWW:Mechanize oder wie das heisst.
Es gibt auch scriptbare Browserengines. Das ist ein vollwertiger Browser
nur ohne GUI den du von aussen scripten kannst, braucht man wenn die
Seite sehr viel Javascript nutzt. Wenn man aber vorher mal die Abläufe
in einem Debugger wie Firebug,... untersucht kommt man auch so an die
direkten Links muss meist nur noch eine Session übernehmen, ids... was
man aus dem HTML,.. parsen kann. Das ganze pappt man zusammen und dann
geht es automatisch per Script.
Für FF gibts auch entspr. Addons, um bestimmte Abläufe zu
automatisieren, das geht das ganz ohne Programieren.
Ich verwende für Javascript rhino (Java) oder spider-monkey,
zum ausführen des Javascript-Codes.
Das sind javascript-interpreter.
Allerdings muss man dann noch eine DOM bereitstellen,
da JavaScript die document.window... strukturen nicht kennt.
