Зачем использовать схему URI данных?

В основном вопрос находится в названии.

У многих людей возник вопрос о том, как создать URI данных и проблемы с ним.

Мой вопрос: зачем использовать URI данных?

В чем преимущества:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

Чем заняться:

<img src="dot.png" alt="Red dot" />

Я понимаю, что на стороне сервера (возможно) меньше накладных расходов, но каковы преимущества/недостатки реальных для использования URI данных?

Ответ 1

Согласно Wikipedia:

Преимущества:

HTTP-запрос и трафик заголовка не требуются для встроенных данных, поэтому URI данных потребляют меньше полосы пропускания всякий раз, когда накладные расходы на кодирование встроенный контент как URI данных меньше, чем накладные расходы HTTP. Например, требуемая кодировка base64 для изображения длиной 600 байтов будет 800 байт, поэтому, если HTTP-запрос требует более 200 байтов служебных данных, URI данных будет более эффективным.
Для переноса многих небольших файлов (менее одного килобайта каждый) это может быть быстрее. Передачи TCP обычно начинаются медленно. Если для каждого файла требуется новое TCP-соединение, скорость передачи ограничена временем округления, а не доступной полосой пропускания. Использование HTTP keep-live улучшает ситуацию, но не может полностью устранить узкое место.
При просмотре защищенного веб-сайта HTTPS веб-браузеру обычно требуется, чтобы все элементы веб-страницы загружались через защищенные соединения, или пользователь будет уведомлен об уменьшенной безопасности из-за сочетания безопасных и небезопасных элементов. На плохо сконфигурированных серверах запросы HTTPS имеют значительные накладные расходы по сравнению с обычными HTTP-запросами, поэтому вложение данных в URI данных может улучшить скорость в этом случае.
Веб-браузеры обычно настроены на создание только определенного номера (часто два) одновременных HTTP-соединений с доменом, поэтому inline данные освобождают соединение для загрузки для другого контента.
Среды с ограниченным или ограниченным доступом к внешним ресурсам может вставлять контент, когда он запрещен или непрактичен для ссылки он внешне. Например, расширенное поле редактирования HTML могло бы принять вставленное или вставленное изображение и преобразовать его в URI данных в скрыть сложность внешних ресурсов от пользователя. В качестве альтернативы браузер может преобразовывать (кодировать) данные на основе изображений из буфер обмена в URI данных и вставить его в поле редактирования HTML. Mozilla Firefox 4 поддерживает эту функциональность.
Можно управлять мультимедийной страницей как единым файлом. Эл. адрес шаблоны сообщений могут содержать изображения (для фона или подписи) без изображения, являющегося "приложением".

Недостатки:

URI данных отдельно не кэшируются из их содержащих документов (например, CSS или HTML файлы), поэтому данные загружаются каждый раз, когда содержащие документы, перезагружаются. Содержимое должно быть перекодировано и повторно внедряется каждый раз, когда происходит изменение.
Internet Explorer по версии 7 (примерно 15% рынка по состоянию на январь 2011 года) не имеет поддержки. Однако это можно преодолеть, обслуживая конкретный контент браузера. Internet Explorer 8 ограничивает URI данных максимальной длиной 32 КБ.
Данные включены как простой поток, и многие среды обработки (например, веб-браузеры) могут не поддерживать использование контейнеров (например, multipart/alternative или message/rfc822), чтобы обеспечить большую сложность, такую как метаданные, сжатие данных, или согласование содержимого.
URI с кодировкой Base64, размер которых на 1/3 больше, чем их двоичный эквивалент. (Однако эти накладные расходы сокращаются до 2-3%, если HTTP сервер сжимает ответ с помощью gzip) URI данных делают его более сложно защитить программное обеспечение для фильтрации содержимого.

Согласно другим источникам - URL-адреса данных значительно медленнее в мобильных браузерах.

Ответ 2

Хорошее использование URI данных позволяет загружать контент, который был сгенерирован на стороне клиента, не прибегая к прокси-серверу на стороне сервера. Вот пример, который я могу придумать:

сохранение вывода элемента холста в качестве изображения.
предложение загрузки таблицы в формате CSV
загрузка результатов любого вида онлайн-редактора (текст, рисунок, код CSS... и т.д.)

Ответ 3

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

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

В противном случае, лично я не буду кодировать большие изображения в виде фотографий. Лучше иметь медиа на другом сервере. Сервер, на котором может отсутствовать все программное обеспечение, связанное с веб-сервером. Просто доставка носителей. Намного лучше использовать ресурсы.

Ответ 4

Я использовал схему URI данных в нескольких (С++, Python) приложениях командной строки для генерации отчеты, которые включают в себя данные.

Наличие одного файла довольно удобно отправлять отчеты по электронной почте (или перемещать их в целом). По сравнению с PDF мне не нужна дополнительная библиотека (кроме кодировки base64 ), и мне не нужно заботиться о разрывах страниц (и мне почти никогда не нужно печатать эти отчеты). Обычно я не помещаю эти отчеты на веб-сервер, просто просматриваю их на локальная файловая система с браузером.

Ответ 5

Я согласен с BiAiB в том, что реальное значение URI данных делает доступный на стороне клиента контент доступным для загрузки файлов без каких-либо проблем с серверами.

В моем блоге описывается рабочий пример использования URI данных для "предоставления загрузки таблицы в виде CSV" некоторые предлагаемые улучшения в HTTP - это более чистый и лучший способ справиться с проблемами скорости HTTP-сети.