Какой «формат файла» лучше всего подходит для сохранения полных веб-страниц (изображений и т. д.) В одном архиве?
Я работаю над проектом, в котором отдельные изображения и текстовые файлы хранятся в одном месте, как капсула времени. Теперь почти каждый проект можно сохранить как один файл, например 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 данных становятся все более популярными. Вместо того, чтобы ссылаться на внешнее расположение как MHTML или MAF, вы кодируете файл прямо в разметке HTML как base64. В зависимости от вашего представления, это упрощается, поскольку файлы имеют размер Правильно, где находится разметка. Однако поддержка все еще несколько слабая. Firefox, Opera и Safari поддерживают его без ошибок; IE, лидер рынка, только начал поддерживать его в IE8, да и то с ограничениями.
Затем, конечно, есть «Сохранить всю веб-страницу», где разметка HTML сохраняется как
"savedpage.html", а файлы - в отдельной папке"savedpage_files". Афаик, все так делают. Это хорошо поддерживается. Но необходимость обработки двух отдельных элементов непроста и упрощена в все. В моем проекте они должны быть в единый архив.
Имея в виду поддержка браузера и простота редактирования страницы, как вы думаете, как лучше всего сохранять веб-страницы в одном архиве? Что было бы лучше всего в качестве «стандарта»? Или я должен просто пристегнуться и заняться HTML-файлом и отдельной папкой? Ради моего проекта я поддерживаю мог, но Лучше я этого избегаю.
MAFF основан на обычном формате ZIP с index.html в качестве точки входа для браузеров, чтобы распознать стартовую страницу. Проверьте это: maf.mozdev.org/maff-file-format.html
Похоже, что ситуация осталась прежней. Я хочу перейти с офисных документов на HTML документы, где необходима интерактивность. Я ищу решение, чтобы все было в одном файле. Поскольку html5 допускает автономные веб-приложения, которые могут быть решением, что также может помочь здесь. Что вы думаете? Offline html: Создание автономных веб-приложений HTML5 и Учебник: как создать офлайн-веб-приложение HTML5 в стиле FT
Ответы 7
PDF-файлы поддерживаются почти всеми браузерами практически на всех платформах и хранят контент и изображения в одном файле. Их можно редактировать с помощью подходящих инструментов. Это почти определенно не идеально, но это вариант, который стоит рассмотреть.
ДУХ! Почему я не подумал об этом? Да, PDF используется всеми и их мамами для обмена документами. Редактировать без инструментов непросто, но что важнее, так это поддержка браузера. «Особенно, если я объединил PDF с другим решением, он окажется идеальным. Спасибо!
я не вижу оправдания использовать что-либо кроме zip файла
Я согласен, и мне нравится, как вы это выразили ;-)
Мне больше всего нравится формат ZIP. Потому что:
- Он очень хорошо подходит для этой цели.
- Это хорошо задокументировано
- Доступно множество реализаций для их создания или чтения.
- Пользователь может легко извлекать отдельные файлы, изменять их и возвращать в архив.
- Почти все основные операционные системы (Windows, Mac и большинство Linux) имеют встроенную программу ZIP.
У всех альтернатив есть недостаток:
- С MHTMl вы не сможете легко редактировать.
- Я не знаю, насколько сложной будет реализация с URI данных. (С ZIP, даже я мог сделать это на PHP, 3 года назад ...)
- Возможность хранить вещи как отдельные файлы просто имеет слишком много вещей, которые могут пойти не так и испортить ваш архив.
Отличный совет, эти предложения указывают мне правильное направление. Спасибо!
Просто любопытно, под ZIP вы имели в виду автономный ZIP или формат архива Mozilla на основе ZIP?
Что ж, если поддержка браузера и простота редактирования являются самыми большими проблемами, я думаю, вы придерживаетесь подхода файл + каталог, если только вы не хотите предоставить редактор для одного формата файла и жить с не очень хорошей поддержкой в браузерах.
Вы можете создать один файл, сжав его содержимое. Вы также можете создать родительский каталог, чтобы упростить обработку.
Используйте zip-архив.
Вы всегда можете создать программу / сценарий, который извлекает zip-файл во временный каталог и загружает файл index.html в ваш браузер. Вы даже можете использовать файл index.ini / txt, чтобы указать файл, который должен быть загружен при распаковке.
По сути, вам нужно что-то вроде формата архива Mozilla, но без ненужной дряни в формате rdf, просто чтобы указать, какой файл загружать.
Файлы MHT хороши, но они обычно используют base64 для встраивания файлов, что увеличивает размер файла, чем он должен быть (URI данных аналогичны). Вы можете добавлять вложения как двоичные файлы, но вам придется делать это вручную с помощью шестнадцатеричного редактора или создать инструмент, и поддержка его клиентами может быть не такой хорошей.
Конечно, если вы хотите использовать то, что генерируют браузеры, MHT (по крайней мере, Opera и IE) может быть лучше.
Очень креативный ответ. Вы совершенно правы, когда используете ZIP-файл, а затем распаковываете его во временный каталог для моего проекта. Я могу этим закончить. Хороший совет и по другим форматам. Спасибо!
В зависимости от реализации вам может даже не потребоваться извлекать его во временный каталог, я знаю, что в PHP я могу напрямую читать содержимое ZIP-файла на лету, поэтому мне не нужно было бы извлекать его во временный файл, однако это увеличится Загрузка процессора немного.
Дело не только в формате файла. Еще один важный вопрос - что именно ты хочешь хранить? Это:
сохранить всю страницу как есть со всеми указанными ресурсами - изображениями, CSS и javascript?
для захвата страницы в том виде, в каком она была отображена в определенный момент времени; статический изображение некоторого визуализированного состояния DOM веб-страницы?
Большинство текущих функций «сохранить страницу как» в браузере, будь то в MAF, MHTML или file + dir, предпринимаются первым способом. Это в конечном итоге ошибочный подход.
Не забывайте, что в наши дни веб-страницы - это скорее локальные приложения, чем статический документ, который вы можете легко сохранить. Возможные проблемы:
одна страница - это фактически несколько страниц, динамически создаваемых JS, требуется взаимодействие с пользователем довести его до желаемого состояния
Приложения AJAX могут осуществлять удаленную связь с удаленным сервисом, предоставляющим его. непригоден для просмотра в автономном режиме.
Скрытые ссылки в коде javascript. В таком случае такой ресурс не является частью сохраненной страницы. Даже анализ JS-кода может их не обнаружить. Вам нужно запустить код.
Даже положение базовых элементов HTML может быть пересчитано, может быть вычислено динамически с помощью JS, и не всегда возможно / легко воссоздать его локально.
Вам понадобится какой-то дамп памяти JS и загрузите его, чтобы получить страницу в желаемое состояние. вы надеялись сохранить
И еще много-много вопросов ...
Проверьте расширение Chrome Отдельный файл. Он хранит веб-страницу в одном файле HTML с изображениями, встроенными с использованием уже упомянутых URI данных. Я не очень много тестировал его, поэтому не могу сказать, насколько хорошо он обрабатывает "изменчивые" страницы ajax.
Проблема в том, что html идет снизу вверх, а не сверху вниз. Посмотрите на свое имя файла, которое было сохранено в моем ящике, как «Какой лучший» формат файла »для сохранения полных веб-страниц (изображений и т. д.) В одном архиве? - Stack Overflow.html»
Просто добавьте "|" и у кого-то возникают проблемы с копированием и вставкой резервных копий на запасной диск. В конце концов, вы закончите. вырезать имя файла, чтобы сохранить его. Десятки, а может и сотни идентичных index.html или index.php загромождают мои диски.
Частичное решение - написать собственную CMS и использовать сценарии для сопоставления всех соответствующих файлов с базой данных плоских файлов, а затем использовать fileName, size, mtime и md5, чтобы получить уникальный идентификатор для каждого файла. Создайте индекс плоского файла, разрешающий 100 или 1000 записей. Цель - написать один раз и использовать много раз. Итак, вам нужна настоящая CMS, вам нужен уникальный идентификатор, основанный на содержании (например, index8765432.html), который находится в вашем files_archive. То же для остальных. Затем вы можете неразрушающим образом создать символическую ссылку из сохраненного исходного html в files_archive и просто воссоздать файл, используя php или альтернативный скрипт, если это необходимо. Не знаю, сработает ли это, потому что я нахожусь в той же точке, что и вы - может, через неделю точно узнаю. Более полезный подход - иметь структуру сверху вниз, основанную на вашем бизнесе или личных желаниях и связанных с ними задачах. Таким образом, ваши файлы могут быть организованы сверху вниз, а внешние - снизу вверх, чтобы сохранить исходное содержимое. Меня интересуют сервисы Web 3.0, и чем ближе вы подходите к взаимодействию между машинами, тем больше потребность в структурировании информации. Может быть, пора переосмыслить идею объединения всего в один файл. Итак, у вас есть сотни main.css, зачем связывать, когда нисходящее решение может позволить вам изменить один файл вместо сотен.
Спасибо за ответы! Действительно воняет, что нет стандарта, и его действительно нужно развивать. PDF ближе всего к нему, так как это широко поддерживаемый формат, но ZIP - хороший выбор из-за его превосходной редактируемости. Браузеры действительно должны поддерживать ZIP-файлы, но до тех пор я могу использовать оба решения!