Wie überprüft man, ob der Inhalt der Webseite geändert wurde?

Es gibt keine universelle Lösung.

• Verwenden Sie If-modifed-since oder HEAD, wenn möglich (normalerweise von dynamischen Seiten ignoriert)
• Verwenden Sie RSS, wenn möglich.
• Extrahieren Sie den letzten Änderungsstempel auf site-spezifische Weise (Nachrichten-Websites haben Veröffentlichungsdaten für jeden Artikel, leicht extrahierbar über XPATH)
• Nur interessante Elemente der Seite hashen (baustellenspezifisches Modell erstellen), ausgenommen flüchtige Teile
• Hasse den ganzen Inhalt (nutzlos für dynamische Seiten)

Hoffe, das hilft.

speichern Sie die HTML-Dateien - zwei Versionen ..

Einer war der HTML, der vor einer Stunde genommen wurde. - first.html

Sekunde ist der HTML, der jetzt genommen wurde - second.html

Führen Sie den Befehl aus:

Wenn das Diffs Text enthält, wird die Datei geändert.

Sicherste Lösung:

lade den Inhalt herunter und erstelle eine Hash-Prüfsumme mit SHA512 hash des Inhalts, behalte sie in der db und vergleiche sie jedes Mal.

Vorteile: Sie sind nicht auf Server-Header angewiesen und erkennen Änderungen.
Nachteile: Zu hohe Bandbreitennutzung. Sie müssen den gesamten Inhalt jedes Mal herunterladen.

Verwendung von Head

Fordern Sie die Seite mit HEAD verb an und überprüfen Sie die Header-Tags:

• Last-Modified : Der Server sollte die zuletzt generierte oder geänderte Seite bereitstellen.
• ETag : Ein Prüfsummen-ähnlicher Wert, der vom Server definiert wird und sich ändern sollte, sobald sich der Inhalt geändert hat.

Vorteile: Deutlich geringere Bandbreitennutzung und sehr schnelle Aktualisierung.
Nachteile: Nicht alle Server bieten die folgenden Richtlinien an und befolgen sie. Benötigen Sie eine echte Ressource mit der GET -Anforderung, wenn Sie feststellen, dass Daten abgerufen werden müssen

Verwendung von GET

Seite mit GET verb anfragen und bedingte Header-Tags verwenden: * If-Modified-Since : Der Server überprüft, ob die Ressource seit der folgenden Zeit geändert wurde und gibt den Inhalt zurück oder gibt 304 Not Modified

Vorteile: Verwenden Sie immer noch weniger Bandbreite, Single trip zum Empfangen von Daten.
Nachteile: Auch hier unterstützen nicht alle Ressourcen diesen Header.

Schließlich ist vielleicht eine Mischung aus der obigen Lösung der optimale Weg, um eine solche Aktion durchzuführen.

Wenn Sie versuchen, ein Tool zu erstellen, das auf beliebige Sites angewendet werden kann, könnten Sie es trotzdem für einige spezielle Anwendungen starten - indem Sie sie wiederholt herunterladen und exakte Unterschiede identifizieren, die Sie ignorieren möchten um die Probleme vernünftig zu behandeln, ohne bedeutungsvolle Unterschiede zu ignorieren. Solch eine schnelle praktische Probenahme sollte Ihnen viel konkretere Ideen über die Herausforderung geben, der Sie gegenüberstehen. Was auch immer Sie versuchen, testen Sie es gegen eine steigende Anzahl von Websites und optimieren Sie Ihre Änderungen.

  

Würden Sie sich die KB-Größe des HTML ansehen? Würden Sie sich die Stringlänge ansehen und prüfen, ob sich beispielsweise die Länge um mehr als 5% verändert hat, der Inhalt wurde "geändert"?

Das ist unglaublich grob, und ich würde das, wenn überhaupt möglich, vermeiden. Aber Sie müssen die Kosten abwägen, wenn Sie fälschlicherweise eine Seite für unveränderbar halten oder nicht für falsch halten.

  

Oder gibt es einen Hashing-Algorithmus, bei dem die Hashes gleich bleiben, wenn nur kleine Teile des Strings / Inhalts geändert wurden?

Sie können einen solchen "Hash" erstellen, aber es ist sehr schwierig, die Empfindlichkeit auf eine sinnvolle Änderung im Dokument einzustellen. Wie auch immer, als ein Beispiel: Sie könnten die 256 möglichen Byte-Werte nach ihrer Häufigkeit im Dokument sortieren und berücksichtigen, dass ein 2k-Hash: Sie können später ein "diff" machen, um zu sehen, wie viel Byte-Reihenfolge in einem späteren Download geändert wurde. (Um Speicher zu sparen, könnten Sie nur die druckbaren ASCII-Werte oder nur Buchstaben nach der Standardisierung der Groß- und Kleinschreibung verwenden.)

Eine Alternative besteht darin, eine Reihe von Hashwerten für verschiedene Schichten des Dokuments zu erzeugen: z.B. Unterteilen in Kopfzeile vs. Körper, Körper nach Überschriftsebenen und Absätze, bis mindestens ein gewünschtes Granularitätsniveau erreicht ist (z. B. 30 Schichten). Sie können dann sagen, dass, wenn nur 2 Schichten von 30 geändert haben, Sie das Dokument gleich betrachten werden.

Sie können auch versuchen, bestimmte Inhaltstypen vor dem Hashing zu ersetzen - z. Verwenden Sie die Übereinstimmung regulärer Ausdrücke, um Zeiten durch "<time>" zu ersetzen.

Sie könnten auch Dinge wie die Toleranz verringern, um mehr zu ändern, da die Zeit seit der letzten Verarbeitung der Seite zunimmt, was die "Kosten" verringern oder begrenzen könnte, wenn sie fälschlicherweise als unverändert betrachtet werden.

Verwenden Sie git , das über hervorragende Berichtsfunktionen für die Änderungen zwischen zwei Status einer Datei verfügt. Außerdem werden Sie keinen Speicherplatz auffressen, da git die Deltas für Sie verwaltet.

Sie können git sogar anweisen, "triviale" Änderungen zu ignorieren, wie das Hinzufügen und Entfernen von Leerzeichen, um die Suche weiter zu optimieren.

Praktisch kommt es darauf an, die Ausgabe von git diff -b --numstat HEAD HEAD^ zu analysieren; was übersetzt sich zu "Finde mich, was sich in allen Dateien geändert hat, und ignoriere alle Leerzeichenänderungen zwischen dem aktuellen Status und dem vorherigen Status" ; was zu einer Ausgabe wie folgt führt:

2 Insertionen gemacht, 37 Deletionen wurden an en/index.html

Als nächstes müssen Sie ein wenig experimentieren, um einen "Schwellenwert" zu finden, bei dem Sie eine Änderung als signifikant ansehen würden, um die Dateien weiter zu verarbeiten; Dies wird einige Zeit dauern, da Sie das System trainieren müssen (Sie können diesen Teil auch automatisieren, aber das ist ein anderes Thema).

Wenn Sie nicht einen guten Grund dafür haben, verwenden Sie Ihre traditionelle relationale Datenbank nicht als Dateisystem. Lassen Sie das Betriebssystem sich um Dateien kümmern, was sehr gut ist (etwas, das eine relationale Datenbank nicht verwalten soll).