Что такое base64 и зачем он нужен в веб разработке?
Зачем это нужно?
Так исторически сложилось, что многие форматы передачи и хранения данных используют текст вместо бинарных кодов (html, url схемы, xml, email… и тп). Но что, если формат передачи данных текстовый, а передать необходимо бинарные данные (отдельно либо вместе с текстовыми данными). Вот тут на помощь и приходит base64.
Типовое применение в веб разработке
data: URL и base64 data: URL — это определённая стандартом RFC 2397 схема, которая позволяет включать небольшие элементы данных в строку URL, как если бы они были ссылкой на внешний ресурс. Согласно RFC «data: URI» – это фактически «data: URL» (URL — унифицированный указатель ресурса), хотя реально он ни на что не указывает.
Формат data: URL следующий:
Несколько типовых применений на примерах.
Пример использования в HTML:
(Переносы на новую строку осуществлены для облегчения восприятия. Их не должно быть) Все, что следует за data:image/png;base64, – это base64 код небольшого png изображения (красная точка 10×10 px). Этот пример будет выглядеть так –
Пример использования в CSS:
Получение бинарных данных из canvas в виде текстового base64 представления
12 comments on “ Что такое base64 и зачем он нужен в веб разработке? ”
Так а чем лучше такой подход для изображений? Не раскрыта тема, зачем надо такое использовать.
Хорошее замечание 😉 попробуем разобраться.
Такой подход лучше только в тех случаях, когда в зависимости от задачи Вам удобно:
Включение картинки непосредственно в CSS в виде base64, позволит браузеру отобразить ее при первой отрисовке страницы, не делая дополнительных запросов к серверу. Это особенно заметно в медленных мобильных браузерах и при медленном соединении.
Так же можно поступить с подгружаемыми шрифтами. Включая их в CSS в виде base64, вы гарантируете, что кастомный шрифт уже будет правильно отображен во время первой отрисовки страницы, а не спустя некоторое время (которое обычно браузер тратит на подгрузку внешнего шрифта)
Я не советую использовать этот подход везде, но в зависимости от задачи и требований к приложению, иногда такой подход может быть лучше. В целом.. Если пункты a) и b) не критичны для Ваших проектов, то включать изображения в css/html в виде base64 не стоит 🙂
Другие области применения в веб
Отличная статья, спасибо. Особенно актуально для email-писем.
Можно заметить что при малых размерах изображений css, применяя gzip сжатие для файла стилей(и отдачу сжатого файла с сервера) получаем не только устранение запросов но и сокращение объёма(20%-25%).
Base64
Base64 буквально означает — позиционная система счисления с основанием 64. Здесь 64 — это наибольшая степень двойки (2 6 ), которая может быть представлена с использованием печатных символов ASCII. Эта система широко используется в электронной почте для представления бинарных файлов в тексте письма (транспортное кодирование). Все широко известные варианты, известные под названием Base64, используют символы A-Z, a-z и 0-9, что составляет 62 знака, для недостающих двух знаков в разных системах используются различные символы.
Содержание
Схема соответствия «символ ↔ значение» в Base64
| Символ | Значение | Символ | Значение | Символ | Значение | Символ | Значение | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 10 | 8 | 16 | 10 | 8 | 16 | 10 | 8 | 16 | 10 | 8 | 16 | ||||
| A | 0 | 00 | 00 | Q | 16 | 20 | 10 | g | 32 | 40 | 20 | w | 48 | 60 | 30 |
| B | 1 | 01 | 01 | R | 17 | 21 | 11 | h | 33 | 41 | 21 | x | 49 | 61 | 31 |
| C | 2 | 02 | 02 | S | 18 | 22 | 12 | i | 34 | 42 | 22 | y | 50 | 62 | 32 |
| D | 3 | 03 | 03 | T | 19 | 23 | 13 | j | 35 | 43 | 23 | z | 51 | 63 | 33 |
| E | 4 | 04 | 04 | U | 20 | 24 | 14 | k | 36 | 44 | 24 | 0 | 52 | 64 | 34 |
| F | 5 | 05 | 05 | V | 21 | 25 | 15 | l | 37 | 45 | 25 | 1 | 53 | 65 | 35 |
| G | 6 | 06 | 06 | W | 22 | 26 | 16 | m | 38 | 46 | 26 | 2 | 54 | 66 | 36 |
| H | 7 | 07 | 07 | X | 23 | 27 | 17 | n | 39 | 47 | 27 | 3 | 55 | 67 | 37 |
| I | 8 | 10 | 08 | Y | 24 | 30 | 18 | o | 40 | 50 | 28 | 4 | 56 | 70 | 38 |
| J | 9 | 11 | 09 | Z | 25 | 31 | 19 | p | 41 | 51 | 29 | 5 | 57 | 71 | 39 |
| K | 10 | 12 | 0A | a | 26 | 32 | 1A | q | 42 | 52 | 2A | 6 | 58 | 72 | 3A |
| L | 11 | 13 | 0B | b | 27 | 33 | 1B | r | 43 | 53 | 2B | 7 | 59 | 73 | 3B |
| M | 12 | 14 | 0C | c | 28 | 34 | 1C | s | 44 | 54 | 2C | 8 | 60 | 74 | 3C |
| N | 13 | 15 | 0D | d | 29 | 35 | 1D | t | 45 | 55 | 2D | 9 | 61 | 75 | 3D |
| O | 14 | 16 | 0E | e | 30 | 36 | 1E | u | 46 | 56 | 2E | + | 62 | 76 | 3E |
| P | 15 | 17 | 0F | f | 31 | 37 | 1F | v | 47 | 57 | 2F | / | 63 | 77 | 3F |
В формате электронной почты MIME base64 — это схема, по которой произвольная последовательность байт преобразуется в последовательность печатных ASCII символов. Это определяет MIME как транспортное кодирование содержимого для использования в электронной почте. Используются только символы латинского алфавита в верхнем и нижнем регистре — символы (A—Z, a—z), цифры (0—9), и символы «+» и «/», с символом «=» в качестве специального кода суффикса.
Полная спецификация этой формы base64 содержится в RFC 1421 и RFC 2045. Эта схема используется для кодирования последовательности октетов (байт). Это соответствует определению файлов почти во всех системах. Результирующие закодированные по base64 данные имеют длину, большую оригинальной в соотношении 4:3, и напоминают по виду случайные символы.
Для того, чтобы преобразовать данные в base64, первый байт помещается в самые старшие восемь бит 24-битного буфера, следующий в средние восемь и третий в младшие значащие восемь бит. Если кодируется менее чем три байта, то соответствующие биты буфера устанавливаются в ноль. Далее каждые шесть бит буфера, начиная с самых старших, используются как индексы строки «ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/» и её символы, на которые указывают индексы, помещаются в выходную строку. Если кодируются только один или два байта, в результате получаются только первые два или три символа строки, а выходная строка дополняется двумя или одним символами «=». Это предотвращает добавление дополнительных битов к восстановленным данным. Процесс повторяется над оставшимися входными данными.
Например, исторический слоган Википедии,
Man is distinguished, not only by his reason, but by this singular passion from other animals, which is a lust of the mind, that by a perseverance of delight in the continued and indefatigable generation of knowledge, exceeds the short vehemence of any carnal pleasure.
будучи закодированным в base64 выглядит следующим образом:
UTF-7 представляет собой систему, называемую Изменённый Base64. Эта схема кодирования данных используется для того, чтобы кодировать UTF-16 как промежуточный формат в UTF-7 в печатных ASCII символах. Этот вариант base64 используется в MIME. UTF-7 предназначен для того, чтобы позволять использовать unicode в e-mail без использования разделения транспортного кодирования содержимого. Главное отличие этого варианта base64 от MIME в том, что символ «=» не используется для дополнения, так как требуется многократное экранирование этого символа. Вместо этого биты октета дополняются нулями.
Изменённый Base64 стандартизирован по RFC 2152, A Mail-Safe Transformation Format of Unicode.
В сервер-сервер протоколе, используемом в IRCu IRC демоном и совместимом программном обеспечении, версия base64 используется для кодирования клиент/серверных числовых и двоичных IP адресов. Клиентские и серверные числовые данные имеют фиксированные размеры, которые точно совпадают с количеством знаков base64, тем самым, нет необходимости в дополнении. Двоичные IP-адреса для соответствия расширяются ведущими нулевыми битами. Набор символов незначительно отличается от MIME использованием [] вместо +/.
Применение в веб-приложениях
Кодирование Base64 может быть полезно, если в окружении HTTP используется информация, длину которой можно точно определить. Hibernate, библиотека, реализующая базу данных-хранилище для Java-объектов, использует Base64 для того, чтобы закодировать относительно большой идентификатор (как правило, 128-битный UUID) в строку, чтобы использовать его как параметр в HTTP-формах или в запросах HTTP GET URL. Также многим приложениям необходимо кодировать двоичные данные, для удобства включения в URL, скрытые поля форм, и здесь Base64 удобно не только для компактного представления, но и относительной нечитаемостью для попытки выяснения случайным человеком-наблюдателем природы данных.
Использование URL-кодировщика над стандартом Base64, несмотря на это, неудобно, так как он преобразует символы ‘/’ и ‘+’ в специальные шестнадцатеричные последовательности. Если позднее эта строка используется вместе с базой данных или через гетерогенные системы, они прекращают работу на символе ‘%’, сгенерированном URL-кодировщиком (потому что символ ‘%’ также используется в ANSI SQL как шаблон).
По причине этого, существует изменённый Base64 для URL,где не используется заполнение символом ‘=’ и символы ‘+’ и ‘/’ соответственно заменяются на ‘*’ и ‘-‘, так, чтобы использование кодеров/декодеров URL перестаёт быть необходимым и не имеет никакого воздействия на длину закодированного значения, оставляя ту же самую закодированную форму, неповреждённую для использования в реляционных базах данных, веб-формах, и идентификаторах объекта вообще. Стандартом Base64-кодирования URL адресов, признается вариант, когда символы ‘+’ и ‘/’ заменяются, соответственно, на ‘-‘ и ‘_’ (RFC3548, раздел 4).
Другой вариант называется изменённый Base64 для регулярных выражений использует ‘!-‘ вместо ‘*-‘ для того, чтобы заменить стандартный Base64 ‘+/’, потому что оба ‘+’ и ‘*’ могут быть зарезервированы для регулярных выражений (отметим, что ‘[]’ используемый выше в IRCu варианте может не работать в этом контексте).
Имеются другие варианты, которые используют ‘_-‘ или ‘._’, если строка Base64 должна быть использована вместе с идентификаторами для программ, или ‘.-‘ для использования в токенах имён XML (Nmtoken), или ‘_:’ в более ограниченных идентификаторах XML (Name).
Radix-64
Radix-64 — разновидность кодирования Base64 двоичных данных в текстовый формат, используемая в PGP. От Base64 отличается тем, что в конец добавляется контрольная сумма в 24 бита.
Другие применения
Существует множество вариантов применения Base64. Например, Thunderbird и Mozilla использовали Base64 для сокрытия паролей в POP3. Base64 часто используется как рациональный метод в безопасности для скрытия секретов без издержек на криптографическое управление ключами.
Сканеры спама, которые не декодируют сообщения в base64, часто пропускают сообщения в Base64, так как они кажутся достаточно случайными, или не содержат ключевые слова в тексте Base64, чтобы быть принятыми за спам. Это используют спамеры для обхода основных антиспамовых инструментов.
SGVsbG8gd29ybGQh или история base64
Краткая предыстория
Вообще, все началось давно. Настолько давно, что вряд ли остались свидетели holy wars тех дней, когда решалось — сколько же бит должно быть в байте.
Это сейчас нам кажется само собой разумеющимся, что 1 байт = 8 бит, что в байте можно закодировать 256 различных значений. Но когда-то было совсем не так. История помнит и семибитные кодировки, и шестибитные, и даже более экзотические системы (например — ЭВМ «Сетунь», которая использовала троичную логику, то есть один троичный бит — трит мог иметь три, а не два значения, для нее было справедливо соотношение 1 трайт = 6 тритам). Но если оставить в стороне всякую экзотику, то мэйнстримом все-таки были кодировки, в которых 6, 7 или 8 бит в байте.
Шестибитная кодировка (например — BCD) позволяла закодировать в одном байте 64 различных значения, что, как казалось, было вполне достаточно для кодирования алфавитно-цифровых символов, а «лишний» седьмой бит расширял кодировку уже до 128 символов.
Однако скоро восьмибитный байт стал общепринятым.
Проблема восьмого бита
Утверждение восьмибитных кодировок как стандарта де-факто принесло много проблем. К этому моменту уже существовала определенная инфраструктура, использующая именно семибитные кодировки, и holy wars разгорелись с новой силой.
До нас они дошли в виде проблем с «обрезанием восьмого бита» в системе электронной почты. Утверждение восьмибитного байта дало 256 различных значений для одного байта, что, в свою очередь позволило уместить в одной кодовой таблице и общепринятые символы (цифры, знаки препинания, латиницу) и символы, скажем кириллицы. Казалось бы — сплошное удобство, текст можно набирать хоть русскими буквами, хоть английскими, а если нужно — и для немецких умлаутов место найдется!
Но, как всегда, дьявол крылся в деталях. Уже накопленный и работающий хард-н-софт зачастую был приспособлен для кодировок семибитных, что приводило к разнообразным проблемам.
Например, почтовый сервер при передаче письма мог совершенно спокойно обнулить старшие биты в каждом байте сообщения, что не могло не привести к проблемам, зачастую информация просто катастрофически терялась.
Для временного решения этой проблемы было предложено несколько вариантов. Одним из них стала кодировка «КОИ-8». Решение, нужно признать, весьма элегантное — в этой кодировке русские буквы располагались по порядку латинских и отличались от них ровно на тот самый старший бит. Таким образом при обрезании этого бита русская «А» превращалась в латинскую «A», «Б» — в «B» и так далее, сообщение просто транслитерировалось и его все-таки можно было прочитать. Правда, и тут не обошлось без скелета в шкафу — сортировка в русском алфавитном порядке в «КОИ» становилась кошмаром…
А что было делать другим языкам, народам и кодировкам? А бинарные данные? Все равно кодировки с транслитерацией не решали фундаментальную проблему — потерю восьмого бита, потерю части информации. Так родилась кодировка (а точнее — алгоритм) Base64.
Алгоритм Base64
Идея base64 проста — обратимое кодирование, с возможностью восстановления, которое переводит все символы восьмибитной кодовой таблицы в символы, гарантированно сохраняющиеся при передаче данных в любых сетях и между любыми устройствами.
В основе алгоритма лежит сведение трех восьмерок битов (24) к четырем шестеркам (тоже 24) и представление этих шестерок в виде символов ASCII. Таким образом получается обратимое шифрование, единственным недостатком которого будет увеличивающийся при кодировании размер — в соотношении 4:3.
Пример:
Возьмем текст русский текст «АБВГД». В двоичной форме в кодировке Windows-1251 мы получим 5 байтов:
11000000
11000001
11000010
11000011
11000100
(00000000) — лишний нулевой байт нужен, чтобы общее число бит делилось на 6
Разделим эти биты на группы по 6:
110000
001100
000111
000010
110000
111100
010000
000000
Берем массив символов «ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/» и получившиеся числа переводим в эти символы, используя их, как индексы массива, получаем «wMHCw8Q». Остается только добавить в конце один символ «=», как указание на один лишний нулевой байт, который мы добавляли на первом шаге и получить окончательный результат:
«АБВГД»: base64 = «wMHCw8Q=»
Обратное преобразование не менее легко, попробуйте, например, расшифровать то, что вынесено в заголовок этой статьи.
Применение
Алгоритм base64 и по сей день применяется там, где нет возможности гарантировать бережного обращения с вашей информацией — например при кодировании вложений электронной почты. В PGP алгоритм base64 используется для кодирования бинарных данных.
Можно представить себе и другие применения base64 — например при сохранении в базу данных, если заранее неизвестно окружение (ох уж эти magic_qoutes в PHP!) и нет необходимости в индексации и поиске по тексту, можно воспользоваться base64.
base64 вполне может использоваться для получения хэшей, например по алгоритму md5, как средство против табличного подбора хэша, если данные, например пароль пользователя в системе, предварительно будут преобразованы в base64.
Для чего используется кодировка base 64?
Я слышал, как люди говорили о «кодировании base 64» здесь и там. Для чего его используют?
Чтобы обойти это, люди кодируют двоичные данные в символы. Base64 является одним из этих типов кодировок.
Почему 64?
Потому что вы, как правило, можете рассчитывать на то, что одни и те же 64 символа присутствуют во многих наборах символов, и вы можете быть достаточно уверены в том, что ваши данные окажутся на другой стороне провода не поврежденными.
Это в основном способ кодирования произвольных двоичных данных в тексте ASCII. Требуется 4 символа на 3 байта данных, плюс, возможно, небольшой отступ в конце.
По сути, каждые 6 бит ввода кодируются в 64-символьном алфавите. «Стандартный» алфавит использует AZ, az, 0-9 и + и /, с = в качестве символа заполнения. Есть URL-безопасные варианты.
Это текстовая кодировка двоичных данных, в которой результирующий текст содержит только буквы, цифры и символы «+», «/» и «=». Это удобный способ хранения / передачи двоичных данных через носитель, который специально используется для текстовых данных.
Но почему Base-64? Две альтернативы для преобразования двоичных данных в текст, которые сразу приходят на ум:
Помимо того, что уже было сказано, два очень распространенных использования, которые не были перечислены
Криптография:
Поскольку ключ шифрования должен быть не текстовым, а необработанным байтом, иногда необходимо сохранить его в файле или базе данных, для чего пригодится Base64. То же самое с результирующими зашифрованными байтами.
Обратите внимание, что хотя Base64 часто используется в криптографии, это не механизм безопасности. Любой может преобразовать строку Base64 обратно в ее исходные байты, поэтому ее не следует использовать в качестве средства защиты данных, а только в качестве формата для более простого отображения или хранения необработанных байтов.
Сертификаты
Сертификаты x509 в формате PEM кодируются в формате base64. http://how2ssl.com/articles/working_with_pem_files/
Несколько лет назад, когда была введена функциональность почтовой рассылки, так что с течением времени она была полностью основана на тексте, и возникла потребность в таких приложениях, как изображения и мультимедиа (аудио, видео и т. Д.). Когда эти вложения отправляются через Интернет (в основном в виде двоичных данных), вероятность повреждения двоичных данных в исходном виде высока. Итак, для решения этой проблемы пришел BASE64.
Проблема с двоичными данными состоит в том, что они содержат нулевые символы, которые в некоторых языках, таких как C, C ++, представляют конец символьной строки, поэтому отправка двоичных данных в необработанном виде, содержащем NULL-байты, не дает файлу полностью считываться и приводит к поврежденным данным.
В C и C ++ этот «нулевой» символ показывает конец строки. Так что «Привет» хранится так:
00 говорит «остановись здесь».
Теперь давайте рассмотрим, как работает кодирование BASE64.
Обратите внимание: длина строки должна быть кратна 3.
Пример 1:
Строка для кодирования: «туз», длина = 3
1) Конвертировать каждый символ в десятичную.
а = 97, с = 99, е = 101
2) Измените каждое десятичное на 8-битное двоичное представление.
97 = 01100001, 99 = 01100011, 101 = 01100101
Комбинированный: 01100001 01100011 01100101
3) Отдельно в группе 6 бит.
011000 010110 001101 100101
4) Рассчитать двоичное в десятичное
011000 = 24, 010110 = 22, 001101 = 13, 100101 = 37
5) Преобразование десятичных символов в base64 с использованием диаграммы base64.
24 = Y, 22 = W, 13 = N, 37 = l
Пример 2:
Строка для кодирования: «abcd» Length = 4, она не кратна 3. Поэтому, чтобы сделать длину строки кратной 3, мы должны добавить 2-битовое заполнение, чтобы сделать length = 6. Бит заполнения представлен знаком «=».
Следует отметить: один бит дополнения равен двум нулям 00, поэтому два бита дополнения равны четырем нулям 0000.
1) Конвертировать каждый символ в десятичную.
а = 97, б = 98, с = 99, д = 100
2) Измените каждое десятичное на 8-битное двоичное представление.
97 = 01100001, 98 = 01100010, 99 = 01100011, 100 = 01100100
3) Отдельно в группе 6 бит.
011000, 010110, 001001, 100011, 011001, 00
поэтому последний 6-бит не является полным, поэтому мы вставляем два дополнительных бита, равных четырем нулям «0000».
011000, 010110, 001001, 100011, 011001, 000000 ==
Теперь оно равное. Два знака равенства в конце показывают, что были добавлены 4 нуля (помогает при декодировании).
4) Рассчитать двоичные числа в десятичные.
011000 = 24, 010110 = 22, 001001 = 9, 100011 = 35, 011001 = 25, 000000 = 0 ==
5) Преобразование десятичных символов в base64 с использованием диаграммы base64.
24 = Y, 22 = W, 9 = j, 35 = j, 25 = Z, 0 = A ==
В первые дни компьютеров, когда межсистемная связь по телефонной линии не была особенно надежной, использовался быстрый и грязный метод проверки целостности данных: «битовая четность». В этом методе каждый передаваемый байт будет иметь 7-битные данные, а 8-й будет 1 или 0, чтобы общее число 1-бит в байте было четным.
Следовательно, 0x01 будет передано как 0x81; 0x02 будет 0x82; 0x03 останется 0x03 и т. Д.
Для дальнейшего развития этой системы, когда был определен набор символов ASCII, только 00-7F были назначены символы. (До сих пор все символы в диапазоне 80-FF нестандартны)
Многие современные маршрутизаторы устанавливают проверку четности и перевод байтов в аппаратные средства, заставляя подключенные к ним компьютеры строго обрабатывать 7-битные данные. Это заставляет вложения электронной почты (и все другие данные, поэтому протоколы HTTP и SMTP основаны на тексте) для преобразования в текстовый формат.
Немногие из роутеров выжили в 90-х годах. Я сильно сомневаюсь, что любой из них используется сегодня.
Термин Base64 относится к конкретной кодировке передачи контента MIME. Он также используется в качестве общего термина для любой подобной схемы кодирования, которая кодирует двоичные данные, обрабатывая их численно и переводя в представление base 64. Конкретный выбор базы обусловлен историей кодировки набора символов: можно выбрать набор из 64 символов, который является частью подмножества, общего для большинства кодировок, а также для печати. Эта комбинация оставляет данные, которые вряд ли будут изменены при передаче через системы, такие как электронная почта, которые традиционно не были 8-битными чистыми.
Base64 может использоваться во множестве контекстов:
Base64 часто используется в качестве быстрого, но небезопасного ярлыка для скрытия секретов без дополнительных затрат на управление криптографическим ключом.
Спамеры используют Base64, чтобы обойти базовые средства защиты от спама, которые часто не декодируют Base64 и поэтому не могут обнаружить ключевые слова в закодированных сообщениях.
Использование Base64, которое я собираюсь описать здесь, является своего рода хаком. Так что, если вам не нравятся хаки, пожалуйста, не продолжайте.
У меня возникли проблемы, когда я обнаружил, что MySQL utf8 не поддерживает 4-байтовые символы Unicode, поскольку он использует 3-байтовую версию utf8. Так что же я сделал для поддержки полного 4-байтового юникода поверх utf8 MySQL? Хорошо, base64 кодирует строки при сохранении в базе данных и base64 декодирует при извлечении.
Поскольку кодирование и декодирование base64 выполняется очень быстро, все вышеперечисленное работает отлично.
У вас есть следующие моменты, чтобы принять к сведению:
Кодировка Base64 использует на 33% больше памяти
Строки, хранящиеся в базе данных, не будут удобочитаемыми (вы можете продать это как функцию, в которой строки базы данных используют базовую форму шифрования).
Вы можете использовать вышеуказанный метод для любого механизма хранения, который не поддерживает Unicode.
