Форум » » Поделитесь ОБРАТНЫМ base64->ASCII конвертором » Ответить
Поделитесь ОБРАТНЫМ base64->ASCII конвертором
Вячеслав: Ищу конвертор из base64 в ASCII.(т.е. обратная конвертация) Если у кого есть фрагмент кода на SIMPL+ прошу поделиться безвозмездно или в обмен на универсальный конвертор кодировок и пр.
Ответов - 20
DmitriiP: на "чистом" SIMPL+ не дам, но сделал побыстрому base64_SSharp если 3ий проц, то попробуйте, работает в обе стороны
Игорь K.: Что за безумные идеи опять?
Вячеслав: Безумные конечно. Ново-испеченному универсальному конвертору для полноты не хватает. До сих пор был только 1 случай куда бы можно было применить base64->ascii, да и то не критично (чисто для удобства дебага) Жаль под 2 -серию не заработает. Как раз бы попробовал в части ascii-base64 на предмет производительности. А то беда с производительностью данной функции в моей реализации алгоритма. Вечером нашел еще 2 варианта на simpl+ но попробую уже завтра их. Просто сейчас заморочился частью E-mail модуля отвечающего за отправку файла. Двоичные данные должны кодироваться в base64 (хотя разумного объяснения этому не нашел). Так вот родной модуль от Crestron умудряется за 8с закодировать в base64 и передать 800кб файл. А у меня на каждые 450 исходных байт уходит от 5 до 25с по нарастающей. Тут даже порядки тяжело сравнивать т.е. примерно в 2250 раз Crestron модуль быстрее. Главная задержка при склеивании нарастающей длины строки str$=str$+add4bytes$; Но все 3 доступных варианта на simpl+, похоже имеют подобную часть (( Начал подозревать, что крестрон делает это как то иначе на более низком регистровом (аппаратном) уровне или даже через интернет сервис (второе не подтвердилось судя по wireshark). Может как то можно оптимизировать конструкцию str$=str$+add4bytes$ ? Кроме варианта разделять файл на большее количество более мелких частей и потом уже их складывать, ничего пока не могу придумать (.
Игорь K.: Регистровый уровень, говорите? Комментировать все это уже невозможно. У вас есть главный инженер, архитектор ПО, или же тот, кто разобравшись может сказать "Стоп" и направить работу по оптимальному пути?
p.vladi: Причём тут крестрон и почта с файлами???? Вы бы еще SAMBA модуль написали, и сделали из него домин-контролер с принт сервером :-))
Igor: p.vladi, зря вы подкинули эту идею :) Сюда уже идут килограммы незакатанного кода.
Вячеслав: А по существу? По оптимизации строковых операций можете что то предложить? P.S. Не я придумал файлы с крестрона рассылать, а сам крестрон см. SendMailAdvance(sServer,25, sName, sPassword, sFrom, sTo, sCC, sSubject, sMessage,1,"\\CF0\\1.pdf"); Я лишь постарался сохранить преемственность своего модуля в котором главной целью было исправить кодовую страницу для возможности отправки сообщений с кириллицей. А samba это тема, неужели никогда в мыслях не было считать параметры конфигурационного файла на сетевом ресурсе?
Игорь K.: ОК, резюмируем, подбиваем бабки. Оптимизация строковых операций это очень общий вопрос, могу отослать к "Искусству программирования" Кнута. Переписка я процессором Crestron это фетиш, а пересылка вложений двойной фетиш. Переписка на кириллице вообще тупиковый путь любого хорошего проекта, во всех смыслах. Выбирайте любой. Игра на "чужом поле" не самая лучшая манера поведения.
Ale4ko: DmitriiP пишет: на "чистом" SIMPL+ не дам А мне не жалко Держите модуль Crestron SIMPL+ Base64 encoding/decoding module по идеи должен работать и на 2й ветке. Я новичок так что код может быть сыроват, любые комментарии по оптимизации кода приветствуются.
eoulianov: Ale4ko, доброе утро! Алгоритмы конвертации кодировок, к счастью, простые - линейные, поэтому оптимизировать время выполнения хотя бы "на порядок" не получится. Но есть фишка с ускорением вычислений с помощью индексирования. Допустим, нужно как можно быстрее вычислять косинусы целых углов 0-360 градусов - как это сделать? Нужно создать массив [0..360], записать в него значения косинусов и потом получать их как выборку по индексу из массива COS[ x ] а не как вызов функции cos( x ). В нашем случае так можно поступить со строкой [pre2]enc1 = FIND(mid(input, n ,1),CHARS)-1;[/pre2] в ней сначала строковая функция MID() выгрызает строку в один символ, а затем другая строковая функция FIND() ищет эту односимвольную подстроку в CHARS$. Нужно создать нечто обратное CHARS и заполнить его (хоть бы и прямо из CHARS): [pre2] #DEFINE_CONSTANT CHARS "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=" INTEGER CODES[255]; /* ..... */ Function Main() { INTEGER i; SetArray( CODES, 255 ); // Сначала всё заполним "сбойными" кодами 255 for( i=1 to Len(CHARS) ) CODES[ Byte(CHARS,i) ] = i-1; // А затем для "правильных" символов из CHARS впишем их код i-1. }[/pre2] И уже тогда в функции base64_decode() можем написать [pre2]enc1 = CODES[ Byte( input, n ) ];[/pre2] Эта конструкция вместо вызова двух строковых функций делает только две выборки по индексу. Ещё ускориться можно если сделать сразу индекс из 4-х символов base64 в три символа однобайтовой кодировки - тогда за одну выборку будем получать сразу из mid(input,n,4) все три chr1..chr3, но этот индекс займёт 48 мегабайт, пожалуй многовато) Иногда полезно проверять входные данные - что все эти enc1..enc4 оказались в 0..64, а не 255 - т.е. что строка в input действительно состоит из сиволов base64 и кратна 4 по длине, иначе можно насыпать warnings в лог при попытке обрабатывать что-то не то.
Игорь K.: eoulianov, предлагаете им заняться индексированием? Может обсудим почему таблицы Брадиса зашивают в ПЗУ арифмометров? Или это просто к слову? Предлагаю сначала определиться на уровне "Надо-Не надо", а потом терзать Прикладной Характер программирования нашего Crestron.
DmitriiP: Моё мнение: В данном случае на уровне "Надо-Не надо" однозначно надо. Вместо вызова на каждые 4 байта текста 8 функции поиска по КОНСТАНТНОЙ строке , будет всего 4 выборки из масива. P.S. И это только на 4 байтах, про "и передать 800кб файл." я ..... P.S.2 Конвертор для base64 штука полезная, много где встречается, но почтовые вложения средствами крестрона я врядли буду :)
Ale4ko: eoulianov, спасибо за советы обязательно возьму на заметку! да и к сати ребята давайте по активней обмениваться опытом ибо вопрос надо или нет само собой отпадает фактом существованием топика.
Игорь K.: ОК, где это может понадобиться? Когда то немало времени потратил на корректное отображение кириллических названий треков сетевого плеера Pioneer. Больше этой темы не всплывало ни в каком виде ни там ни тут.
Вячеслав: Ну мы то не наездами в России, мы тут живем и работаем Для Ale4ko : Все очень круто и компактненько, правда напоминает мне другой модуль от Niko Brasseur вплоть до названия переменных. Одно лишь замечание, надо переменную result все же инициализировать = "" За DECODER отдельное мерси Жаль опять конструкция сбора строки с добавлением новых 4 символов присутствует. Она то и занимает максимальное время операции (по нарастающей с ростом длины результирующей строки). Но видать без нее никак. Единственное что нарыл хэлпе, это функцию setstring Попробую, может она даст какой то прирост в скорости. Но как это крестрон делает так молниеносно не дает покоя (даже предположив идею существования массива на все возможные варианты (хотя по нему тоже искать надо), от сбора то строки s=s+n никуда не деться.
DmitriiP: Вячеслав пишет: Но как это крестрон делает так молниеносно не дает покоя (даже предположив идею существования массива на все возможные варианты (хотя по нему тоже искать надо), от сбора то строки s=s+n никуда не деться. да они не парятся особо, в отличии от вас, пользуются родными системными функциями (благо у них есть к ним доступ), через FileStream считывают файл в масив byte[] и потом просто String УраУНасВсёПолучилось = Convert.ToBase64String(масив,0,длина масива); На Simpl+ думаю долго будете пытатся побить их результат... P.S. ~1,073,741,824 длина String в с# против 65,536 в Simpl+
Вячеслав: Так системные функции тоже имеют некоторый код реализации и происходят не по волшебству. Другой разговор, что они могут использовать низкоуровневое программирование.
eoulianov: Игорь K., вопрос целесообразности оптимизации в применении к Crestron у меня возникает (и находит успешное решение) крайне редко - либо когда нужно ускорить обработку фидбэка и поскорее показать его пользователю (чтобы он не расстроился и не начал давить на всё подряд - я всегда переписывал модуль начисто), либо когда нужно подобрать более быстрый макрос (обычно это приводило к замене линейного макроса на условные). В этом смысле все эти Кнутовские приёмчики не важны, я написал потому что Ale4ko спросил) Можно делать какие угодно "в лоб" написанные модули, лишь бы стабильно работало) Если от них начинает серьёзно тупить контроллер - я просто переношу их с конотроллеров с которыми работают пользовательские интерфейсы на другие, и тогда эти тормоза становятся незаметны. На Series2 MakeString() работала шустрее чем сборка строки через +, а если удавалось написать обработку на SIMPL - то это никогда не тормозило. Как на Core3 - не знаю. Работа с потоками и строками - определённо не сильная сторона S+))
Игорь K.: Это понятно, но по существу, большинство таких задач не для Crestron.
Вячеслав: Итог таков: Самым подходящей для работы с большими строками оказалась SETSTRING, время работы которой в отличии от обычного сложения и makestring не зависит от длины строки. Конечно, родной модуль от Crestron все еще в 150 раз быстрее конвертирует в base64, но уже можно жить ). Использование параллельных процессов и табличных данных лишь увеличивает время кодирования.
полная версия страницы