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

Question

В основном вопрос в названии.

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

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

Какие преимущества для выполнения:

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

По сравнению с:

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

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

Answer 1

Согласно Википедии :

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

• HTTP-запрос и трафик заголовка не требуются для встроенных данных, поэтому URI данных потребляют меньшую пропускную способность всякий раз, когда накладные расходы на кодирование встроенный контент как URI данных меньше, чем издержки HTTP. Например, необходимая кодировка base64 для изображения длиной 600 байт будет 800 байтов, поэтому если HTTP-запрос требует более 200 байтов служебной информации, URI данных будет более эффективным.

• Для передачи множества небольших файлов (менее нескольких килобайт каждый) это может быть быстрее. TCP-передачи обычно начинаются медленно. Если для каждого файла требуется новое TCP-соединение, скорость передачи ограничивается временем прохождения сигнала в обоих направлениях, а не доступной пропускной способностью. Использование поддержки активности HTTP улучшает ситуацию, но не может полностью устранить узкое место.

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

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

• Среды с ограниченным или ограниченным доступом к внешним ресурсам может включать контент, когда он запрещен или нецелесообразен для ссылки это внешне. Например, расширенное поле для редактирования HTML может принять вставленное или вставленное изображение и преобразовать его в URI данных в скрыть сложность внешних ресурсов от пользователя. Кроме того, браузер может конвертировать (кодировать) данные на основе изображения из буфер обмена в URI данных и вставьте его в поле редактирования HTML. Mozilla Firefox 4 поддерживает эту функцию.

• Можно управлять мультимедийной страницей как одним файлом. Эл. адрес шаблоны сообщений могут содержать изображения (для фона или подписи) без изображения, являющегося вложением.

Недостатки:

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

• Internet Explorer до версии 7 (примерно 15% рынка по состоянию на январь 2011 года), отсутствует поддержка. Тем не менее, это может быть преодолено путем предоставления конкретного контента для браузера. Internet Explorer 8 ограничивает URI данных максимальной длиной 32 КБ.

• Данные включены в виде простого потока, и многие среды обработки (например, веб-браузеры) могут не поддерживать использование контейнеров (таких как multipart / альтернатива или message / rfc822) для обеспечения большей сложности, например метаданных, сжатия данных или согласование содержания.

• URI данных в кодировке Base64 имеют размер на 1/3 больше, чем их двоичный код эквивалент. (Тем не менее, эти издержки уменьшаются до 2-3%, если HTTP сервер сжимает ответ с помощью gzip) URI данных делают его более трудно для обеспечения безопасности программного обеспечения для фильтрации содержимого.

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

Рабочий пример использования URI данных для "предложения загрузки таблицы в формате CSV" описан в моем блоге .

ИМХО, вставка данных изображения (или другого двоичного ресурса) в файл HTML по соображениям производительности - это красная сельдь. Увеличение скорости за счет меньшего количества HTTP-соединений незначительно и нарушает хороший принцип разделения (текстовой) разметки и двоичных ресурсов (файлов изображений, видео и т. Д.).

Я думаю, что конвейерная обработка HTTP 1.1 и некоторые предлагаемые улучшения HTTP - более чистый и лучший способ решения проблем скорости сети HTTP.