Отправлено: 20.10.16 16:45. Заголовок: Поделитесь ОБРАТНЫМ base64->ASCII конвертором

Ищу конвертор из base64 в ASCII.(т.е. обратная конвертация)
Если у кого есть фрагмент кода на SIMPL+ прошу поделиться безвозмездно или в обмен на универсальный конвертор кодировок и пр.

 Отправлено: 20.10.16 19:17. Заголовок: для SIMPL+ не дам, н..

на "чистом" SIMPL+ не дам, но сделал побыстрому base64_SSharp если 3ий проц, то попробуйте, работает в обе стороны

 Отправлено: 20.10.16 19:50. Заголовок: Что за безумные идеи..

Что за безумные идеи опять?

 Отправлено: 20.10.16 23:20. Заголовок: Безумные конечно. Н..

Безумные конечно.
Ново-испеченному универсальному конвертору для полноты не хватает.
До сих пор был только 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$ ?
Кроме варианта разделять файл на большее количество более мелких частей и потом уже их складывать, ничего пока не могу придумать (.

 Отправлено: 21.10.16 08:18. Заголовок: Регистровый уровень,..

Регистровый уровень, говорите?
Комментировать все это уже невозможно.
У вас есть главный инженер, архитектор ПО, или же тот, кто разобравшись может сказать "Стоп" и направить работу по оптимальному пути?

 Отправлено: 21.10.16 10:14. Заголовок: Причём тут крестрон ..

Причём тут крестрон и почта с файлами????
Вы бы еще SAMBA модуль написали, и сделали из него домин-контролер с принт сервером :-))

 Отправлено: 21.10.16 10:22. Заголовок: p.vladi, зря вы подк..

p.vladi, зря вы подкинули эту идею :) Сюда уже идут килограммы незакатанного кода.

 Отправлено: 21.10.16 16:56. Заголовок: А по существу? По оп..

А по существу? По оптимизации строковых операций можете что то предложить?
P.S. Не я придумал файлы с крестрона рассылать, а сам крестрон см. SendMailAdvance(sServer,25,
sName,
sPassword,
sFrom,
sTo,
sCC,
sSubject,
sMessage,1,"\\CF0\\1.pdf");
Я лишь постарался сохранить преемственность своего модуля в котором главной целью было исправить кодовую страницу для возможности отправки сообщений с кириллицей.
А samba это тема, неужели никогда в мыслях не было считать параметры конфигурационного файла на сетевом ресурсе?

 Отправлено: 21.10.16 17:21. Заголовок: ОК, резюмируем, подб..

ОК, резюмируем, подбиваем бабки.
Оптимизация строковых операций это очень общий вопрос, могу отослать к "Искусству программирования" Кнута.
Переписка я процессором Crestron это фетиш, а пересылка вложений двойной фетиш.
Переписка на кириллице вообще тупиковый путь любого хорошего проекта, во всех смыслах. Выбирайте любой.
Игра на "чужом поле" не самая лучшая манера поведения.

 Отправлено: 22.10.16 06:04. Заголовок: DmitriiP пишет: на ..

DmitriiP пишет:

цитата:

на "чистом" SIMPL+ не дам

А мне не жалко
Держите модуль Crestron SIMPL+ Base64 encoding/decoding module по идеи должен работать и на 2й ветке.

Я новичок так что код может быть сыроват, любые комментарии по оптимизации кода приветствуются.

 Отправлено: 22.10.16 12:11. Заголовок: Ale4ko, доброе утро!..

Ale4ko, доброе утро!
Алгоритмы конвертации кодировок, к счастью, простые - линейные, поэтому оптимизировать время выполнения хотя бы "на порядок" не получится.

Но есть фишка с ускорением вычислений с помощью индексирования. Допустим, нужно как можно быстрее вычислять косинусы целых углов 0-360 градусов - как это сделать? Нужно создать массив [0..360], записать в него значения косинусов и потом получать их как выборку по индексу из массива COS[ x ] а не как вызов функции cos( x ).

В нашем случае так можно поступить со строкой

enc1 = FIND(mid(input, n  ,1),CHARS)-1;

в ней сначала строковая функция MID() выгрызает строку в один символ, а затем другая строковая функция FIND() ищет эту односимвольную подстроку в CHARS$. Нужно создать нечто обратное CHARS и заполнить его (хоть бы и прямо из CHARS):

 #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. 
 }

И уже тогда в функции base64_decode() можем написать

enc1 = CODES[ Byte( input, n ) ];

Эта конструкция вместо вызова двух строковых функций делает только две выборки по индексу.

Ещё ускориться можно если сделать сразу индекс из 4-х символов base64 в три символа однобайтовой кодировки - тогда за одну выборку будем получать сразу из mid(input,n,4) все три chr1..chr3, но этот индекс займёт 48 мегабайт, пожалуй многовато)

Иногда полезно проверять входные данные - что все эти enc1..enc4 оказались в 0..64, а не 255 - т.е. что строка в input действительно состоит из сиволов base64 и кратна 4 по длине, иначе можно насыпать warnings в лог при попытке обрабатывать что-то не то.

 Отправлено: 22.10.16 13:49. Заголовок: eoulianov, предлагае..

eoulianov, предлагаете им заняться индексированием?
Может обсудим почему таблицы Брадиса зашивают в ПЗУ арифмометров?
Или это просто к слову?
Предлагаю сначала определиться на уровне "Надо-Не надо", а потом терзать Прикладной Характер программирования нашего Crestron.

 Отправлено: 22.10.16 17:28. Заголовок: Моё мнение: В данном..

Моё мнение: В данном случае на уровне "Надо-Не надо" однозначно надо.

Вместо вызова на каждые 4 байта текста 8 функции поиска по КОНСТАНТНОЙ строке , будет всего 4 выборки из масива.

P.S. И это только на 4 байтах, про "и передать 800кб файл." я .....
P.S.2 Конвертор для base64 штука полезная, много где встречается, но почтовые вложения средствами крестрона я врядли буду :)

 Отправлено: 22.10.16 18:36. Заголовок: eoulianov, спасибо з..

eoulianov, спасибо за советы обязательно возьму на заметку!

да и к сати ребята давайте по активней обмениваться опытом ибо вопрос надо или нет само собой отпадает фактом существованием топика.

 Отправлено: 22.10.16 20:53. Заголовок: ОК, где это может по..

ОК, где это может понадобиться?

Когда то немало времени потратил на корректное отображение кириллических названий треков сетевого плеера Pioneer.
Больше этой темы не всплывало ни в каком виде ни там ни тут.

 Отправлено: 22.10.16 22:49. Заголовок: Ну мы то не наездами..

Ну мы то не наездами в России, мы тут живем и работаем

Для Ale4ko :

цитата:

Все очень круто и компактненько, правда напоминает мне другой модуль от Niko Brasseur вплоть до названия переменных. Одно лишь замечание, надо переменную result все же инициализировать = "" За DECODER отдельное мерси

Жаль опять конструкция сбора строки с добавлением новых 4 символов присутствует. Она то и занимает максимальное время операции (по нарастающей с ростом длины результирующей строки). Но видать без нее никак.
Единственное что нарыл хэлпе, это функцию setstring Попробую, может она даст какой то прирост в скорости. Но как это крестрон делает так молниеносно не дает покоя (даже предположив идею существования массива на все возможные варианты (хотя по нему тоже искать надо), от сбора то строки s=s+n никуда не деться.

 Отправлено: 23.10.16 09:34. Заголовок: Вячеслав пишет: Но ..

Вячеслав пишет:

цитата:

Но как это крестрон делает так молниеносно не дает покоя (даже предположив идею существования массива на все возможные варианты (хотя по нему тоже искать надо), от сбора то строки s=s+n никуда не деться.

да они не парятся особо, в отличии от вас, пользуются родными системными функциями (благо у них есть к ним доступ), через FileStream считывают файл в масив byte[] и потом просто
String УраУНасВсёПолучилось = Convert.ToBase64String(масив,0,длина масива);

На Simpl+ думаю долго будете пытатся побить их результат...

P.S. ~1,073,741,824 длина String в с# против 65,536 в Simpl+

 Отправлено: 23.10.16 13:02. Заголовок: Так системные функци..

Так системные функции тоже имеют некоторый код реализации и происходят не по волшебству. Другой разговор, что они могут использовать низкоуровневое программирование.

 Отправлено: 23.10.16 15:22. Заголовок: Игорь K., вопрос цел..

Игорь K., вопрос целесообразности оптимизации в применении к Crestron у меня возникает (и находит успешное решение) крайне редко - либо когда нужно ускорить обработку фидбэка и поскорее показать его пользователю (чтобы он не расстроился и не начал давить на всё подряд - я всегда переписывал модуль начисто), либо когда нужно подобрать более быстрый макрос (обычно это приводило к замене линейного макроса на условные).
В этом смысле все эти Кнутовские приёмчики не важны, я написал потому что Ale4ko спросил)

Можно делать какие угодно "в лоб" написанные модули, лишь бы стабильно работало) Если от них начинает серьёзно тупить контроллер - я просто переношу их с конотроллеров с которыми работают пользовательские интерфейсы на другие, и тогда эти тормоза становятся незаметны.

На Series2 MakeString() работала шустрее чем сборка строки через +, а если удавалось написать обработку на SIMPL - то это никогда не тормозило. Как на Core3 - не знаю. Работа с потоками и строками - определённо не сильная сторона S+))

 Отправлено: 24.10.16 10:27. Заголовок: Это понятно, но по с..

Это понятно, но по существу, большинство таких задач не для Crestron.

 Отправлено: 08.11.16 18:26. Заголовок: Итог таков: Самым п..

Итог таков:
Самым подходящей для работы с большими строками оказалась SETSTRING, время работы которой в отличии от обычного сложения и makestring не зависит от длины строки.
Конечно, родной модуль от Crestron все еще в 150 раз быстрее конвертирует в base64, но уже можно жить ).
Использование параллельных процессов и табличных данных лишь увеличивает время кодирования.