кодирование файла в base64
Мануал по методу кодирования base 16/32/64.
История появления кодировки.
Кодировка base берет свое начало еще с тех времен, когда не было определено сколько бит должно содержаться в одном байте. Сейчас всем известно, что в одном байте содержится 8 бит и с помощью него можно закодировать 256 различных значений, но так было не всегда.
Раньше были популярны кодировки, содержащие 6, 7 или 8 бит в байте. Таким образом, 6 бит позвояло закодировать в одном байте 64 различных значения, а 7-ми битная кодировка 128 значений. Казалось бы, что этого достаточно для того, чтобы закодировать буквенно-цифровой алфавит. Но вскоре была принята кодировка, содержащая 8 бит в одном байте.
Такая кодировка привнесла много проблем. В первую очередь, эти проблемы были связаны с оборудованием, которое уже работало на других кодировках, где байт содержал 6 или 7 бит. Но помимо этого была проблема обрезания 8-го бита в системах электронной почты, т.к. весь сфот был заточен под 7-ми или 6-ти битную кодировку. Как пример, 7-ми битная кодировка могла спокойно обнулить каждый 8-ой бит, что приводило к потери данных.
Тут на помощь пришел base 64. Идея base64 проста — обратимое кодирование, с возможностью восстановления, которое переводит все символы восьмибитной кодовой таблицы в символы, гарантированно сохраняющиеся при передаче данных в любых сетях и между любыми устройствами. В основе алгоритма лежит сведение трех восьмерок битов (24) к четырем шестеркам (тоже 24) и представление этих шестерок в виде символов ASCII. Таким образом получается обратимое шифрование, единственным недостатком которого будет увеличивающийся при кодировании размер — в соотношении 4:3.
Ниже приведена схема смещения битов в base 64
Пример:
Возьмем русский текст «АБВГД». В двоичной форме в кодировке Windows-1251 мы получим 5 байтов: 11000000 11000001 11000010
11000011 11000100 (00000000) — лишний нулевой байт нужен, чтобы общее число бит делилось на 6
Разделим эти биты на группы по 6: 110000 001100 000111 000010
110000 111100 010000 000000
Берем массив символов «ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/» и получившиеся числа переводим в эти символы, используя их, как индексы массива, получаем «wMHCw8Q». Остается только добавить в конце один символ «=», как указание на один лишний нулевой байт, который мы добавляли на первом шаге и получить окончательный результат: «АБВГД»: base64 = «wMHCw8Q=» Возможно и обратное преобразование.
Base 16
Base 32
Base 32 использует 32 символа: A-Z (или a-z), 2-7. Может содержать в конце кодированной последовательности несколько спецсимволов (по аналогии с base64). В данном алгоритме преобразования нам необходимо будет разделять двоичные значения на группы по 5 бит.
Основные отличия кодировок
Base64
Позволяет кодировать информацию, представленную набором байтов, используя всего 64 символа: A-Z, a-z, 0-9, /, +. В конце кодированной последовательности может содержаться несколько спецсимволов (обычно “=”).
Преимущества: Позволяет представить последовательность любых байтов в печатных символах. В сравнении с другими Base-кодировками дает результат, который составляет только 133.(3)% от длины исходных данных.
Недостатки: Регистрозависимая кодировка.
Base32
Использует только 32 символа: A-Z (или a-z), 2-7. Может содержать в конце кодированной последовательности несколько спецсимволов (по аналогии с base64).
Преимущества: Последовательность любых байтов переводит в печатные символы. Регистронезависимая кодировка. Не используются цифры, слишком похожие на буквы (например, 0 похож на О, 1 на l).
Недостатки: Кодированные данные составляют 160% от исходных.
Как закодировать/декодировать base?
В основном в заданиях по ctf вам будет попадаться base 64. Его легко определить, т.к. на конце будет знак «=». Например, мы кодировали строку «АБВГД» в base 64 и у нас получился результат «wMHCw8Q=». Как мы видим, здесь присутсвует знак «=», который говорит нам о том, что строка зашифрована в base 64.
Итак, как же ее декодировать? Все очень просто. Base 16, 32, 64 легко декодировать онлайн-сервисами. Т.е. вбиваете в гугле подобный запрос:»base 64 online decoder» и вам будет выдан большой перечнь ссылок на онлайн декодеры. Берем первый попавшийся, разве что для уточнения стоит воспользоваться сразу несколькимим онлайн декодерами.
Процесс кодирования почти ничем не отличается, разве, что вам нужно вбить в запросе не «decode», а «encrypt». Бывает, что нужно обращать внимание на то, какой кодировкой вы пользуетесь. В русскоязычной версии ОС «Windows» обычно используется кодировка windows-1251.
Практика
Задание 1:
Взгляните на эту строку:
ZmxhZ2lzVzBXdGhpc2lzQkFTRTY0Cg==
На конце мы видим «=», причем двойное, что сразу наводит на мысль, что это base 64. Воспользуемся онлайн-декодером.
Задание 2:
Посмотрим на эту строку:
MZWGCZ33MJQXGZJTGJ6Q
На конце мы не видим знака «=». На base 16 тоже не похоже, тогда попробуем base 32.
Снова воспользуемся онлайн-декодером.
И вот наш флаг: flag
Задание 3:
Была получена такая строка: 666C61677B48656C6C6F2C20576F726C64217D
Здесь нет ни знака «=», алфавит ограниченный. Похоже на base 16 или просто hex.
Как и прежде, пользуемся онлайн-декодером.
Отлично, у нас есть флаг, но это же задание можно было решить и через hex декодер.
Абсурдно быстрое кодирование и декодирование base64
Об авторе: Дэниель Лемир — профессор компьютерных наук в Университете Квебека (Канада). Его исследования затрагивают производительность программного обеспечения и инженерию данных
Компьютеры хранят данные как поток бит. Как изображения, аудио- или видеофайлы, так и бинарные файлы могут содержать практически любую последовательность бит.
Однако мы часто используем текстовые форматы; например, веб-страницы и электронные письма должны быть в текстовом формате. Как же мы отправляем изображения по электронной почте? Как внедряем картинки на веб-страницы? Один из вариантов — поставить ссылку на реальный бинарный файл. Другой типичный подход — встроить бинарный файл непосредственно в тело письма или веб-страницы с помощью base64. Base64 — это просто стандартный текстовый формат, который можно использовать для кодирования любых бинарных данных. Если быть точным, то код base64 — всегда валидный текст ASCII (и поэтому также валидный UTF-8). Каждый байт кода base64 содержит 6 бит данных. То есть мы «теряем» примерно 2 бита на байт. Поэтому эквивалент base64 бинарного файла будет примерно на 33% больше. На практике такое увеличение размера редко становится проблемой. Насколько я знаю, приложения к электронным письмам почти всегда кодируются в base64.
При написании HTML я нашёл удобным внедрять изображения напрямую в HTML-код с помощью схемы data URI. Например, в недавней статье я таким образом закодировал файл PNG. Крупнейшие веб-сайты вроде Google постоянно используют эту схему. Небольшим недостатком становится то, что веб-страницы чуть увеличиваются в размере (что очевидно) и нельзя воспользоваться преимуществами кэширования изображений. Но зато браузер экономит один сетевой запрос.
Если вы веб-разработчик, то можете использовать Web Storage для создания базы данных для вашего приложения на клиентской стороне. Эта клиентская БД будет хранить изображения и произвольные данные, но они все должны быть закодированы в base64.
Большинство движков баз данных поддерживают бинарные данные, но некоторые требуют в какой-то момент кодирования в base64: это MongoDB, Elasticsearch, Amazon SimpleDB и Amazon DynamoDB. Вероятно, и какие-то ещё.
Base64 повсеместно используется в криптографии для обмена ключами. Форма base64 также используется для передачи произвольных данных в составе URI.
К счастью, кодирование и декодирование base64 происходят быстро. Хотя есть случаи, когда недостаточная скорость может стать проблемой. Мэтт Крейн и Джимми Лин обнаружили медленное декодирование бинарных атрибутов base64 в Amazon DynamoDB.
Насколько быстро вы можете декодировать данные base64? На последнем процессоре Intel это требует примерно двух циклов на байт (из кэша) при использовании быстрого декодера вроде того, что встроен в браузер Chrome. Этот быстрый декодер, в основном, занят обращениями к таблице. Это намного медленнее, чем копирование данных в кэше (что занимает менее 0,05 циклов на байт).
Это лучшее, что можно получить?
Несколько лет назад Альфред Клопп показал, что можно добиться гораздо лучшего результата при использовании векторных инструкций. Войцех Мула, я сам и несколько коллег (в том числе Говард и Курц) решили серьёзно пересмотреть проблему. Мула открыл веб-страничку, посвящённую этой теме.
Мы обнаружили, что можно ускорить обработку в 10 раз и использовать всего около 0,2 циклов на байт на последних процессорах Intel при использовании векторных инструкций. Это по-прежнему больше, чем копирование, но намного меньше лимита, способного когда-либо стать самым узким местом системы. Должен обратить внимание, что в эти 0,2 цикла на байт входит обработка ошибок: декодер должен декодировать и проверять входные данные (например, если найдены недопустимые символы, то декодирование отменяется).
Код для нашего исследования доступен, так что можете воспроизвести результаты. Наша статья опубликована на arXiv и принята для публикации в веб-версии ACM Transactions.
Насколько я понимаю, наши хорошие результаты интегрированы в библиотеку base64 Кломпа.
Кодирование файла в base64
Если вы хоть раз делали какой-нибудь долгосрочный проект в веб-индустрии, то наверняка вам попадался на глаза термин «кодирование Base64». Base64 – это такой формат шифрования, который используется браузерами. Например, для реализации проверки подлинности вводимых данных в форму пароля и логина.
Однако, если вы поинтересуетесь мнением какого-либо специалиста о том, можно ли использовать это шифрование для серьезной защиты, то он просто посмеется. Base64 – двусторонний шифр; так что, если у вас есть оригинальная фраза, то можно просто применить его обратно и получить исходный текст.
Ладно, но если Base64 такой хлам, зачем я рассказываю вам об этом?
Ну, на самом деле, у кодировки Base64 есть еще одно очень хорошее применение. Она отлично подходит для кодирования сложных двоичных файлов и данных в очень простое текстовое представление, которое передается исключительно легко с помощью текстовых протоколов, таких как HTTP.
Подожди. Но HTTP обеспечивает передачу двоичных данных, правильно?
Да это так, но давайте представим на минуту, что вы хотите попытаться сохранить несколько запросов в вашем последнем проекте ASP.NET MVC. Что вы могли бы это сделать, надо вставлять изображения непосредственно в веб-страницы, а затем передавать их все в то же время при доставке исходную страницу. Если у вас появились сомнения по поводу достоверности этой схемы, посмотрите на исходный код для текущей страницы поиска Google. Вы увидите что-то вроде этого:
Рис. 1: Поиск Google использует кодировку Base64 для изображений
Обратите особое внимание на раздел в красном прямоугольнике. Это логотип Google, который отображается на странице, когда вы загрузите её. На самом деле, если вы посмотрите в веб-отладчик при загрузке страницы, вы увидите, что каждый раз логотип Google загружается из кэша на высокой скорости. Поскольку изображения в основном загружены на страницу, на дисплее происходит мгновенно, когда ваш браузер загружает вид.
То, что на то вы смотрите, называется кодированными в Base64URL данными. Это новая вещь, которая была введена в HTML5, и вы можете использовать её не только для изображений, но и для CSS-файлов и JavaScript. Где-нибудь в вашем HTML/MVC вьювере можно указать любые URL, вы можете использовать URL данные.
Запустите Visual Studio, и начните новый проект в режиме консоли. Файл «Program.cs» заполните так:
Когда вы выполните это, вы должны увидеть нечто вроде следующего:
Рис. 2: Тест кодирования Base64
Расшифровка строки обратно так же проста:
Рис. 3: Тест декодирования Base64
Если вы посмотрите на эти два примера кода, то вы увидите, что они работают с массивами байтов. Мы преобразовываем строку в байты, затем кодируем её, а декодер принимает строку и создает массив байт, содержащий декодированное содержимое.
Это означает, что кодирование и декодирование файла так же просто, как и строки:
Как вы можете видеть, однако, здесь получается большое количество данных.
Рис. 4: Осторожно; при кодировании в base64 на выводе получаются большие объемы данных.
Компромиссом здесь является то, что вы получаете мгновенную загрузку изображений в обмен на несколько больший размер страницы. Так что это не самый лучший способ для «тяжелых» изображений. А наибольший эффект будет достигнут, если ваш веб-сервер сжимает информацию перед отправкой. Из-за своих особенностей Base64 сжимает очень эффективно, так что объем данных, которые отправляются, будет очень небольшим.
Кодирование и декодирование в формате Base64
Документация
Кодирование Base64 широко используется в случаях, когда требуется перекодировать двоичные данные для передачи по каналу приспособленному для передачи текстовых данных. Это делается с целью защиты двоичных данных от любых возможных повреждений при передаче. Base64 широко используется во многих приложениях, включая электронную почту (MIME), и при сохранении больших объёмов данных в XML.
В языке JavaScript существуют две функции, для кодирования и декодирования данных в/из формат Base64 соответственно:
Функция atob() декодирует Base64-кодированную строку. В противоположность ей, функция btoa() создаёт Base64 кодированную ASCII строку из «строки» бинарных данных.
Tools
Related Topics
The «Unicode Problem»
Since DOMString s are 16-bit-encoded strings, in most browsers calling window.btoa on a Unicode string will cause a Character Out Of Range exception if a character exceeds the range of a 8-bit byte (0x00
0xFF). There are two possible methods to solve this problem:
Here are the two possible methods.
Solution #1 – escaping the string before encoding it
To decode the Base64-encoded value back into a String:
Unibabel implements common conversions using this strategy.
Solution #2 – rewrite the DOMs atob() and btoa() using JavaScript’s TypedArray s and UTF-8
Use a TextEncoder polyfill such as TextEncoding (also includes legacy windows, mac, and ISO encodings), TextEncoderLite, combined with a Buffer and a Base64 implementation such as base64-js.
When a native TextEncoder implementation is not available, the most light-weight solution would be to use TextEncoderLite with base64-js. Use the browser implementation when you can.
The following function implements such a strategy. It assumes base64-js imported as
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.