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

Question

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

• Microsoft имеет MHTML - в основном файл закодирован именно как сообщения электронной почты MIME HTML. Он уже основан на существующем стандарте, и MHTML как его собственный был предложен как rfc2557. Это отличная идея, и это было навсегда, за исключением того, что это был «предложенный стандарт» с 1999 года. Кроме того, реализации, отличные от IE, просто громоздки. IE и Opera поддерживают его; Firefox и Safari с громоздким расширением.

• Mozilla имеет Mozilla Archive Format - в основном ZIP-файл с разметкой и изображениями, с метаданными, сохраненными как RDF. Это потрясающая идея - Winamp делает это для скинов, ODF и OOXML для своих встроенных изображений. Мне это нравится, за исключением: 1. Никто кроме Mozilla не использует его, 2. Единственное поддерживающее его расширение не обновлялось с Firefox 1.5.

• Data URIs становятся все более популярными. Вместо ссылки на внешнее местоположение a la MHTML или MAF, вы кодируете файл прямо в HTML-разметку как base64. В зависимости от вашего вида, он оптимизирован, так как файлы справа, где разметка есть. Однако поддержка по-прежнему несколько слабая. Firefox, Opera и Safari поддерживают его без помех; IE, лидер рынка, только начал поддерживать его в IE8, и даже тогда с ограничениями.

• Тогда, конечно, есть «Сохранить полную страницу» где HTML разметка сохраняется в "savedpage.html" и файлы в отдельной папке "savedpage_files". Афайк, все это делают. Это хорошо поддерживается. Но иметь дело с двумя отдельными элементами не просто и обтекаемо на все. Мой проект должен иметь их в архиве .

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

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

Answer 6

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

1. магазин целую страницу, как это со всеми ссылочные ресурсы - картинки, CSS и JavaScript?

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

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

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

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

2. AJAX приложения могут сделать дистанционную связь с удаленным сервисом делает его непригодный для офлайн-просмотра.

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

4. Четное положение базовых элементов html может быть пересчитано динамически по JS, и это не всегда возможно/легко воссоздать его локально.

5. Вам потребуется какое-то дамп памяти JS и загрузить эту страницу, чтобы получить в нужное состояние вы надеялись сохранить

И много много больше вопросов ...

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

Answer 7

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

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

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