Hallo,
ich möchte gerne eine Datei parsen, die html5 enthält. Bei der Internetsuche bin ich auf JSOUP gestoßen. Das parst nur DOM-like. Ich möchte aber mit einer Stream-API a la SAX (XMLEventReader) arbeiten. Der erste naive Versuch mit der SAX-API ist schon an dem gescheitert, weil das keine valide XML-Präambel ist. Auf der Suche nach anderen Libs hab ich nicht wirklich was gefunden, was überzeugt. Kennt jemand da was?
Danke und viele Grüße aus Tornadoland.
Ob es in Anbetracht der speziellen Anforderung passend ist, weiß ich nicht - ich weiß nicht, ob er speziell HTML5 unterstützt (oder was einen solchen Parser ausmacht - es sind doch immer nur oder nicht?). Aber wenn es weder DOM noch SAX sein soll: Ich habe (nicht für „professionelle“ Anwendungen, sondern nur für private Experimente) mit Jericho HTML Parser ausgezeichnete Erfahrungen gemacht. Er schluckt so ziemlich alles, auch wenn’s nicht wirklich valide ist, ist ausgezeichnet dokumentiert und sehr einfach zu verwenden. (Tatsächlich ist das das einzige Projekt, dem ich bisher xx $ gespendet habe).
Aber selbst wenn er nicht passt: Unten auf der Seite sind noch Alternativen aufgelistet, die du durchprobieren kannst 
Stimmt, es würde mir auch reichen, wenn die Doctype/Text/Tag/Attribut-Knoten rauskommen. Validierung brauche ich nicht.
Naja, SAX wäre schön gewesen, geht aber nicht. Oder doch?
Danke für die Empfehlung, StreamedSource sieht recht vielversprechend aus. Mal sehen, wie Jericho mit dem doctype zurecht kommt…
Nun, ich weiß nicht, nach welchen Kriterien man einen Parser „hart“ als „SAX oder nicht“ klassifizieren könnte. Er sagt in der Übersicht
- Compared to a tree based parser such as DOM, the memory and resource requirements can be far better …
- Compared to an event based parser such as SAX, the interface is on a much higher level and more intuitive …
WAS genau er da intern macht, ist (mir) nicht ganz klar. Aber bisher konnte ich da so ziemlich jedes HTML reinwerfen, und er konnte damit umgehen. Genaue Performanceanalysen habe ich aber nicht gemacht, und was passiert, wenn man ihm eine 1000MB-HTML-Datei gibt, und man eigentlich nur wissen will, ob sie mit anfängt und mit aufhört, weiß ich auch nicht. Welchen konkreten Grund gibt es denn, speziell nach SAX zu fragen? Speicherbedarf, Performance, oder irgendein spezielles Anwendungsmuster?
Recht einfach, ein Parser, der eine Implementierung der SAX-API bereit stellt, konkret des Interfaces XMLEventReader. Die mit dem JDK mitgelieferte Defaultimplementierung com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl wirft mir wegen des doctypes am Anfang der html5-Datei einen Fehler. Wenn es andere SAX-Parser Impls gäbe, die das nicht machen, könnte man die austauschen. Das wäre für mich OK.
Ich benutze plain html5 Dateien als Templates. Die möchte ich z.B. für Lokalisierung filtern und manipulieren. Das geht mit einem Stream-basierten Ansatz. Dafür brauche ich kein DOM o.ä.
Speicherbedarf ist ein Argument. Es ist aber entschärft, weil die Templates soo groß eigentlich auch nicht sind.
Wichtiger ist mir das Programmiermodell Streaming mit mapping/filtering. Anstatt Programierung über Seiteneffekte (Manipulation des veränderlichen DOMs).
Ohne bisher damit gearbeitet zu haben, erinnerte ich mich noch daran, dass in thymeleaf 3 ein neuer Parser zum Einsatz kommt, der zwar explizit für thymeleaf entwickelt wurde, aber auch losgelöst verwendbar ist.
Dieser Parser ist “sax-like” und kann mit html5 umgehen. Er wurde auf einen schmalen Memoryfootprint und hohe Performance optimiert.
Siehe hier: attoparser
Vielen Dank für Eure beiden Hinweise. Die beiden Libs sind mir bei der Suche durch gerutscht. Beide sind auf einem einigermaßen aktuellen Stand und tatsächlich gut dokumentiert.
Ich habe mich vornehmlich mit den API-Docs befasst:
Jericho HTML Parser 3.4
Mit net.htmlparser.jericho.StreamedSource lässt sich ähnlich arbeiten wie mit javax.xml.stream.XMLEventReader.
attoparser 2.0.0.RELEASE API
Die Verwendung von org.attoparser.simple.IMarkupHandler bzw. ISimpleMarkupHandler finde ich für meinen Zweck ungeeigneter.
Das ist die Dokumentationslage. Zu praktischen Tests bin ich noch nicht gekommen…