#python #python_3x #base64
Хотя на сайте http://crypt-online.ru/crypts/base64/ всё дешифруется верно.
Вот пример кода:
import base64
s = input()
resault = base64.b64encode(bytes(s, 'utf-8')) #Шифровка
print(resault)
print(base64.b64decode(resault)) #Дешифровка
Ответ 1
print(base64.b64decode(resault).decode()) и лучше resault = base64.b64encode(s.encode())
#c_sharp #base64
Какие в c# есть варианты кодирования последовательности байт в строковую форму, кроме
base64?
Вариант с base64 устраивает почти всем, но у него в символах алфавита используется
несколько неудобных знаков. Мне мешает символ '=', ещё на википедии упоминается, что
возможны проблемы с передачей base64-кодированной строки в url.
Как возможный вариант замены рассматриваю base58, которая упоминается там же на википедии
и которая используется в некоторых биткоин-прокотолах. У неё на выходе возможны только
варианты букв и цифр. Жаль, что в C# включили именно base64, а не base58, придётся
подключать какой-нибудь пакет.
Есть ли какие-то ещё варианты? Есть ли допустим base32 или base16?
Ответ 1
Просто в голову пришла вот такая мысль var str = "Hello, World!"; var encoded = HttpUtility.UrlEncode( Convert.ToBase64String(Encoding.Default.GetBytes(str))); Console.WriteLine(encoded); var decoded = Encoding.Default.GetString( Convert.FromBase64String(HttpUtility.UrlDecode(encoded))); Console.WriteLine(decoded);Ответ 2
Можно каждый байт кодировать как 16-ричное число (2 символа). Пример: 255 = 'FF' 165 = 'A5' 0 = '00' и т.д.
#javascript #java #c_sharp #base64
Доброго всем!
Есть строка, которая выдает ошибку при конвертации:
0JTQsNGA0LjQvCDRgdC60LjQtNC60YMg0L3QsCDQvdC+0LLQvtCz0L4=0LTQvdC40LUg0L/QvtC00LDRgNC60Lgh
При чем отдельные ее части:
0JTQsNGA0LjQvCDRgdC60LjQtNC60YMg0L3QsCDQvdC+0LLQvtCz0L4=
и
0LTQvdC40LUg0L/QvtC00LDRgNC60Lgh
Декодируются нормально, но если их соединить, то ошибка. Проверял себя через декодер
Лебедева https://www.artlebedev.ru/decoder/advanced/
Как это можно решить?
Ответ 1
Base64 конвертирует 3 байта в 4 символа, соответственно возникает проблема выравнивания длины байтов (набор байтов должен быть кратен 3), для чего и применяется символ (1 или 2) =, который как и написали в комментариях не может стоять в середине, а всегда в конце Ваша исходная строка Дарим скидку на новогодние подарки! должна конвертироваться в строку: 0JTQsNGA0LjQvCDRgdC60LjQtNC60YMg0L3QsCDQvdC+0LLQvtCz0L7QtNC90LjQtSDQv9C+0LTQsNGA0LrQuCE= которая, как нетрудно заметить слегка отличается от ваших строчек: 0JTQsNGA0LjQvCDRgdC60LjQtNC60YMg0L3QsCDQvdC+0LLQvtCz0L4= 0LTQvdC40LUg0L/QvtC00LDRgNC60Lgh Короче говоря, нельзя просто так и взять конкатенировать base64 строки
#html #изображения #base64
Делаю галерею. Хранить картинки на сервере мне проще в base64. Есть ли разница при
отображении картинки в html между указанием в атрибуте src пути до картинки или подстановкой
в этот тег строки base64 с точки зрения производительности или еще чего нибудь?
Ответ 1
хранить на сервере, это в базе? если у вас более менее большие изображения, то сохраняйте как статичные файлы. зачем каждый раз гонять туда сюда контент файлов через коннекшен базы? она и так большую часть нагрузки на себя берет. если вы используете base64, то изображения не кешируются, а отправляются вместе с HTML. Т.е юзер будет ждать пока загрузится 5 мегабайт страницы и отрендерится. Вместо того, чтобы отобразить контент и стили, а все остальное параллельно догружать (причем браузеры умеют перед полной загрузкой изображения показывать превьюшку) можно использовать серверный GZIP, в много раз уменьшая размер получаемого контента. статичные файлы в целях оптимизации принято отдавать на CDN. он выгружает контент с более близкого сервера, ускоряя загрузку. также ставят NGINX (только либо перед апачем), который быстро работает с стат. файлами. в base64 этот вариант не работаетОтвет 2
в случае указания пути к картинке, браузеру нужно будет сделать ещё один запрос и скачать картинку. Это как бы минус, но современные браузеры умеют делать это очень хорошо (если только им не мешать) и скачивать в паралель. Также картику легко закешировать. В том случае, если же картинка будет внутри html страницы, кеширование картинки невозможно, сама html страница стенет больше. Но если картинка мелкая (10на10 пикселей), то это может быть оправданно. Так как Вы делаете галерею, то для основных картинок (больших) лучше использовать классический подход. Это будет проще, быстрее (с точки зрения разработки и отображения) и более гибко. Мелкие картинки (стрелочки всякие) можно внутрь html вставить, но я не вижу никой вігоды от этого. На сервере все таки лучше хранить картики файлами - это как минимум на 25 процентов меньше по размеру (относительно base64 варианта). Способ с хранением картинки внутри страницы оправдан только если у Вас дорого стоит установка нового соединения (как по деньгам, так и по времени) хочется сохранять страницу как один файл с картинками вместе.
Создаю на стороне сервера уже готовый отчёт PDF со средствами Jasperreports, и кодирую в Base64. Дальше передаю всё это клиенту.
В клиенте:
$.ajax({url: "reports/pdfCurStateByOwner",
data: {p: document.getElementsByClassName('active')[0].dataset.idrju},
success: function (data) {
console.log(data);
//window.print(atob(data));
},
dataType: "text"
})
Что я получаю: и сервер и console.log(data) выдают одинаковую строку, и с помощью онлайн декодеров base64 тоже проверил получил желанный pdf файл.
Теперь мне надо этот полученный байт-код распечатать и вот тут получаю не то, что получил в качестве данных, а всю страницу... Что делаю не так?
Во-первых, вы совсем не «байт-код» с сервера отдаёте, а PDF, закодированный в BASE64-СТРОКУ. Во-вторых, вы получаете при распечатке именно то, что вызвали – а именно распечатку текущего окна. В-третьих, в функцию window.print() нельзя передать НИЧЕГО, т.к. она ничего не ожидает. Учитесь пользоваться документацией, пожалуйста.
РЕШЕНИЕ:
Современные обозреватели сети имеют ограничения безопасности на открытие всплывающих окон.
Для IE:
Согласно документации IE не поддерживает data:URL protocol для PDF. Поэтому в отличии от остальных для него следующий код работать не будет:
var newWin = window.open('data:application/pdf;base64,' + pdfInBase64, '_blank', 'width=500,height=300,menubar=yes,scrollbars=yes');
Также в IE действуют ограничения безопасности на открытие всплывающих окон. Обойти их очень непросто и поэтому для IE отдельное решение через navigator.msSaveOrOpenBlob
Для остальных обозревателей сети:
Для того, чтобы всплывающие окна открывались надо в адресной строке нажать на кнопку-оповещении о всплывающих окнах и выбрать выпадающее меню "Всегда разрешать всплывающие окна с «адрес в сети»". Такая кнопка появляется лишь тогда, если вы ещё такую кнопку для данной страницы не нажимали.
ИТАК РЕШЕНИЕ:
//pdfInBase64 соответствует «data» в строке «success: function (data)»
var pdfInBase64 = 'JVBERi0xLjMKMyAwIG9iago8PC9UeXBlIC9QYWdlCi9QYXJlbnQgMSAwIFIKL1Jlc291cmNlcyAyIDAgUgovQ29udGVudHMgNCAwIFI+PgplbmRvYmoKNCAwIG9iago8PC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzQ0Pj4Kc3RyZWFtCnicdZI7buRADERznaJOQDT/3VfYY9jBJrOJE1/fRQ1geIB1IomNalY9UoY/15JsfPIVrXg+VdZa+Ph72WmpQLXKVvy7/KRsR2mKGh5XrBBVlB2JQqwjmqhIiUAoOx9UqRzH+xVqsqbXlrBbu6llw+W4+xz088o7fbakoa2moe9zV7HENrx7wnSy762tmgxdLnXgc7zRbdIL7jVmTU8vat+un4DP7/9g6qGA0d0n3IM1Mzex2TRhqhIHOdEXzLaUIjfvjoWRvgNZW9pgDGfJas2h7ZYuZO6n1jkEm7oms/uakSQHZg2PM3zJTBY3Jocbt48RbOcMMw/5HK9rGcyfgL9ivk7ncbnWWPS+CexwJ82qRTesXXSxMkkdzOQ25y6XQa3b0Hb10Jr2/A7fG7Jlk7lp144ZLgfWIzLoJjszEcSTWqUB6atzdq3bhdkrXVzxupbB/ALY/Id+CmVuZHN0cmVhbQplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9QYWdlcwovS2lkcyBbMyAwIFIgXQovQ291bnQgMQovTWVkaWFCb3ggWzAgMCA1OTUuMjggODQxLjg5XQo+PgplbmRvYmoKMiAwIG9iago8PAovUHJvY1NldCBbL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0KL0ZvbnQgPDwKPj4KL1hPYmplY3QgPDwKPj4KPj4KZW5kb2JqCjUgMCBvYmoKPDwKL1Byb2R1Y2VyIChGUERGIDEuNikKL0NyZWF0aW9uRGF0ZSAoRDoyMDA5MDUwODEyMjkxMSkKPj4KZW5kb2JqCjYgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cKL1BhZ2VzIDEgMCBSCi9PcGVuQWN0aW9uIFszIDAgUiAvRml0SCBudWxsXQovUGFnZUxheW91dCAvT25lQ29sdW1uCj4+CmVuZG9iagp4cmVmCjAgNwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDA1MDEgMDAwMDAgbiAKMDAwMDAwMDU4OCAwMDAwMCBuIAowMDAwMDAwMDA5IDAwMDAwIG4gCjAwMDAwMDAwODcgMDAwMDAgbiAKMDAwMDAwMDY4MiAwMDAwMCBuIAowMDAwMDAwNzU3IDAwMDAwIG4gCnRyYWlsZXIKPDwKL1NpemUgNwovUm9vdCA2IDAgUgovSW5mbyA1IDAgUgo+PgpzdGFydHhyZWYKODYwCiUlRU9GCg==';
var URL = window.URL || window.webkitURL,
byteChars = atob(pdfInBase64),
bytes = [],
i = 0;
for (; i < byteChars.length; i++)
bytes[i] = byteChars.charCodeAt(i);
var blob = new Blob([new Uint8Array(bytes)], {type: 'application/pdf'});
// создаём object URL из Blob
var downloadUrl = URL.createObjectURL(blob);
if(window.navigator && window.navigator.msSaveOrOpenBlob)
window.navigator.msSaveOrOpenBlob(blob);
else
{
var newWin = window.open(downloadUrl, '_blank', 'width=500,height=300,menubar=yes,scrollbars=yes,status=yes,resizable=yes');
newWin.focus();
newWin.print();//чтобы эта строка сработала страница должна быть в сети, т.е. НЕ локально.
URL.revokeObjectURL(downloadUrl);
}
Этот код здесь через snippet не работает из-за ограничений в snippet. Пользователь @Other поделился поэтому ссылкой на этот пример на jsfiddle.net
Обратите внимание на то, что открытие в текущем окне при помощи перемены window.location или с помощью window.open вам не подойдёт, т.к. распечатать в этих окнах уже не получится, т.к. они в этом случае перезаписываются открываемой страницей.
Можете также посмотреть: PDF Reader на JavaScript от Мozilla. Но для этого нужен уже отдельный вопрос.
Доброго всем!
Есть строка, которая выдает ошибку при конвертации:
0JTQsNGA0LjQvCDRgdC60LjQtNC60YMg0L3QsCDQvdC+0LLQvtCz0L4=0LTQvdC40LUg0L/QvtC00LDRgNC60Lgh
При чем отдельные ее части:
0JTQsNGA0LjQvCDRgdC60LjQtNC60YMg0L3QsCDQvdC+0LLQvtCz0L4=
и
0LTQvdC40LUg0L/QvtC00LDRgNC60Lgh
Декодируются нормально, но если их соединить, то ошибка. Проверял себя через декодер Лебедева https://www.artlebedev.ru/decoder/advanced/
Как это можно решить?
Base64 конвертирует 3 байта в 4 символа, соответственно возникает проблема выравнивания длины байтов (набор байтов должен быть кратен 3), для чего и применяется символ (1 или 2) =, который как и написали в комментариях не может стоять в середине, а всегда в конце
Ваша исходная строка Дарим скидку на новогодние подарки! должна конвертироваться в строку:
0JTQsNGA0LjQvCDRgdC60LjQtNC60YMg0L3QsCDQvdC+0LLQvtCz0L7QtNC90LjQtSDQv9C+0LTQsNGA0LrQuCE=
которая, как нетрудно заметить слегка отличается от ваших строчек:
0JTQsNGA0LjQvCDRgdC60LjQtNC60YMg0L3QsCDQvdC+0LLQvtCz0L4=
0LTQvdC40LUg0L/QvtC00LDRgNC60Lgh
Короче говоря, нельзя просто так и взять конкатенировать base64 строки
Делаю галерею. Хранить картинки на сервере мне проще в base64. Есть ли разница при отображении картинки в html между указанием в атрибуте src пути до картинки или подстановкой в этот тег строки base64 с точки зрения производительности или еще чего нибудь?
хранить на сервере, это в базе?
если у вас более менее большие изображения, то сохраняйте как статичные файлы.
зачем каждый раз гонять туда сюда контент файлов через коннекшен базы?
она и так большую часть нагрузки на себя берет.
если вы используете base64, то
изображения не кешируются, а отправляются вместе с HTML. Т.е юзер будет ждать пока загрузится 5 мегабайт страницы и отрендерится. Вместо того, чтобы отобразить контент и стили, а все остальное параллельно догружать (причем браузеры умеют перед полной загрузкой изображения показывать превьюшку)
можно использовать серверный GZIP, в много раз уменьшая размер получаемого контента.
статичные файлы в целях оптимизации принято отдавать на CDN. он выгружает контент с более близкого сервера, ускоряя загрузку.
также ставят NGINX (только либо перед апачем), который быстро работает с стат. файлами.
в base64 этот вариант не работает