Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>.webarchive, .maff, .mhtml – oder andere HTML-Archivformate – welches bietet die beste Sicherheit für die Zukunft?

.webarchive, .maff, .mhtml – oder andere HTML-Archivformate – welches bietet die beste Sicherheit für die Zukunft?

ratz-fatz
ratz-fatz19.02.1812:03
Ich habe mir über die Jahre angewöhnt, von interessanten Webseiten mit Safari eine .webarchive Datei anzulegen. Seit Dezember 2017 scheint aber (wahrscheinlich wegen der von mir verwendeten Beta-Versionen von Safari) der Wurm in diesem Dateiformat zu stecken. Die gespeicherten Inhalte lassen sich nicht mehr öffnen, bzw. laufen in einer Endlosschleife, weil Safari meint: "Diese Webseite wurde neu geladen, weil ein Problem aufgetreten ist." Diese Meldung wird oben im Browserfenster angezeigt, refresht im Sekundenabstand, der Ladebalken bleibt in der Mitte stehen und das Webarchive ist somit unbrauchbar.

Da ich seit geraumer Zeit auch alternativ den Firefox und Opera einsetze, suche ich nach einem anderen Speicherformat, welches nach Möglichkeit nicht ausschließlich zu Safari kompatibel ist. Ich möchte nicht die Seite nach PDF konvertieren und die Inhalte weiterhin auch in Zukunft im Browser darstellen können. Bei meiner Suche bin ich über ein PlugIn für Firefox gestolpert, welches aber in Formaten speichert, die nicht mehr unterstützt werden:

Über den WebArchive Folderizer kann ich zwar die alten Webarchive wieder "auflösen". Jetzt stellt sich aber die Frage, wie ich die Seiten dann erneut so abspeichere, dass sie auch in Zukunft gelesen werden können. Safari hat jetzt mit dem "Bruch" bei der Kompatibilität zum eigenen .webarchive Format bei mir jegliches Vertrauen verspielt und ich werde nicht mehr auf ein Format setzen, das nur noch von einem einzigen Browser weltweit gelesen werden kann.

Ich suche also nach einem Archiv-Format, mit dem ich die HTML Seite in einer Datei so abspeichern kann, dass ich sie auch in Zukunft noch problemlos in unterschiedlichen Browsern öffnen kann. Wer hat Empfehlungen dazu?
0

Kommentare

maculi
maculi19.02.1812:50
Das einfachste wäre, du speicherst die Seiten als HTML-Dateien mit allem dazugehörigen ab. Nur hast du dann wieder viele Dateien, statt nur einer einzigen. Du musst dich entscheiden, was wichtiger ist: Alles in einer Datei, oder auch in Zukunft problemlos zu öffnen. HTML-Dateien sind mit Abstand die Variante mit der größten Zukunft. Wenn es unbedingt eine einzige Datei sein muss, dann würde sich tatsächlich pdf anbieten. Was spricht da dagegen? Hab selber damit schon manches archiviert, einfach über den Druckdialog aufrufen und gut ist.

Sie dir doch mal Sitesucker BlueCrab oder ähnliche Programme an. Die speichern aus gutem Grund nicht in einem eigenen Format, sondern in HTML, damit der ganze Kram auch in Zukunft noch lesbar ist.
0
Deichkind19.02.1814:53
Vor einigen Jahren habe ich beobachtet, dass Safari/Mavericks von Safari/El Capitan erzeugte Archive nicht öffnen konnte. Das äußerte sich ebenfalls in der Endlosschleife eines abstürzenden und neustartenden Tabs.
Der umgekehrte Fall (neueres Safari kann alte Archive nicht öffnen) wäre allerdings neu für mich.
Safari kann doch die vom WebArchieve Folderizer entpackten Seiten neu verpacken?

Das Firefox-maff-Archiv war auch nicht problemlos. Häufig scheiterte der Speicherversuch überhaupt (oder man musste mehrmals neu ansetzen bis zum Erfolg), oder der Archiv-Generator erzeugte absurd große Dateien. Wobei allerdings die maff-Dateien in der Regel etwas kleiner waren als die entsprechenden Safari-Archive - dank zip-Komprimierung vermutlich.
0
ratz-fatz
ratz-fatz19.02.1815:29
Deichkind
Der umgekehrte Fall (neueres Safari kann alte Archive nicht öffnen) wäre allerdings neu für mich.
Safari kann doch die vom WebArchieve Folderizer entpackten Seiten neu verpacken?
Das aktuelle Safari öffnet keine Archive, die mit bestimmten Betas von Safari erstellt wurden. Archive vor der Betaphase werden anstandslos geöffnet.
Aus dem Folderizer kommen nur .html Dateien mit falsch codierten Sonderzeichen, bzw. Umlauten. Das lässt sich zwar mit entsprechenden Tools "heilen" (search and replace), ändert aber nichts daran, dass ich mich konsequent vom .webarchive Dateiformat abwenden möchte.

Die Archivierung der HTML Seite ist für mich wichtig, weil sich darin Linkinformationen befinden, die zum Zeitpunkt der Seitenerstellung des Anbieters einen zweifelsfreien Beleg ermöglichen und bei einem späteren Aufruf des Archivs auch dem Kunden als Nachweis dienen. Wenn die Seite nach längerer Zeit aufgerufen (und dabei aus dem Autorensystem des Anbieters heraus neu aufgebaut) werden, sind die ursprünglichen Links nicht mehr vorhanden, weil sie durch neue (aktuelle) Links zu externen Quellen ersetzt wurden. Das erschwert uns und dem Kunden den Nachweis der tatsächlichen Situation zum Zeitpunkt der Veröffentlichung. Das klingt wahrscheinlich irrational, es dient aber zur nachträglichen Beurteilung eines bestimmten "Klickverhaltens" aus dem Content heraus als eine sehr wichtig eingestufte Hilfestellung.
0
MikeMuc20.02.1810:34
So du zugriff auf den Server hast kannst du doch auch einfach dort den ganzen Ordner mit den Originaldaten der Website einfach laden. Wenn dort Seiten allerdings dynamisch generiert werden dann wird das aber wohl nicht so einfach sein
0
almdudi
almdudi20.02.1817:15
Damit, daß bei der Benutzung von Betavarianten irgendwann mal was nicht klappt, sollte man aber schon vorher rechnen. Es gibt ja einen Grund, warum sie als Beta bezeichnet werden.

Das webarchive-Format ist vermutlich ein Package, also an sich ein Ordner, in dem die einzelnen Dateien liegen, die man bei Speicherung als html-Datei einzeln sieht. Ich bilde mir ein, daß man früher mal per Kontextmenü die einzelnen Dateien anschauen konnte, kann aber auch eine Illusion sein. Man könnte - falls es Ordner sind - bei Problemdateien mal versuchen, den Inhalt per Terminal aufzurufen.
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.