Image svg xml base64 как найти файл

Обновлено: 04.07.2024

Data URL, URL имеющий приставку data: , делает возможным встраивание файлов небольшого размера прямо в документ.

Заметьте: современные браузеры обрабатывают Data URL, как неявный уникальный origin, и не заимствуют значение origin из объекта настроек ответственного за навигацию.

Синтаксис

Data URL состоит из четырёх сегментов: приставки ( data: ), MIME типа, описывающего тип данных, дополнительного ключевого слова base64 для нетекстовых данных и самой строки данных:

тип данных описывается строкой в формате MIME типа, например 'image/jpeg' для JPEG файла изображения. При не указывании типа данных, браузер автоматически будет интерпретировать строку данных, как text/plain;charset=US-ASCII

Если данные представляют собой какую-либо текстовую информацию, вы можете просто вставить эту текстовую строку в Data URL (используя соответствующие для типа данных сущности и знаки экранирования). В ином случае вам будет необходимо использовать ключевое слово base64 перед вставкой base64-кодированных бинарных данных. Дополнительную информацию о MIME типах вы сможете найти здесь и здесь (en-US).

data:,Hello%2C%20World! Простые text/plain данные data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D base64-кодированная версия примера выше data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E HTML строка вида: <h1>Hello, World!</h1> data:text/html,<script>alert('hi');</script> HTML строка, вызывающая JavaScript alert функцию. Заметьте необходимость закрывающего <script> тега.

Кодирование данных в формат base64

Base64 относится к группе транспортных кодировок, и позволяет представлять бинарные данные в виде ASCII строк, переводя их в radix-64 представление. Состоя только из ASCII символов, base64 строки являются допустимыми для использования в URL, по этой причине они могут быть использованы и в Data URL.

Кодирование в Javascript

Web API имеет встроенные методы для кодирования и декодирования формата base64: Base64 кодирование и декодирование.

Кодирование на Unix системах

На Linux и Mac OS X системах, кодирование файлов или строк в формат Base64 может быть выполнено через программу base64 в командной строке (или, в качестве альтернативы, программу uuencode с -m аргументом).

Кодирование на Microsoft Windows

Кодирование на Windows может быть выполнено через powershell или какую-либо другую предназначенную для этого программу. Так же кодирование может быть выполнено и через программу base64 (смотрите секцию Кодирование на Unix системах), при условии активированной технологии WSL.

Распространённые проблемы

Эта секция описывает ряд проблем, которые могут возникнуть при использовании Data URL.

Для примера рассмотрим Data URL вида:

результатом декодирования которого будет HTML строка:

Синтаксис Data URL представляет собой простой формат, но даже в нём можно забыть добавить запятую перед сегментом данных или произвести ошибку во время их base64 кодирования. Форматирование внутри документа Встраивание Data URL по сути является встраиванием файла внутрь файла, и длина его строки может быть намного шире, чем ширина заключающего его документа. Так же, несмотря на то, что использование пробелов считается обычной практикой при форматировании данных, есть вероятность, что у вас возникнут проблемы при их base64 кодировании. Ограничения длины Хотя Firefox поддерживает Data URL практически неограниченных размеров, каждый отдельный браузер имеет свои ограничения на их длину. Например, Opera 11 ограничивает допустимую длину URL до 65535 символов, что означает ограничение сегмента данных в Data URL до 65529 символов (длина в 65529 символов взята из условия использования только только data: сегмента, без определения MIME типа данных). Нехватка возможности обработки ошибок Опечатки в определении MIME типа или написания ключевого слова 'base64' будут проигнорированы без каких-либо уведомлений об ошибках. Отсутствие поддержки строки параметров

В связи с неопределённостью типа сегмента данных в Data URL, строка параметров (характерные для страницы параметры, представляющиеся в виде <url>?parameter-data ), добавленная к сегменту данных будет рассматриваться, как часть этих данных.

Проблемы с безопасностью Несколько проблем с безопасностью (например: фишинг) связаны с Data URL и переходом по ним из корневого контекста документа. Чтобы избавиться от этих проблем, переход по URI, начинающихся со схемы data:// , из корневого контекста документа перестал быть возможен в Firefox, начиная с версии 59 (и начиная с версии 58 в Nightly/Beta вариантах браузера). Надеемся, что остальные браузеры так же последуют этому примеру. Для дополнительной информации смотрите Blocking Top-Level Navigations to data URLs for Firefox 58.

Что касается растровых изображений, подобных PNG, то их данные, вне всякого сомнения, должны быть представлены в формате base64. Не берусь утверждать на 100%, так как не являюсь экспертом в этой области, но насколько я понимаю, выбор именно этой кодировки объясняется тем, что она безопасна для использования на HTML и CSS платформах, поскольку в ней используются только допустимые, так называемые безопасные, символы для этих сред.

Вероятно, более полным будет ответ Дэйва Маркла (Dave Markle) из Stack Overflow:

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

Поэтому для обхода подобных ситуаций люди кодируют двоичные данные в символы. Base64 является одной из таких кодировок.

Внешне Base64 выглядит как абракадабра и зачастую мы воспринимаем этот код как результат используемой в Web компрессии. Однако в отличие от сжатых файлов, по объему эта абракадабра даже слегка превышает исходный код. Так происходит по причине, которую неплохо объяснил Джон Скит (Jon Skeet) на все том же Stack Overflow:

На кодировку трех байтов данных уходит 4 символа, плюс потенциальный бит заполнения в конце последовательности.

Для представления SVG формата тоже можно использовать URI данные:

В случае с SVG у вас нет необходимости в конвертировании данных в base64. Опять же повторюсь. Я не эксперт в этой области, однако, насколько я понимаю, SVG синтаксис просто напросто не содержит каких-либо «сумасшедших» символов. Это обычный XML, который подобен HTML и поэтому не должен вызывать конфликтов c HTML.

Вы можете оставить данные в UTF-8 кодировке и попросту вставить исходный <svg> синтаксис:

Для того, чтобы опробовать это на деле я загрузил из IcoMoon три SVG пиктограммы.

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

Затем я пропустил их через base64 конвертор.

Теперь все сходится, так ведь? Если на каждые 3 байта уходит 4 символа, значит это на 133% больше, с допустимыми отклонениями, вызванными нечетной длиной, а значит с использованием заполняющего символа.

Я не знаю, может быть это слишком очевидно, чтобы быть сенсацией, однако, как по мне, так если вы собираетесь использовать SVG в виде URI данных, то нет никакой причины для их base64 кодировки.

Статья написана благодаря e-mail от Мэта Флэскена (Matt Flaschen), присланного мне несколькими месяцами ранее, где он и обозначил эту тему.

Все вроде бы просто и понятно, однако, как оказалось, предложенный Крисом способ работает не во всех браузерах, причем, речь идет даже не о старых их версиях (Safari 7, IE11). Где же выход?

Кодировки SVG все-таки не удастся избежать, поскольку этот формат может содержать «небезопасные» символы. Векторные изображения могут иметь растровые включения или атрибуты, значения которых заключены в одиночные или двойные кавычки. Поэтому предварительная обработка (нормализация) данного формата все же потребуется. Только это совсем не обязательно должен быть base64. Более приемлемым является способ, предусматривающий представление URI данных с помощью URL-кодирования. Такого результата можно достигнуть с помощью метода encodeURIComponent() . Всем известно, что содержащиеся в ссылке запрещенные для прямого использования в URL символы, рекомендуется экранировать их UTF-8 эквивалентами с предшествующим знаком процента (%). Не смотря на то, что такой метод приводит к еще большему увеличению объема кода, чем в случае с base64, однако после gzip обработки ситуация меняется на совершенно противоположную, т.е. результат сжатия UTF-8 значительно ниже его аналога в base64. Тем не менее, некоторые инструменты, такие как, к примеру, LESS в качестве URI данных по умолчанию вставляют SVG уже кодированный в base64.

Получается, что необходимость в кодировке SVG изображений все-таки есть, только вот UTF-8 в данном случае предпочтительнее.

Я написал код для захвата изображений с помощью javascript / jquery. Ниже приведен код:

Item_image печатает формат base64, как преобразовать этот base64 в изображение и как использовать этот путь на стороне клиента javascript.

Я ищу в Google так много веб-сайтов, но он не работает, и этот код не подходит для моих требований.

Если вы хотите, чтобы данные base64 были изображением, вам нужно будет обработать эту строку на стороне сервера и использовать путь к сохраненному изображению на стороне сервера. Вы можете сделать это с помощью метода Ajax Post.

Вы можете просто создать Image объект и поместить base64 в качестве своих src , в том числе data:image. части , как это :

Это то, что они называют «URI данных», а вот таблица совместимости для внутреннего спокойствия.

Вы можете четко объяснить, означает, что изображение возвращает элемент html объекта и как читать как изображение Здесь я пишу тег img <img src = "d: \\ face.jpg" border = 1> и использую этот код document.getElementById ('myImg'). Src = item_image; // <img tag > но он не работает Это потому, что ваш код удалил data:image. часть из item_image . Я думаю, что ищу то же самое, что и OP. Я считаю, что он хочет, чтобы URL-адрес изображения указывал на .jpg, а не на исходную строку в кодировке base64. Ищу конверсию где-нибудь там, если это возможно. @John, вам нужно будет где-то сохранить, загрузить и разместить файл, поскольку URI данных не имеет ссылки на то, откуда файл изначально пришел.

Это не совсем сценарий OP, но ответ на некоторые из комментаторов. Это решение, основанное на Cordova и Angular 1, которое должно быть адаптировано к другим фреймворкам, таким как jQuery. Он дает вам Blob из данных Base64, которые вы можете где-то хранить и ссылаться на него из javascript / html на стороне клиента.

Он также отвечает на исходный вопрос о том, как получить изображение (файл) из данных Base 64:

Важной частью является Base 64 - двоичное преобразование:

Нарезка необходима, чтобы избежать ошибок нехватки памяти.

Работает с файлами jpg и pdf (по крайней мере, то, что я тестировал). Должен работать и с другими типами mimetypes / contenttypes. Проверьте браузеры и их версии, к которым вы стремитесь, они должны поддерживать Uint8Array, Blob и atob.

Вот код для записи файла в локальное хранилище устройства с помощью Cordova / Android:


Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

Для растровых изображений, таких как PNG, данные самого изображения должны быть представлены в кодировке base64. Я не супер-эксперт в данной теме, но если я правильно понял, кодировка base64 является безопасной для использования в документах типа HTML или CSS, потому что в ней используются только 64 символа, являющиеся безопасными для использования в подобного рода документах.


Слева вы видите исходные данные изображения в формате PNG, содержащие символы, которые потенциально могут нанести вред целостности HTML документа. А справа – те же самые данные, закодированные с помощью base64 и представленные в виде безопасных символов.

Пожалуй, лучше будет прочитать ответ Дэйва Маркла (Dave Markle) на сайте Stack Overflow:

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

Base64 выглядит, как бессвязный набор символов, и относительно веба такой набор обычно ассоциируется с процессом сжатия. Но он не является сжатием. На самом деле он даже немного больше исходных данных, потому что, цитируя Джона Скита (Jon Skeet) в том же обсуждении на сайте Stack Overflow:

Происходит преобразование 3 байтов данных в 4 символа, плюс может происходить добавление пробелов/других символов в конце.

Я не уверен, как на этом сказывается сжатие gzip. Но мне хочется рассмотреть здесь, что происходит с SVG. Вы можете применять data: URI для SVG:

Поддержка браузерами data:URL

Хотя Opera 7.2+, Firefox, Safari, Netscape и Mozilla поддерживают data:URI , Internet Explorer 5–7 совсем нет. Однако, сообщается, что Internet Explorer 8 будет поддерживать эту схему, так как проходит Acid2 тест, что позволяет использовать data:URL как реальную альтернативу для внедрения небольших декоративных изображений. Существует также несколько приемов для поддержки старых версий Internet Explorer.

Схема data:URL

В случае простых изображений вам нужно указать mime-тип для них (например, image/gif ), за ним идет base64-представление бинарного файла с изображением. Ниже приведен пример (переводы строк добавлены, чтобы не разрывать страницу, на самом деле, их нет):

В результате вы получите следующее изображение иконки папки (частичный скриншот ниже):

CSS и встроенные изображения

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

Теперь иконка папки будет повторяться для каждого вхождения LI (или можно также использовать соответствующий класс или ID ).

Что выглядит в Firefox примерно следующим образом (частичный скриншот):

Проблемы data:URL

С описанным выше подходом для подключения изображений связано две основные проблемы. Во-первых, вам нужно пересчитывать base64-представление изображений и редактировать CSS-файл каждый раз, когда само изображением меняется. Также IE до версии 7 включительно не поддерживает встроенных изображений. У первой проблемы есть простой решение на PHP:

Этот код читает файл с изображением и автоматически преобразовывает его на сервере в base64. Однако, это простота этого решения повлечет некоторую дополнительную нагрузку на сервер. Как вариант можно рассмотреть автоматический пересчет всех картинок и вставка их в CSS-файл, например, раз в 5 минут по необходимости (если файл с изображением изменился). Дополнительно нужно будет озаботиться, чтобы сбросить кеширование для самого CSS-файла.

Работа в Internet Explorer

Существует два способа обойти отсутствие в IE поддержки data:URL . Используя распознавание браузеров (например, с помощью условных комментариев, ведь речь идет только про IE) можно просто отображать внешнее изображение для IE и встроенные изображения для остальных браузеров. Или вы можете использовать JavaScript для эмуляции этой поддержки в IE, но эта техника потребует довольно значительного объема JavaScript-кода. Вышеприведенный PHP-код позволяет легко вставить base64-аналог изображения (можно расширить этот пример, чтобы, например, распознавать заголовки, отправляемые браузером серверу и только для IE выводить URL для изображения, для остальных же кодировать его в base64):

Когда ваш сервер анализирует CSS-файл, он автоматически перекодирует бинарный файл изображения в base64 и отправит эти данные внутри CSS-файла. Следующим шагом будет добавление распознавания браузеров для отправки изображения только IE, и встроенных изображений всем остальным. Это можно сделать либо внутри CSS-файла с PHP-кодом, либо с помощью условных комментариев, например:

В файле ie.css должно быть нормальное обращение к картинке, например:

Лично мне вышеприведенный код кажется сомнительным: все браузеры, кроме IE, посчитают, что CSS-файлы закомментированы и вообще к ним не обратятся. Поэтому я бы советовал оставить комментарии только для первого файла и переместить его вызов в конец, чтобы он переопределял общие стилевые правила.

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

Недостатки data:URL

Встроенные изображения не поддерживаются в Internet Explorer 5–7, хотя сообщается, что версия 8 их поддерживает. Текстовое base64-представление данных также занимает больше, чем бинарное изображение. В наших тестах base64-данные были на 39–45% больше бинарного аналога, но gzip-сжатие позволяет уменьшить разницу до 89%. Предварительная оптимизация изображений перед base64-кодированием позволяет уменьшить их размер пропорционально.

Также существует ряд ограничений на размер встроенных изображений. От браузеров требуется поддерживать только URL длиной до 1024 байтов, в соответствие с вышеупомянутой спецификацией RFC. Однако, браузеры более либеральны к пользователям в том, что они принимают. Например, Opera ограничивает data:URL до примерно 4100 символов. Firefox поддерживает data:URL вплоть до 100Кб. В итоге, эта техника подходит больше для небольших по размеру изображений. Краткий список минусов:

  • Не поддерживается IE до 7 версии включительно.
  • Требуются дополнительные действия для обновления внедренного содержания (перекодировать, еще раз вставить).
  • Ограничена длина. Эта техника может быть полезна для вставки небольших, декоративных изображений.
  • Изображения, представленные в base64-кодировке, примерно на 33% больше размера их бинарного аналога.
  • Спасибо, zerkms, встроенные картинки (не в CSS) не получится закешировать по определению. Они будут кешироваться только с HTML-кодом.

Примеры data:URL

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

Дополнительные соображения по оптимизации

Наиболее разумным будет, мне кажется, подход, не увеличивающий общее число CSS-файлов, т.е. использующий характерные хаки для IE, чтобы только для него подключить фоновые изображения. Для IE версий 6 и ниже можно использовать * html , для IE 7, к сожалению, этот хак уже не работает, поэтому используем *+html (спасибо за дополнение Bueno). В итоге, вышеприведенный пример будет выглядеть примерно так:

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

Для включения небольших графиков прямо в HTML-код прекрасно подойдут условные комментарии, когда для ряда браузеров изображение выводится в base64, а для остальные в виде IE подключается через условные комментарии. Если использовать связку относительное позиционирование родителя абсолютное позиционирование дочернего элемента, то IE будет просто выводить картинку из внешнего файла поверх непонятного (для него) объекта. Например, так:

Оба примера использования можно посмотреть на webo.in: на главной странице график выводится прямо в теге img , фоновый CSS sprite в CSS-файле записан также в base64-кодировке. Если у кого-то не отображается какая-либо картинка, напишите, пожалуйста, в комментариях будем думать над решением.

Хочу подчеркнуть, что решение об использовании data:URL должно приниматься на основе статистики использования браузеров для просмотра сайта (для webo.in доля IE составляет меньше 20%, что позволяет использовать более прогрессивные методы для оптимизации скорости загрузки).

Заключение

Читайте также: