Каков наилучший "формат файла" для сохранения полных веб-страниц (изображений и т. д.) в одном архиве? [закрытый]
Я работаю над проектом, который хранит отдельные изображения и текстовые файлы в одном месте, например, капсулу времени. Теперь почти каждый проект можно сохранить как один файл, например 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.
сведения Урис!--13--> становятся все более популярными. Вместо ссылки на внешнее расположение a la MHTML или MAF вы кодируете файл прямо в разметку HTML как base64. В зависимости от вашего представления, он оптимизирован, так как файлы право где разметка. Однако поддержка все еще несколько слаба. Firefox, Opera и Safari поддерживают его без ошибок; т. е. лидер рынка, только начал поддерживать его в IE8, и даже тогда с ограничениями.
тогда, конечно, есть "сохранить полную веб-страницу" где разметка HTML сохраняется как
"savedpage.html"и файлы в отдельной"savedpage_files"папка. Афайк, все так делают. Он хорошо поддерживается. Но необходимость обрабатывать два отдельных элемента не является простой и обтекаемой в все. Мой проект должен иметь их в одним файлом.
имея в виду поддержка браузеров и простота редактирования страницы, как вы думаете, лучший способ сохранить веб-страницы в одном архиве? что было бы лучше всего в качестве "стандарта"? Или я должен просто пристегнуться и иметь дело с HTML-файлом и отдельной папкой? Ради моего проекта я ... --3-->может поддержка, но мне лучше избегать этого.
7 ответов
мой любимый формат ZIP. Потому что:
- Это очень хорошо sutied для этой цели
- Это хорошо документированы
- существует множество реализаций, доступных для их создания или чтения
- пользователь может легко извлечь отдельные файлы, изменить их и вернуть в архив
- почти каждая основная операционная система (Windows, Mac и большинство linux) имеет встроенную программу ZIP
альтернативы у всех есть какой-то изъян:
- С MHTMl, вы не можете легко редактировать.
- С данными URI я не знаю, насколько сложной будет реализация. (С ZIP, даже я мог бы сделать это на PHP, 3 года назад...)
- вариант для хранения вещей как отдельные файлы, так и слишком много вещей, которые могут пойти не так и испортить ваш архив.
PDF поддерживаются почти во всех браузерах почти на всех платформах и хранят содержимое и изображения в одном файле. Их можно редактировать с помощью правильных инструментов. Это почти определенно не идеально, но это вариант для рассмотрения.
Это не только вопрос формата файла. Еще один важный вопрос:что именно вы хотите хранить? Это:
сохранить всю страницу, как это со всеми ссылочными ресурсами-изображения, CSS и javascript?
для захвата страницы, как она была отображена в какой-то момент времени; статический изображение некоторого отображаемого состояния веб-страницы DOM?
самая последняя функциональность "сохранить страницу как" в браузере, будь то MAF или MHTML или file+dir, пытается первый способ. Это в конечном счете ошибочный подход.
Не забывайте, что веб-страницы есть довольно локальные приложения, а затем статический документ, который вы можете легко хранить. Потенциальные проблемы:
одна страница-это фактически несколько страниц, динамически создаваемых JS, требуется взаимодействие с пользователем чтобы получить желаемое состояние
AJAX приложения могут выполнять удаленную связь с удаленным обслуживанием непригодными для вид в автономном режиме.
скрытые ссылки в коде JavaScript. Такой ресурс не является частью сохраненной страницы. Даже анализ кода JS может не обнаружить их. Вам нужно запустить код.
даже положение основных элементов html может быть пересчитано может быть вычислено динамически JS и не всегда возможно/легко воссоздать его локально.
вам понадобится какой-то дамп памяти JS и загрузите его, чтобы получить страницу в нужное состояние вы надеялись сохранить
и многие другие вопросы...
Проверить Chrome SingleFile
используйте zip-файл.
вы всегда можете создать программу / скрипт, который извлекает zip-файл во временный каталог и загружает индекс.html-файл в вашем браузере. Вы даже можете использовать индекс.ini / txt файл, чтобы указать файл, который должен быть загружен при извлечении.
в принципе, вы хотите что-то вроде формата архива Mozilla, но без ненужного дерьма rdf просто указать, какой файл загружать.
MHT файлы хороши, но они обычно используют base64 для внедрите файлы, которые сделают размер файла больше, чем он должен быть (URI данных одинаковы). Вы можете добавлять вложения как двоичные, но вам придется вручную сделать это с помощью шестнадцатеричного редактора или создать инструмент, и поддержка его клиентами может быть не так хороша.
конечно, если вы хотите использовать то, что генерируют браузеры, MHT (Opera и IE, по крайней мере) может быть лучше.
Ну, если поддержка браузера и простота редактирования являются самыми большими проблемами, я думаю, что вы застряли с подходом file+directory, если вы не готовы предоставить редактор для одного формата файла и жить с не очень хорошей поддержкой в браузерах.
вы можете создать один файл, сжимая содержимое. Вы также можете создать родительский каталог, чтобы облегчить обработку.
проблема в том, что html снизу вверх, а не сверху вниз. Посмотрите на свое имя файла, которое сохранено на моем поле как "какой лучший" формат файла " для сохранения полных веб-страниц(изображений и т. д.) в одном архиве? - переполнение стека.HTML-код"
просто добавьте"|", и у вас есть проблемы с копированием и вставкой резервных копий на запасной диск. В конце концов. вырезание имени файла, чтобы сохранить его. Десятки/, возможно, сотни одинаковых индексов.html или индекс.в PHP загромоздили мою приводы.
частичное решение-написать собственную CMS и использовать скрипты для сопоставления всех соответствующих файлов с базой данных плоских файлов, а затем использовать имя файла, размер, mtime и md5 для получения уникального идентификатора для каждого файла. Создайте плоский индекс файла, позволяющий 100k или 1000k записей. Цель состоит в том, чтобы написать один раз и использовать много раз. Поэтому вам нужна настоящая CMS, вам нужен уникальный идентификатор на основе контента (например, index8765432.html), который идет в вашем files_archive. То же самое для остальных. Затем вы можете неразрушающе symlink из сохраненный исходный html в files_archive и просто воссоздать файл с помощью php или альтернативного сценария, если это необходимо. Не знаю, сработает ли это так, как я в тот же момент, что и вы, - может быть, через неделю узнаю наверняка. Более полезный подход - иметь структуру сверху вниз, основанную на ваших деловых или личных желаниях и связанных с ними задачах. Так что ваши файлы могут быть организованы сверху вниз, но внешние снизу вверх, чтобы сохранить исходное содержание. Мой интерес в Web 3.0 services и чем ближе вы получаете для взаимодействия машины с машиной тем больше необходимость структурировать информацию. Возможно, пришло время переосмыслить идею объединения всего в один файл. Таким образом, у вас есть сотни main.css зачем связывать, когда решение сверху вниз может позволить вам изменить один файл вместо сотен.