RFC: 2397
Оригинал: The 'data' URL scheme
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: RFC2.ru

1. Тезисы

URL-схема "data" позволяет включать небольшие элементы данных в строку URL так, как если бы они являлись ссылкой на внешний ресурс.

2. Описание

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

URL имеет следующий вид:

data:[<mediatype>][;base64],<data>

<mediatype> — спецификация типа носителей данных (с дополнительными параметрами). Появление ";base64" означает, что данные закодированы в base64. Без ";base64", данные (как последовательность байтов) представляются с использованием кодировки ASCII в диапазоне безопасных символов URL и используя стандартное %xx hex-кодирование для символов вне этого диапазона. Если <mediatype> опущен, значение по умолчанию — text/plain; charset=US-ASCII. Для краткости, можно опустить "text/plain", оставив параметр charset.

URL-схема "data:" полезна только для коротких значений.

Заметим, что некоторые приложения, использующие URL, могут наложить ограничение на длину, например URL, внедренное в HTML тег <A>, имеет ограничение, определенное в соответствии с декларациями SGML для HTML [RFC1866]. LITLEN (1024) ограничивает количество символов одного атрибута, ATTSPLEN (2100) определяет сумму длин всех атрибутов, а TAGLEN (2100) ограничивает общую длину тега.

URL-Схема "data" не поддерживает относительные формы URL.

3. Синтаксис

dataurl    := "data:" [ mediatype ] [ ";base64" ] "," data
mediatype  := [ type "/" subtype ] *( ";" parameter )
data       := *urlchar
parameter  := attribute "=" value

"urlchar" импортирован из спецификации URI [RFC2396], а "type", "subtype", "attribute" и "value" соответствуют лексемам из стандарта MIME [RFC2045], по необходимости обработанные URL escaped кодировкой.

Из спецификации MIME следует, что значения атрибутов могут быть представлены как в виде лексем, так и виде строк, обрамлены кавычками. Тем не менее, в Data:URL, представлять "quoted-string" было бы неуклюжим, поскольку символы кавычек сами по себе не являются валидными urlchar. Поэтому, если значение атрибутов содержат какие-либо "tspecial", необходимо использовать именно URL Escaped кодирование, а не quoted-string.

Расширение ";base64" отличается от параметра content-type тем, что не имеет последующего знака "=".

4. Примеры

Data URL может быть использовано для любых типов данных. URL-адрес:

data:,A%20brief%20note

кодирует строку text/plain "A brief note", которая могла бы быть полезна в создании удобных сносок.

Фрагмент HTML-кода:

<IMG
SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw
AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz
ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp
a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl
ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis
F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH
hhx4dbgYKAAA7"
ALT="Larry">

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

Спецификация медиа типов Data: URL позволяет включать и другие параметры, например, можно определить кодировку документа параметром charset:

data:text/plain;charset=iso-8859-7,%be%fg%be

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

Некоторые приложения могут использовать URL-схему "data" для настройки параметров других видов сетевых приложений. Например, можно создать media-type:

application/vnd-xxx-query

содержание которого, состоит из строки запроса и идентификатора базы данных для поставщика "xxx". URL-адрес вида:

data:application/vnd-xxx-
query,select_vcount,fcol_from_fieldtable/local

мог бы тогда использоваться в локальном приложении для запуска "помощника" для application/vnd-xxx-query и его данных.

5. История

Первоначально идея была предложена в августе 1995. Некоторые версии Data: URL были использованы в определении VRML, а затем поступило предложение о внедрении данных в HTML. Множество различных изменений было сделано на основе запросов, игнорировать медиа типы, более плотно кодировать данные base64, ликвидировать "quoted printable" в качестве кодировки, поскольку не получится сформировать правильный URL без дополнительного %xx кодирования, которое само по себе недостаточно. Сегодня URL-схема "data" используется в VRML, новых HTML-приложениях, и различных коммерческих продуктах. Она так же используется для параметров объекта в Java и ActiveX.

6. Безопасность

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

Сайтам, которые используют фильтрующие прокси для запрета определенных типов информации (таких, как языки сценариев или другие типы с известными проблемами безопасности) будет трудно отразить внедрение через URL-схему "data". Тем не менее, они должны знать об угрозе, и принять все меры предосторожности, которые считаются необходимыми в их области.

Эффект от использование длинных data URLs в настоящее время неизвестен. Некоторые программы могут продемонстрировать неблагоразумное поведение, когда сталкиваются с данными, превышающими выделенный размер буфера.

7. Ссылки

[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifiers (URI): Generic Syntax», RFC 2396, Август 1998.
[RFC1866] Berners-Lee, T., and D. Connolly, «Hypertext Markup Language — 2.0.», RFC 1866, Ноябрь 1995.
[RFC2045] Freed N., and N. Borenstein., «Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies», RFC 2045, Ноябрь 1996.

Адрес автора:

Larry Masinter
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304
EMail: moc.xorex.crap@retnisam

2007 - 2022 © Русские переводы RFC, IETF, ISOC.