Какой лучший "формат файла" для сохранения полных веб-страниц (изображений и т.д.) В одном архиве?

Я работаю над проектом, в котором хранятся отдельные изображения и текстовые файлы в одном месте, например, капсула времени. Теперь большинство проектов можно сохранить как один файл, например DOC, PPT и ODF. Но полные веб-страницы не могут - они сохраняются как отдельный файл HTML и папка с данными. Я хочу сохранить веб-страницу в одном архиве, и, хотя есть несколько решений, нет "стандартного". Каков наилучший формат для HTML-архивов?

Microsoft имеет MHTML - в основном файл, закодированный точно как MIME-сообщение электронной почты HTML, Он уже основан на существующем стандарте, а MHTML как его собственный был предложен как rfc2557. Это отличная идея, и это было навсегда, за исключением того, что это был "предложенный стандарт" с 1999 года. Кроме того, реализации, отличные от IE, просто громоздки. IE и Opera поддерживают его; Firefox и Safari с громоздким расширением.
Mozilla имеет Формат архива Mozilla - в основном ZIP файл с разметкой и изображениями, с метаданные, сохраненные как RDF. Это потрясающая идея - Winamp делает это для скинов и ODF и OOXML для своих встроенных изображений. Мне это нравится, за исключением: 1. Никто кроме Mozilla не использует его, 2. Единственное поддерживающее его расширение не обновлялось с Firefox 1.5.
URI данных становятся все более популярными. Вместо ссылки на внешнее местоположение a la MHTML или MAF, вы кодируете файл прямо в HTML-разметку как base64. В зависимости от вашего представления, он оптимизирован, так как файлы находятся правильно, где разметка. Однако поддержка по-прежнему несколько слабая. Firefox, Opera и Safari поддерживают его без помех; IE, лидер рынка, только начал поддерживать его в IE8, и даже тогда с ограничениями.
Тогда, конечно, там "Сохранить полную веб-страницу" , где разметка HTML сохраняется как "savedpage.html" и файлы в отдельной папке "savedpage_files". Афайк, все это делают. Это хорошо поддерживается. Но иметь дело с двумя отдельными элементами не просто и обтекаемо. Мой проект должен иметь их в одном архиве.

Имея в виду поддержку браузера и легкость редактирования страницы, , как вы думаете, лучший способ сохранить веб-страницы в одном архиве? Что было бы лучше всего как "стандарт"? Или мне нужно просто спрятать и обработать файл HTML и отдельную папку? Ради моего проекта я мог бы поддержать это, но я бы лучше его избежал.

Ответ 1

Мой любимый формат ZIP. Потому что:

Это хорошо подходит для этой цели
Это хорошо документировано
Для создания или чтения существует множество реализаций
Пользователь может легко извлекать отдельные файлы, изменять их и помещать в архив
Почти каждая основная операционная система (Windows, Mac и большинство Linux) имеет ZIP-программу, встроенную в

У всех вариантов есть некоторые недостатки:

С MHTMl вы не можете легко редактировать.
С URI данных, я не знаю, насколько сложной была бы реализация. (С помощью ZIP, даже я мог бы сделать это на PHP, 3 года назад...)
Возможность хранить вещи как отдельные файлы имеет слишком много вещей, которые могут пойти не так и испортить ваш архив.

Ответ 2

PDF файлы поддерживаются почти во всех браузерах почти на всех платформах и хранят содержимое и изображения в одном файле. Их можно редактировать с помощью правильных инструментов. Это почти определенно не идеально, но это вариант для рассмотрения.

Ответ 3

Используйте zip файл.

Вы всегда можете сделать программу / script, которая извлекает zip файл в каталог temp и загружает файл index.html в ваш браузер. Вы даже можете использовать файл index.ini/txt для указания файла, который должен быть загружен при извлечении.

В принципе, вы хотите что-то вроде формата Mozilla Archive, но без ненужного rdf-харда просто указать, какой файл загрузить.

Файлы MHT хороши, но обычно они используют base64 для встраивания файлов, что сделает размер файла больше, чем он должен быть (URI данных одинаковы). Вы можете добавлять вложения как двоичные файлы, но вам придется вручную сделать это с помощью шестнадцатеричного редактора или создать инструмент, а поддержка его клиентами может быть не такой хорошей.

Конечно, если вы хотите использовать то, что создаете браузеры, возможно, лучше MHT (Opera и IE).

Ответ 4

Это не только вопрос формата файла. Еще один важный вопрос: что именно вы хотите сохранить? Это:

хранить всю страницу так же, как со всеми ссылочными ресурсами - изображениями, CSS и javascript?
для захвата страницы, поскольку она была отображена в определенный момент времени; статический образ некоторого отображаемого состояния веб-страницы DOM?

Наиболее актуальная функция "сохранить страницу как" в браузере, будь то MAF или MHTML или файл + dir, пытается первым способом. Это в конечном счете ошибочный подход.

Не забывайте, что веб-страницы там являются скорее локальными приложениями, чем статическими документами, которые вы легко можете сохранить. Потенциальные проблемы:

одна страница на самом деле состоит из нескольких страниц, динамически создаваемых JS, требуется взаимодействие с пользователем для получения желаемого состояния
Приложения AJAX могут осуществлять удаленную связь с удаленным сервисом непригодный для офлайн-просмотра.
Скрытые ссылки в javascript-коде. Такой ресурс тогда не является частью хранимой страницы. Даже разбор JS-кода может не обнаружить их. Вам нужно запустить код.
Четное положение базовых html-элементов может быть пересчитано, может быть вычислено динамически JS, и это не всегда возможно/легко воссоздать его локально.
Вам понадобится какой-то дамп памяти JS и загрузите его, чтобы получить страницу в нужном состоянии вы надеялись сохранить

И еще много вопросов...

Проверить Chrome SingleFile расширение. Он хранит веб-страницу в один html файл с изображениями, встроенными с использованием уже упомянутых URI данных. Я не тестировал его, поэтому не могу сказать, насколько хорошо он обрабатывает "изменчивые" страницы ajax.

Ответ 5

Я не вижу оправдания использовать ничего, кроме zipfile

Ответ 6

Хорошо, если поддержка браузера и простота редактирования - это самые большие проблемы, я думаю, что вы застряли в подходе к файлу +, если вы не хотите предоставить редактор для одного формата файла и жить с не очень хорошей поддержкой в браузерах.

Вы можете создать один файл, сжимая содержимое. Вы также можете создать родительский каталог, чтобы упростить обработку.

Ответ 7

Проблема заключается в том, что html имеет нижнюю часть, а не сверху вниз. Посмотрите на свое имя файла, которое было сохранено в моем окне как "Какой лучший" формат файла "для сохранения полных веб-страниц (изображений и т.д.) В одном архиве? - Stack Overflow.html"

Просто добавьте '|' и есть проблемы с копированием и вставкой резервных копий на резервный диск. В конце концов вы в конечном итоге. уничтожая имя файла, чтобы сохранить его. Десятки /, возможно, сотни идентичных index.html или index.php загромождают мои диски.

Частичное решение состоит в том, чтобы написать собственную CMS и использовать сценарии для сопоставления всех соответствующих файлов в плоской файловой базе данных - затем используйте имя файла, размер, mtime и md5, чтобы получить уникальный идентификатор для каждого файла. Создайте индекс плоского файла, разрешающий записи 100k или 1000k. Цель состоит в том, чтобы написать один раз и использовать много раз. Таким образом, вам нужна реальная CMS, вам нужен уникальный идентификатор на основе контента (например, index8765432.html), который входит в ваш файл_архив. То же самое для других. Затем вы можете без разрушительной символической ссылки из сохраненного исходного html в файл_архив и просто воссоздать файл, используя php или альтернативный script, если это необходимо. Не знаю, будет ли это работать, поскольку я нахожусь в той же точке, в которой вы находитесь, - может быть, через неделю это точно будет знать. Более полезный подход состоит в том, чтобы иметь структуру сверху вниз, основанную на ваших деловых или личных потребностях и связанных с ними задачах. Таким образом, ваши файлы могут быть организованы сверху вниз, но внешние снизу вверх, чтобы сохранить исходное содержимое. Я заинтересован в услугах Web 3.0, и чем ближе вы добираетесь до машинного взаимодействия, тем больше потребность в структурировании информации. Может быть, время переосмыслить идею объединения всего в один файл. Таким образом, у вас есть сотни main.css, почему пакет, когда решение сверху вниз может позволить вам изменить один файл, а не сотни.