Ruby-HTML- und XML-Parser: Ein auf der Arbeitslast basierender Vergleich

Aktuelle Releases und unterstützte Ruby-Versionen wurden für diesen Entwurf nicht in der Praxis überprüft, daher müssen statusabhängige Empfehlungen zum Zeitpunkt der Veröffentlichung überprüft werden.

• Wählen Sie Nokogiri als praktischen Ausgangspunkt für statisches oder unvollständiges HTML sowie allgemeine Arbeit mit XML-Bäumen.
• Entscheiden Sie sich für Ox, wenn das Parsen und Schreiben von XML, die Verarbeitung im SAX-Stil oder die Objektserialisierung im Mittelpunkt stehen.
• Wählen Sie LibXML Ruby, wenn Ihre XML-Pipeline XPath sowie Validierungs- oder XSLT-Funktionen benötigt.
• Betrachten Sie Oga und Hpricot als Alternativen, die eine besonders sorgfältige Überprüfung der Kompatibilität und Wartung erfordern.
• Verwenden Sie Selenium nur, wenn das Rendern, Klicken, Scrollen, das Ausfüllen von Formularen oder der Browserstatus Teil der Aufgabe sind.

Diese auf die Arbeitslast ausgerichtete Einteilung ist sinnvoller, als einen Satz von Ruby-HTML- und XML-Parsern pauschal als die beste Lösung zu erklären.

Für alle sechs Tools gelten dieselben Kriterien. Ein Sternchen kennzeichnet Angaben, die noch durch die aktuelle offizielle Dokumentation bestätigt werden müssen.

Die Kategorie „HTML-Parsing“ der Ruby Toolbox bietet nützliche Paketinformationen, doch Verzeichnisdaten allein reichen nicht aus, um die aktuelle Kompatibilität oder eine allgemeine Rangliste zu ermitteln.

Klassifizieren Sie die Eingabe, bevor Sie APIs vergleichen. Fragen Sie sich, ob es sich um HTML oder XML handelt, ob Sie eine tolerante Wiederherstellung oder eine strenge Fehlerbehandlung benötigen, ob die Daten in den Arbeitsspeicher passen und welche Abfrage- oder Transformationsfunktionen erforderlich sind.

Fügen Sie betriebliche Einschränkungen hinzu: native Kompilierung, Systembibliotheken, Ruby-Laufzeitumgebung, Container-Image und Bereitstellungsziel. Überprüfen Sie schließlich, ob die Bytes die gewünschten Daten enthalten. Ist dies nicht der Fall, muss eine Abfrage, Authentifizierung oder Browser-Darstellung erfolgen, bevor Ruby-HTML- und XML-Parser die Daten extrahieren können.

Web-HTML ist oft unvollständig. Ein Ruby-HTML-Parser sollte aus fehlenden Tags, ungewöhnlichen Verschachtelungen und Fragmenten einen brauchbaren Baum rekonstruieren können, während Abfragen vorhersehbar bleiben. Nokogiri stützt sich auf den Quellcode für CSS und XPath sowie für den Umgang mit fehlerhaftem HTML, was es zu einem sinnvollen ersten Versuch macht.

XML hat andere Vorgaben. Struktur, Namespaces und Validierungsregeln können geschäftliche Anforderungen sein, sodass eine stillschweigende Wiederherstellung schlimmer sein kann als ein offensichtlicher Fehler. Wählen Sie einen XML-orientierten Modus und legen Sie fest, wie Fehler angezeigt werden.

Das Abrufen erfolgt separat. Cookies, Authentifizierung, Weiterleitungen und Ajax bestimmen, welche Markups du erhältst. Wenn die Antwort den Zielknoten enthält, parse ihn direkt. Wenn JavaScript diesen Knoten später erstellt, rendere ihn zuerst und parse das resultierende DOM.

Ein DOM-Baum lädt das Dokument in einen Knotengrafen im Arbeitsspeicher. Dies ist praktisch für die Navigation zu übergeordneten, gleichrangigen oder untergeordneten Elementen sowie für wiederholte Abfragen. Der Speicherbedarf steigt mit der Dokumentgröße und der Baumdarstellung des Parsers.

Eine SAX- oder Reader-ähnliche Schnittstelle gibt Ereignisse aus, während der Parser voranschreitet. Sie eignet sich für große Feeds, „Append-only“-Transformationen und Pipelines, die Datensätze erzeugen können, ohne das gesamte Dokument zu behalten. Der Kompromiss liegt in der Zustandsverwaltung: Ihr Handler muss Kontext, Namespaces und Teil-Datensätze explizit verfolgen.

Unter diesen Ruby-HTML- und XML-Parsern stützt sich „supplied evidence“ bei der SAX-Verarbeitung auf „Ox“ und bei mehreren Nicht-DOM-Schnittstellen auf „Nokogiri“ und „LibXML Ruby“. Überprüfen Sie die genauen APIs und messen Sie den maximalen Speicherbedarf mit Fixtures, bevor Sie Ihre Lösung darauf ausrichten.

Entscheiden Sie für die Extraktion, ob das Team CSS-Selektoren, XPath oder beides bevorzugt. CSS ist prägnant für Klassen- und Attributmuster; XPath eignet sich oft besser für Textbedingungen, Achsen und namensraumbewusstes XML. Eine gezielte Überprüfung von XPath im Vergleich zu CSS-Selektoren kann verhindern, dass der Selektorstil zu einer unbeabsichtigten Architektur wird.

Prüfen Sie bei XML separat die Namespace-Registrierung, die DTD- oder Schema-Validierung, XSLT und die Fehlerberichterstattung. Leiten Sie keine Funktion aus einer anderen ab. Die Installation verdient die gleiche Sorgfalt: Native Erweiterungen können zwar die Funktionalität verbessern, aber sie können zusätzlichen Aufwand für den Compiler, die Systembibliotheken oder die Image-Erstellung verursachen.

Halten Sie in der Entscheidung die Gem-Version, die Ruby-Version, die Versionen der nativen Bibliotheken sowie das Überprüfungsdatum fest. Führen Sie bei Upgrades die Fixture-Tests erneut durch, anstatt „erfolgreich installiert“ als Kompatibilitätsnachweis zu betrachten.

Nokogiri ist der umfassendste, durch den Quellcode gestützte Ausgangspunkt in dieser Reihe von Ruby-HTML- und XML-Parsern. Es parst HTML und XML, ermöglicht CSS- und XPath-Abfragen und kann aus unvollständigem HTML einen brauchbaren Baum aufbauen. Diese Kombination eignet sich für gewöhnliches Web-Scraping in Ruby, die Bereinigung von Feeds, die Dokumentenprüfung sowie Transformationen, die einen wahlfreien Zugriff auf Knoten erfordern.

require "nokogiri"

html = "<article><h1>Parser choice</h1><a href='/next'>Next</a></article>"
doc = Nokogiri::HTML.parse(html)

title = doc.at_css("article h1")&.text&.strip
next_url = doc.at_xpath("//a[normalize-space()='Next']")&.attr("href")

Die „safe-navigation“-Aufrufe sind wichtig, da Selektoren in der Produktion fehlschlagen können, selbst wenn sie bei einem Beispiel funktioniert haben. Entscheiden Sie, ob ein fehlendes Feld nil, einen übersprungenen Datensatz oder einen schwerwiegenden Fehler bedeutet, und kodieren Sie diese Entscheidung in Ihren Tests.

Nokogiri ruft keine Seiten ab und führt kein JavaScript der Website aus. Kombinieren Sie es mit einem HTTP-Client, wenn die Antwort bereits die Daten enthält. Erweitern Sie die Abrufebene, wenn Authentifizierung oder clientseitiges Rendering das zurückgegebene Dokument verändern.

Die bereitgestellten Quellen führen Nokogiri außerdem SAX, Push-Parsing, XSLT und mehrere native Parser-Backends zu. Behandeln Sie diese als verifizierungsabhängige Funktionen, insbesondere bei der Wahl zwischen MRI und anderen Laufzeiten oder beim Erstellen minimaler Container.

Ox und LibXML Ruby lösen unterschiedliche „XML-first“-Probleme. Ox deckt baumbasierte XML-Ein- und -Ausgabe, die Serialisierung von Ruby-Objekten sowie die ereignisgesteuerte SAX-Verarbeitung ab. Es lohnt sich, es in die engere Wahl zu ziehen, wenn ein Ruby-XML-Parser Objekte serialisieren oder große Dokumente ohne komplexe Abfragen verarbeiten muss.

LibXML Ruby ist eine Hülle um libxml2 und eignet sich für abfrageintensive Pipelines, bei denen XPath-Abfragen, Schema-Prüfungen oder XSLT-Transformationen eine Rolle spielen. Der Verzeichnis-Snapshot weist dem Gem außerdem Schnittstellen für Bäume, Ereignisse, Pull-Reader und Writer zu, zusammen mit DTD-, RelaxNG- und XSD-Validierung. Überprüfen Sie diese Details anhand der genauen Version, die Sie einsetzen möchten.

xml = "<person><name>Ada</name></person>"

require "ox"
ox_tree = Ox.parse(xml)

require "xml"
libxml_doc = XML::Parser.string(xml).parse
name = libxml_doc.find("//name").first&.content

Machen Sie aus einem alten Benchmark-Ergebnis keinen „Nokogiri-vs.-Ox“-Mythos. Ein fairer Test berücksichtigt Ruby, Compiler-Flags, Versionen der nativen Bibliotheken, Dokumentform, Kodierung, Warm-up, Wiederholungen sowie die Frage, ob Baumkonstruktion, Abfragen, Serialisierung oder Streaming gemessen werden. Geben Sie Durchsatz, Latenz, Zuweisungen und Spitzen-Speicherbedarf separat an.

Das bereitgestellte Material berichtet über mögliche Einschränkungen von Ox in Bezug auf XPath, Namespaces und XSLT sowie über eine native Abhängigkeitskette für LibXML Ruby. Überprüfen Sie beides vor der Auswahl, insbesondere bei Integrationen mit vielen Namespaces und portablen Container-Builds.

Oga und Hpricot gehören zu einem statusabhängigen Zweig des Entscheidungsbaums. Oga hält den Großteil seiner Implementierung in Ruby, nutzt eine kleine Erweiterung und verarbeitet HTML und XML mit XPath sowie namensraumbezogenen XML-Abfragen. Der Schwerpunkt von Hpricot liegt auf HTML, obwohl die bereitgestellten Informationen besagen, dass es XML akzeptiert und CSS- sowie XPath-Selektoren bietet.

Die vorliegenden Informationen beschreiben zudem eine geringe Aktivität bei Oga in jüngster Zeit und weisen darauf hin, dass Hpricot nicht mehr gepflegt wird; dies sind jedoch keine aktuellen offiziellen Überprüfungen. Bevor Sie sich für eine der beiden Lösungen entscheiden, sollten Sie die neueste Version, die Ruby-Unterstützung, Kompatibilitätsprobleme sowie die Frage prüfen, ob Ihr Zielsystem die entsprechende Erweiterung erstellen kann.

Bei bestehenden Anwendungen kann das Risiko eines Wechsels die Verwendung eines durch Fixtures geschützten Adapters rechtfertigen. Bei einer neuen Anwendung sollten Sie einen erfolgreichen Kompatibilitätstest und einen expliziten Verantwortlichen für die Wartung verlangen, bevor Sie eine der beiden Lösungen als Alternative zu Nokogiri wählen.

Selenium dient der Browser-Automatisierung und ist kein gewöhnlicher Ruby-HTML-Parser. Verwenden Sie es, wenn JavaScript das erforderliche DOM erstellt oder wenn der Workflow Klicks, Scrollen, das Absenden von Formularen oder die Beibehaltung des Browserstatus erfordert. Die offizielle Selenium-WebDriver-Dokumentation erläutert das Modell zur Browsersteuerung.

Beginnen Sie mit einem HTTP-Abruf in Verbindung mit einem Parser. Wenn in einer gespeicherten Antwort Daten fehlen, die im Browser sichtbar sind, verlagern Sie nur die Darstellung oder die Interaktion auf Selenium. Extrahieren Sie dann mit Locators oder übergeben Sie den Quellcode der gerenderten Seite an Nokogiri zur CSS- oder XPath-Verarbeitung.

Dies führt zu zusätzlichen Browserprozessen, Treiberverwaltung, Wartezeiten und weiteren Fehlerquellen. Die aktuelle Warte-Semantik und die Treiberkonfiguration sind versionsabhängig; überprüfen Sie diese daher, anstatt ältere Anleitungen zu wiederholen. Nehmen Sie diesen Mehraufwand nicht für statisches Markup in Kauf, das ein HTTP-Client bereits zurückgibt.

Verwenden Sie für das Parsen von Produktionsdaten einen expliziten Eingabe- und Ausgabekontrakt:

1. Empfange oder rufe Bytes ab und zeichne anschließend die endgültige URL, den Status, den Inhaltstyp und den deklarierten Zeichensatz auf.
2. Lösen Sie die Kodierung auf, bevor Selektoren ausgeführt werden. Behalten Sie die ursprünglichen Bytes bei, falls bei der Transkodierung oder bei fehlerhaftem Input eine Untersuchung erforderlich werden könnte.
3. Führen Sie das Parsing in dem Modus durch, der für HTML-Toleranz, striktes XML oder Streaming gewählt wurde.
4. Extrahieren Sie Felder mit Selektoren, die bewusst mit fehlenden Knoten umgehen.
5. Validieren Sie erforderliche Felder, Typen, Namespaces oder Schemata, bevor Sie einen Datensatz ausgeben.
6. Speichern Sie repräsentative Testdaten, einschließlich fehlerhafter Markups, geänderter Layouts, leerer Felder und Nicht-UTF-8-Beispiele.
7. Führen Sie bei jedem Parser- oder Abhängigkeits-Upgrade Selektortests mit diesen Testfällen durch.

def extract_title(html)
  doc = Nokogiri::HTML.parse(html)
  title = doc.at_css("article h1")&.text&.strip
  raise KeyError, "article h1 missing" if title.to_s.empty?
  { title: title }
end

Protokollieren Sie Parsing-Fehler mit einem „fixture-safe“-Kontext, nicht mit den gesamten sensiblen Dokumenten. Behandeln Sie nicht vertrauenswürdiges XML als separaten Sicherheitscheck, anstatt davon auszugehen, dass die Standardwerte des Parsers sicher sind.

Bevor Sie sich für diese Ruby-HTML- und XML-Parser entscheiden, beantworten Sie folgende Fragen:

• Handelt es sich bei der Eingabe um statisches HTML, fehlerhaftes HTML, striktes XML oder ein gerendertes Browser-DOM?
• Passt das Dokument in den Arbeitsspeicher, oder sollten Datensätze gestreamt werden?
• Sind CSS, XPath, Namespaces, Validierung oder XSLT erforderlich?
• Ist die Objektserialisierung Teil der Arbeitslast?
• Welche nativen Bibliotheken, Compiler, Browser oder Treiber müssen mitgeliefert werden?
• Wurde das jeweilige Gem bereits mit der Zielversion von Ruby und dem Zielbetriebssystem abgeglichen?
• Ist das Tool eine veraltete Abhängigkeit, die hinter einem Adapter laufen sollte?
• Decken die gespeicherten Fixtures Kodierung, fehlerhafte Eingaben, fehlende Selektoren und Upgrades ab?

Der beste Ruby-XML-Parser oder HTML-Parser ist derjenige, der diese Anforderungen mit der geringsten zuverlässigen Laufzeit erfüllt.

• Klassifizieren Sie die Arbeitslast, bevor Sie sich für ein Gem entscheiden: Statisches HTML, striktes XML, gestreamtes XML, Objektserialisierung und gerenderte Seiten erfordern unterschiedliche Tools.
• Halten Sie Abruf, Authentifizierung, Rendering und Parsing als separate Pipeline-Schritte getrennt, damit Fehler der richtigen Ebene zugeordnet werden.
• Überprüfen Sie die aktuellen Versionen, nativen Abhängigkeiten und Plattformunterstützung mit genau der Ruby-Version und dem Deployment-Image, die Sie einsetzen werden.
• Führen Sie Benchmarks mit repräsentativen Testdaten und Testselektoren durch und prüfen Sie auf fehlende Knoten, Kodierungen und fehlerhafte Eingaben, bevor Sie einen Parser als produktionsreif einstufen.

Nein. Nokogiri parst die ihm übergebene HTML- oder XML-Zeichenkette und führt keine Seitenskripte aus. Rufen Sie das gerenderte DOM mit einem Browser-Tool ab, sobald JavaScript das Zielelement erstellt, und fragen Sie dieses DOM dann direkt ab oder übergeben Sie dessen Seitenquelltext an Nokogiri. Wenn ein Endpunkt dieselben Daten als JSON oder HTML zurückgibt, ist die Verwendung dieser Antwort in der Regel einfacher als die Steuerung über den Browser.

Verwenden Sie Streaming oder SAX, wenn Dokumente für eine komfortable Baumkonstruktion zu groß sind oder wenn jeder Datensatz einmal der Reihe nach verarbeitet werden kann. Dies eignet sich gut für Feeds, Exporte und Transformationen, die Ergebnisse schrittweise ausgeben. Bevorzugen Sie ein DOM, wenn die Extraktion beliebige Navigation, wiederholte Abfragen oder Änderungen an weit voneinander entfernten Stellen des Dokuments erfordert.

Behandeln Sie beide als situationsabhängige Entscheidungen und nicht als automatische Standardwerte. Überprüfen Sie vor der Einführung eine aktuelle Version, die Unterstützung für Ihre Ruby-Version, den erfolgreichen Build auf jedem Bereitstellungsziel sowie eine akzeptable Reaktion auf Probleme. Ein kleiner Kompatibilitätstest sollte Ihre tatsächlichen Fixtures analysieren und Namespaces, fehlerhafte Eingaben sowie Selektoren durchspielen. Vorhandener Code kann die Beibehaltung hinter einem Adapter rechtfertigen, selbst wenn bei einer Neuentwicklung eine andere Wahl getroffen würde.

Ein fairer Vergleich erfordert zunächst identische Ausgabe und identisches Fehlerverhalten, da eine schnellere Wiederherstellung bedeutungslos ist, wenn Parser unterschiedliche Baumstrukturen erstellen. Verwenden Sie separate Fixture-Gruppen für kleine Dokumente, große Dokumente, Namespaces, fehlerhafte Eingaben, Streaming und Serialisierung. Geben Sie die Verteilung der Laufergebnisse anstelle eines einzigen besten Ergebnisses an, berücksichtigen Sie die Auswirkungen der Garbage Collection und veröffentlichen Sie das Test-Harness, damit andere Entwickler den Test reproduzieren können.

Die Auswahl unter Ruby-HTML- und XML-Parsern wird wesentlich einfacher, sobald die Arbeitslast klar definiert ist. Nokogiri ist der praktische Allzweck-Ausgangspunkt für HTML und gemischte baumbasierte Aufgaben. Ox verdient eine Bewertung hinsichtlich XML-Serialisierung und Ereignisverarbeitung, während LibXML Ruby für XML-Pipelines geeignet ist, die XPath-, Validierungs- oder Transformationsfunktionen benötigen. Oga und Hpricot erfordern intensivere Wartungs- und Kompatibilitätsprüfungen, und Selenium kommt nur dort zum Einsatz, wo Rendering oder Interaktion tatsächlich erforderlich sind.

Egal, wofür Sie sich entscheiden: Halten Sie den Parser hinter einer schmalen Schnittstelle. Bewahren Sie Rohdaten, Testselektoren und das Verhalten bei fehlenden Knoten auf, dokumentieren Sie Annahmen zur Kodierung und legen Sie die Laufzeitteile fest, die native Erweiterungen beeinflussen. Führen Sie Benchmarks mit Ihren eigenen Dokumenten durch, anstatt die Geschwindigkeitsrangliste anderer zu übernehmen.

Das Abrufen von Daten kann letztendlich schwieriger werden als das Parsen. Wenn blockierte Anfragen, CAPTCHAs oder Proxy-Rotation das Entwicklungsbudget belasten, kann die Scraper-API von WebScrapingAPI rohes HTML zurückgeben und gleichzeitig die Arbeit auf der Anfrageseite übernehmen, sodass sich Ihr Ruby-Code auf eine kleine, testbare Extraktionsphase konzentrieren kann. Das ist die klarste Abgrenzung: Das Abrufen liefert vertrauenswürdiges Markup, und der ausgewählte Parser wandelt es in validierte Daten um.