Исходный SVG-код из строки Data URI

Онлайн-конвертер восстанавливает исходный SVG-код из строки Data URI, возвращая закодированной векторной графике ее первоначальную текстовую структуру. Инструмент принимает инлайновые строковые данные со схемой data:image/svg+xml и выполняет их обратное преобразование. В результате декодирования формируется читаемая XML-разметка с корневым тегом <svg> , полностью готовая к редактированию. Весь процесс происходит автоматически без ручного удаления служебных префиксов и замены спецсимволов.

Встраивание графики напрямую в CSS-правила или HTML-документы через схему Data URL избавляет браузер от лишних сетевых запросов, но делает сам рисунок непригодным для прямого чтения и правки.

Декодер решает эту проблему при работе с обоими типами представления данных: текстом с процентным кодированием символов и строками в кодировке Base64. Алгоритм отделяет служебные метаданные от полезной нагрузки и переводит содержимое в стандартный формат векторной разметки. Полученный код можно сразу внедрить в DOM-дерево страницы, сохранить в отдельный файл с расширением .svg или открыть в профильном графическом редакторе для изменения геометрии контуров и стилей.

Структура строки Data URI и схемы кодирования SVG

Входная строка со встроенной векторной графикой строится по жесткому синтаксическому шаблону, который разделяет служебный заголовок и само содержимое файла. Базовая формула записи выглядит как data:[<media type>][;charset=<encoding>][;base64],<data> . Каждый сегмент до разделительной запятой задает правила чтения последующего массива символов.

Служебный заголовок и блок данных в схеме Data URL состоят из следующих обязательных и опциональных компонентов:

• Префикс data: объявляет начало схемы и указывает на то, что ресурс встроен непосредственно в строку, а не загружается по внешнему сетевому пути.
• Идентификатор MIME type (media type) со значением image/svg+xml сообщает обработчику, что внутри находится векторное изображение на базе XML-разметки. Если этот параметр пропущен, по умолчанию предполагается обычный текстовый формат text/plain;charset=US-ASCII , что не позволяет отобразить графику.
• Параметр набора символов, такой как ;charset=utf-8 или сокращенный вариант ;utf8 , явно фиксирует текстовую кодировку UTF-8 для корректной интерпретации многобайтовых символов.
• Флаг ;base64 добавляется только в том случае, если полезная нагрузка переведена в соответствующее текстовое представление двоичных данных.
• Запятая ( , ) служит строгим синтаксическим разделителем, отделяющим декларацию метаданных от тела документа. Все символы, идущие сразу после первой запятой, представляют собой закодированный SVG-файл.

Текстовое процентное кодирование и формат Base64

Полезная нагрузка после запятой записывается одним из двух способов: в виде текста с экранированием специальных символов (percent-encoding, или URL encoding) либо как непрерывная строка Base64. Выбор схемы на этапе генерации строки влияет на ее итоговую длину, читаемость и набор допустимых знаков.

Стандарт языка разметки SVG базируется на обычном тексте (plain text), однако прямая вставка тегов в адресную строку или табличное свойство часто нарушает синтаксис родительского документа. Проблема возникает из-за различий между базовым набором US-ASCII, многобайтовой кодировкой UTF-8 и ограниченным перечнем безопасных символов URL-safe characters. Набор URL-safe включает только латинские буквы, цифры и несколько знаков пунктуации (дефис, точку, нижнее подчеркивание, тильду), тогда как синтаксис XML активно использует угловые скобки, кавычки и пробелы, а атрибуты цвета содержат символ решетки.

При использовании URL encoding структура исходного текста сохраняется, но все конфликтующие и небезопасные знаки заменяются на шестнадцатеричные hex-коды с префиксом процента. Например, открывающая скобка < превращается в %3C , закрывающая > - в %3E , а символ решетки # в цветовых кодах обязательно заменяется на %23 , иначе строка после него воспринимается как идентификатор фрагмента (хэш), и чтение данных обрывается. Двойные кавычки часто заменяют на одинарные или кодируют как %22 .

Схема Base64 работает иначе: исходный текст в кодировке UTF-8 сначала рассматривается как поток байтов (двоичная информация), который затем разбивается на группы по 6 бит и сопоставляется с таблицей из 64 безопасных ASCII-символов (буквы A-Z , a-z , цифры 0-9 , знаки + и / , а также = для выравнивания длины в конце). Такая строка полностью лишена синтаксических конфликтов с кавычками или скобками, но увеличивает объем текстовых данных примерно на треть и полностью скрывает структуру тегов до момента обратной конвертации.

В таблице ниже приведено сравнение двух типов записи векторных данных внутри схемы Data URI:

Принцип декодирования Data URI и извлечения SVG-разметки

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

Синтаксический анализ строки и отделение полезной нагрузки

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

Для получения чистой информационной части при разборе строки последовательно отсекаются следующие служебные и внешние элементы:

• Внешние синтаксические конструкции, включая обертку url( в начале и закрывающую скобку ) в конце строки.
• Обрамляющие кавычки любого типа, которые использовались для изоляции строкового литерала.
• Служебный префикс схемы и медиатипа data:image/svg+xml вместе с дополнительными параметрами кодировки.
• Разделительная запятая, фиксирующая границу между заголовком с метаданными и началом закодированного документа.

Поиск первой запятой в структуре Data URI является ключевой операцией парсинга: все символы слева от нее трактуются исключительно как инструкции для обработчика, а вся последовательность справа представляет собой целевую полезную нагрузку, подлежащую декодированию.

Определение способа декодирования по параметрам заголовка

На втором этапе анализируется отсеченный на предыдущем шаге заголовок, расположенный между префиксом data:image/svg+xml и разделительной запятой. Логика выбора метода обратной конвертации полностью зависит от наличия или отсутствия в этой части маркера ;base64 .

Если в блоке метаданных присутствует флаг ;base64 , полезная нагрузка идентифицируется как массив данных, перекодированный побитовым алгоритмом Base64. При отсутствии этого маркера - например, когда заголовок завершается параметрами ;utf8 , ;charset=utf-8 или сразу переходит в запятую после указания медиатипа - строка распознается как текст с процентным кодированием.

Выполнение декодирования и восстановление XML-разметки

Финальный этап заключается в применении выбранного математического или символьного алгоритма к выделенной полезной нагрузке для получения исходного кода векторной графики.

При обработке данных с маркером ;base64 выполняется обратное преобразование из 64-символьного алфавита в исходный поток байтов, который затем интерпретируется как текст в кодировке UTF-8. Каждая группа из четырех печатных символов Base64 (по 6 бит) переводится обратно в три восьмибитных байта исходного текста. Выравнивающие знаки = в конце строки отбрасываются. В результате этой операции сплошной буквенно-цифровой блок восстанавливается в читаемые открывающие и закрывающие теги.

Если на втором шаге была определена схема percent-encoding, применяется процедура URL-декодирования. Обработчик проходит по всей длине строки, находит шестнадцатеричные последовательности вида %XX и заменяет их на соответствующие штатные символы XML-разметки согласно таблице кодов UTF-8. Часть строки, изначально записанная безопасными латинскими буквами и цифрами, остается без изменений.

В таблице ниже показаны типовые замены экранированных последовательностей при выполнении URL-декодирования векторной разметки:

Вне зависимости от того, какой из двух методов применялся на третьем шаге, итогом операции становится полностью восстановленный текстовый поток. На выходе формируется чистый исходный код в формате SVG с корневым элементом <svg> , готовый к чтению, редактированию или сохранению в отдельный файл.

Синтаксис и структура извлеченного SVG-кода

После завершения декодирования выходной результат представляет собой структурированный текстовый документ, построенный по правилам XML. В отличие от растровых изображений, которые хранят сетку пикселей, SVG описывает графику через математические координаты, геометрические формулы и строгую иерархию тегов. Поскольку XML чувствителен к синтаксису, в восстановленной разметке все открывающие теги имеют парные закрывающие элементы либо оформлены как самозакрывающиеся конструкции (self-closing tags) со слэшем перед закрывающей угловой скобкой, а значения всех атрибутов строго заключены в кавычки.

Корневой элемент и параметры координатной сетки

Любой валидный векторный документ начинается с открывающего корневого тега <svg> и заканчивается закрывающим </svg> . Этот контейнер объединяет все внутренние фигуры и задает глобальные правила отображения графики через набор базовых атрибутов:

• xmlns="http://www.w3.org/2000/svg" - декларация пространства имен XML. Этот атрибут указывает программе просмотра или браузеру, что содержащиеся внутри теги нужно интерпретировать именно как векторную графику, а не как произвольный набор данных. При извлечении кода из Data URI присутствие этого атрибута обязательно, иначе изображение не отобразится при открытии в виде отдельного файла.
• viewBox - ключевой параметр внутренней системы координат, состоящий из четырех чисел ( min-x , min-y , width , height ), разделенных пробелами или запятыми. Он определяет начальную точку отсчета и условные размеры рабочего полотна, за счет чего векторные элементы масштабируются под любой экран без потери пропорций.
• width и height - задают физические или относительные размеры области отображения (viewport), в которую будет вписана внутренняя координатная сетка. Значения могут указываться в пикселях, процентах или условных единицах.
• preserveAspectRatio - управляет выравниванием и масштабированием графики в тех случаях, когда пропорции внешнего контейнера (заданные через width и height ) не совпадают с пропорциями внутреннего холста viewBox .

Внутренние элементы и геометрические примитивы

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

Для построения геометрических объектов и объединения их в логические блоки в коде используются стандартные дескрипторы:

Помимо одиночных фигур и групп, в извлеченном коде часто встречается сервисный блок <defs> . Элементы, помещенные внутрь этого контейнера, не рисуются на холсте напрямую - они служат заготовками (шаблонами масок, градиентов или повторяющихся фрагментов), которые вызываются в других частях документа по их идентификатору.

Атрибуты стилизации, трансформации и управления геометрией

Внешний вид каждого контура или примитива определяется презентационными атрибутами. Они могут быть прописаны непосредственно в теге конкретной фигуры, вынесены в родительскую группу <g> или заданы на уровне корневого элемента <svg> .

К основным параметрам управления цветом и линиями относятся атрибуты заливки и обводки. Свойство fill отвечает за внутреннее окрашивание замкнутого или незамкнутого контура: в качестве значения может выступать цветовая схема, ссылка на градиент или ключевое слово none (прозрачная внутренняя область). Если сложный контур имеет самопересечения или внутренние отверстия, дополнительно применяется атрибут fill-rule (со значениями nonzero или evenodd ), который математически определяет, какие участки считать внутренними и закрашивать, а какие оставлять пустыми. Параметр stroke задает цвет линии контура, а stroke-width регулирует ее толщину в единицах текущей координатной сетки. За общую степень прозрачности элемента или целой группы отвечает атрибут opacity , принимающий дробные значения от 0 (полная невидимость) до 1 (полная непрозрачность).

Вместо сплошного цвета поверхности могут окрашиваться плавными цветовыми переходами. Линейные и радиальные градиенты объявляются отдельными вложенными структурами с опорными точками цвета ( <stop> ) и получают собственный id , после чего подключаются к нужной фигуре через конструкцию вида fill="url(#id)" . Аналогичным образом к объектам привязываются обтравочные маски clipPath , где правило расчета границ отсечения при сложных контурах регулируется параметром clip-rule .

Для изменения положения, размера или наклона элементов без пересчета базовых координат контура используется атрибут transform . Он поддерживает передачу математических функций пространственного преобразования: смещение по осям, масштабирование, наклон и поворот rotate на заданный угол относительно центра координат или указанной точки. Наличие таких атрибутов в декодированном коде позволяет точно воспроизвести геометрию исходного изображения без искажений.

Источники строк Data URI и сценарии применения исходного SVG

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

Где в веб-проектах встречаются закодированные векторные изображения

Основной массив инлайновых векторных данных сосредоточен во фронтенд-коде, таблицах стилей и скомпилированных бандлах веб-приложений. При анализе чужого или старого проекта без доступа к исходным дизайн-макетам строку Data URI обычно копируют через панель инструментов разработчика DevTools в браузерах Chrome, Firefox, Safari или Edge при инспекции конкретного узла страницы или сетевых ресурсов.

В зависимости от способа верстки и назначения графического элемента закодированная строка располагается в следующих конструкциях кода:

• Таблицы стилей CSS. Векторные иконки, маркеры списков, декоративные стрелки и сложные фоновые паттерны часто записываются внутри функции url() в свойствах background , background-image и border-image . Если векторная фигура служит трафаретом для наложения цвета или градиента через стилевые правила, строка размещается в свойствах mask или mask-image .
• Статическая и динамическая разметка HTML. Изображения встраиваются напрямую в атрибуты src и srcset тега <img> или передаются через атрибут data контейнера <object> . Также в виде компактной строки Data URI нередко задается иконка сайта favicon внутри тега <link rel="icon"> в заголовке документа.
• Скомпилированные бандлы сборки. Сборщики модулей при компиляции проекта могут переводить мелкие векторные файлы в инлайновые строки и записывать их внутрь минифицированных файлов стилей или скриптов для сокращения числа сетевых обращений.

Зачем переводить Data URI обратно в чистый код SVG

Пока графика находится внутри строки Data URI в свойстве фона или теге изображения, браузер воспринимает ее как замкнутый внешний ресурс. В таком состоянии невозможно обратиться к отдельным контурам или группам фигур через DOM, чтобы программно изменить их цвет при наведении курсора, запустить построчную анимацию обводки или скрыть часть композиции. Перевод строки в исходную разметку снимает эти ограничения и возвращает полный контроль над структурой векторного документа.

В таблице ниже сопоставлены типичные рабочие задачи, источники закодированных данных и дальнейшие действия с полученным после декодирования кодом:

При переносе декодированной графики в компонентную среду вроде React с использованием синтаксиса JSX или типизации TypeScript, а также при работе с single-file components, чистый векторный код позволяет передавать цвет заливки, толщину линий или размеры иконки через входные свойства компонента. Если же проект использует систему иконок на базе единого набора символов, извлеченные из стилей разрозненные строки декодируют, оборачивают в соответствующие теги и собирают в общий SVG sprite. Для тонкой доработки самой формы - например, удаления лишних опорных точек, скругления углов или выравнивания пропорций - извлеченный код сохраняют в файл с расширением .svg либо копируют напрямую в рабочую область Figma, Adobe Illustrator или InkScape.

Примеры преобразования Data URI в чистый код SVG

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

Декодирование строки с процентным экранированием

При использовании текстового представления с параметром utf8 структура тегов остается отчасти узнаваемой, но прямое копирование такой строки в файл .svg или HTML-документ вызовет синтаксическую ошибку из-за замененных спецсимволов. В следующем примере показана входная строка Data URI, содержащая простую геометрическую иконку с заливкой в формате HEX:

data:image/svg+xml;utf8,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%2024%2024%22%20width%3D%2224%22%20height%3D%2224%22%3E%3Cpath%20fill%3D%22%233b82f6%22%20d%3D%22M12%202L2%2022h20L12%202z%22%2F%3E%3C%2Fsvg%3E

В процессе обратного преобразования удаляется заголовок data:image/svg+xml;utf8, , а все экранированные последовательности переводятся в стандартные символы разметки: %3Csvg возвращает открывающий тег <svg , коды %20 заменяются на пробелы, а комбинация %23 внутри атрибута fill восстанавливает символ решетки для цветовой модели HEX. Итоговый результат представляет собой валидный XML-код:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24">
  <path fill="#3b82f6" d="M12 2L2 22h20L12 2z"/>
</svg>

Извлечение векторной разметки из кодировки Base64

Второй сценарий - работа со строкой, где векторная графика переведена в кодировку Base64. В таком виде визуально определить содержимое, размеры координатной сетки или цвет элементов до момента декодирования невозможно, хотя начало полезной нагрузки с последовательности PHN2Zy всегда указывает на закодированный открывающий тег <svg . Пример исходной строки:

data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCAxNiAxNiI+PHBhdGggZmlsbD0iIzEwYjkgOCIuIGQ9Ik04IDBMMCA4bDggOCAxLjUtMS41TDQuNSA5SDE2VjdoLTExLjVsNS01LjVMODAwWiIvPjwvc3ZnPg==

На практике в конце такой строки часто встречаются один или два символа = , которые служат для выравнивания длины блока при кодировании и исчезают после обработки. После отсечения префикса data:image/svg+xml;base64, и перевода символьного потока в текстовый формат восстанавливается читаемая векторная разметка с атрибутом viewBox и элементом <path> :

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16">
  <path fill="#10b981" d="M8 0L0 8l8 8 1.5-1.5L4.5 9H16V7h-11.5l5-5.5L8 0Z"/>
</svg>

Сопоставление фрагментов до и после конвертации

При ручной проверке исходных строк или анализе полученного кода удобно ориентироваться на характерные маркеры, которые показывают, в какие именно конструкции SVG превращаются участки закодированных данных. В таблице ниже приведены типичные фрагменты для обоих вариантов кодирования:

Вне зависимости от того, какой из двух вариантов использовался в исходных стилях или разметке страницы, на выходе получается идентичный по своей структуре код SVG. Его можно сразу вставлять в DOM-дерево документа, переносить в шаблоны компонентов или сохранять как самостоятельный графический файл.