Отправлено: 06.10.19 13:28. Заголовок: Кириллица в адресной книге кодека Cisco

Добрый день!

Есть кодек Cisco Room и последний драйвер с маркета - Cisco Room Devices Driver 3.2.4.

Проблема в том, что из модуля строки с именами кириллицей выходят без старшего байта (04h). Т.е. нет возможности различить, например, цифру "1" (0031h) и русскую букву "б" (0431h).
С пробелом будут схожие проблемы.

Это можно как-то решить, как думаете? Не перепахивая сильно модуль (нет времени). Может, в более старых версиях этой проблемы не было?
Управлял когда-то кодеком SX20 через API, но там не работал с адресной книгой. Да и этот вариант что-то сомнительный, времени мало....

 Отправлено: 07.10.19 13:40. Заголовок: Надо проверить. Про ..

Надо проверить. Про какие серийные выходы идет речь??

Сам пока до отладки кодека Cisco Spark не добрался, но коллега использовал Cisco Room Device 3.1(cm) из базы данных Crestron и по его словам работало всё без проблем.
В программе он использовал преобразование из 2-х байтного UTF-8 в UTF-16(WEB). Второй это то что приводит к формату ""&#x...;" Это алгоритм известный под названием (ASCIItoUTF16cyr.usp). Первый использует алгоритм известный под названием (UTF8toASCII.usp)
Все конечно не имеет смыла, если выход реально однобайтный, но не верьте дебаггеру. Toolbox в смысле шрифтов соврет не дорого возьмет, может отображать не так как есть на самом деле в смысле шрифтов.
Попробуйте двойное преобразование UTF8->ASCII->ASCII->UTF16WEB, закрыв глаза на дебаггер.

 Отправлено: 07.10.19 14:38. Заголовок: Повозился еще немног..

Повозился еще немного.

Например, возмем локальную адресную книгу - ее удобно заполнять через WEB-интерфейс кодека. Занесем туда запись с именем "Тест1"
С модуля выходит сигнал "LocalPhonebook_Entries_XSIG", далее этот сигнал Intersystem Communications раскладывает на отдельные [LocalPhonebook]_Name_1, [LocalPhonebook]_Name_2 и т.д. Вот тут уже и теряется байт 04.
А сам сигнал "LocalPhonebook_Entries_XSIG" имеет вид: \xC8\x00\x04\x22\x04\x35\x04\x41\x04\x42\x31\xFF. Второй байт - номер посылки. Т.е. для второй записи будет \xC8\x01........

На выходе Intersystem Communications уже имеем: \x22\x35\x41\x42\x31


Хорошо бы еще, конечно, если бы удалось Intersystem Communications настроить так, что бы он не проглатывал 04h.

 Отправлено: 08.10.19 08:53. Заголовок: Intersystem Communic..

Intersystem Communications, похоже устарел, не поддерживает unicode и вырезает непонятные ему байты из строк, я с этим тоже столкнулся на модуле Cisco.

Пришлось написать свой "заменитель" на simpl+.
На входе этот xsig, на выходе массив строк.
Это оказалось совсем несложно.

Потом, помню, приходилось ещё эти строки пропускать через симпловский модуль Convert to unicode в режиме "Mark as unicode", он их как-то метит, а без этого панель не понимала, что это за байты ей суют и ерунду отображала.

 Отправлено: 08.10.19 09:47. Заголовок: Добрый день. >&..

Добрый день.

>> Intersystem Communications, похоже устарел, не поддерживает unicode и вырезает непонятные ему байты из строк

Вот и мне совершенного не понятно, с какого перепуга он берет и что-то вырезает! По-идее, Intersystem Communications, прям из его хелпа, определяет только заголовок, порядковый индекс сигнала и далее идут БАЙТЫ данных. Какая ему разница, unicode там или мой собственный протокол со своим значением байтов!

 Отправлено: 08.10.19 11:11. Заголовок: Попробовал пока обой..

Попробовал пока обойтись без парсера. И ничего не получается.

Пропустил сигнал XSIG через Convert To ASCII в режиме Pass Thru Mark As ASCII. Не помогает. На выходе Intersystem Communications опять строки без 04h. Тут уже, по-идее, нет никаких старших байт юникода на входе в Intersystem, которые могут теряться при работе SIMPL. Что за... хотя вспоминаю, когда мне надо было в SIMPL+ запоминать кириллические строки, перед записью в NVRAM я преобразовывал юникодные строки в ASCII а потом уже снаружи обратно и все работало . Почему Intersystem Communications упорно вырезает 04h не понятно. Т.е. тут поток байт какой-то ASCII не ACSII получается.

 Отправлено: 08.10.19 16:21. Заголовок: http://crestron.bord..

http://crestron.borda.ru/?1-0-0-00001258-000-0-0-1485907021

цитата:

Никакие символы в SIMPL не работают со СТАРШИМИ байтами кода символа, они не передаются в потоках (по rs232 или через TCP/IP клиент), не проходят сквозь Intersystem Communications и CrossPoints, нет символов SIMPL их анализирующих в духе Serial to Analog, даже панели Crestron их не получат.

- Либо пишите в службу поддержки/crestronlabs. Чтоб убрали это косяк.
- Либо делать свой велосипед
- Либо каждый раз редактируйте Cisco Room Device: Прогоняя все тексты идущие в Intersystem Communications через Convert To ASCII в режиме ALL Bytes и потом обратно на выходе

 Отправлено: 08.10.19 16:56. Заголовок: DmitriiP Вот спасибо..

DmitriiP Вот спасибо! Буду пробовать, о результатах напишу.

 Отправлено: 08.10.19 17:47. Заголовок: Хотя стоп. спешу. Не..

Хотя стоп. спешу. Недопонял.

Ведь первый же Convert To ANSI в режиме All Bytes нарушит "пакет" для Intersystem Communications и он его не поймет?

 Отправлено: 08.10.19 18:03. Заголовок: он ничего не нарушит..

он ничего не нарушит.

вы конвертируете (разъеденяете старшие и младшие байты) входящей строки "двухбайтовой на символ"
\u0422\u0435\u0441\u0442\u0031

в "однобайтовые" \u00XX
\x04\x22\x04\x35\x04\x41\x04\x42\x31

а не xsig между Intersystem Communications :)

на выходе из принимающего Intersystem Communications конвертируете "склеиваете" их обранто в UTF-16 через Convert to UTF-16

 Отправлено: 08.10.19 18:33. Заголовок: http://easycaptures...

 Отправлено: 08.10.19 18:35. Заголовок: Результат "Визуа..

Результат "Визуально однаковых строк" из примера выше:

 Отправлено: 08.10.19 21:27. Заголовок: Правильно ли я поним..

Правильно ли я понимаю, что я захожу в модуль Cisco. Там есть Simpl+ модуль, с него есть строковые выходы LocalPhonebook_Entry1 ….NNN.
А также в модуле Cisco есть "передающий" Intersystem Communications.

Вот сигнал, например LocalPhonebook_Entry1 я пропускаю через Convert To ANSI в режиме All Bytes,
пусть он будет теперь LocalPhonebook_Entry1_A. Этот сигнал я отправляю на первый вход "передающего" Intersystem Communications.

В отладчике после приемного Intersystem Communications, с выходов которого и выходят названия записей видно, что нет сигнала с индексом 0. Сразу идет второй сигнал, с индексом 1.
Т.е. раскодировать в UTF уже нечего....

 Отправлено: 09.10.19 03:08. Заголовок: похоже строка из мо..

похоже строка из [Simpl+] модуля выходит не помеченой как UTF_16, поэтому на выходе Convert To ANSI вы LocalPhonebook_Entry1_A получаете как "", это лечится двумя способами:

или

[Simpl+] LocalPhonebook_EntryNNN -> [Convert To UTF-16 (Pass Thru Mark as UTF-16)] -> LocalPhonebook_EntryNNN_marked_as_UTF-16 -> [Convert To ANSI (All Bytes)] -> LocalPhonebook_EntryNNN_ASCII -> [Intersystem Communications]

или просто добавить в [Simpl+ модуль] строку #ENCODING_UTF16 (что на мой личный взгляд правильнее) и дальше -> [Convert To ANSI (All Bytes)]





C ANSI однобайтовой и UTF-16 двухбайтовой у крестрона вечный косяк. и он умножается на х3 (Simpl# / Simpl+ /Simpl) ... Поэтому вечно приходится шаманить ...

Лечить это или делать нормальный дебагер показывающей тип строки похоже никто не собирается... Они также до сих пор судя по модулю Scheduler незнают или игнорируют что в мире есть 24ч время помимо AM/PM и тд. :)

 Отправлено: 09.10.19 21:44. Заголовок: Увы, пока непонятнос..

Увы, пока непонятности продолжаются. В модуле Cisco сделал цепочку Simpl+] LocalPhonebook_EntryNNN -> [Convert To UTF-16 (Pass Thru Mark as UTF-16)] -> LocalPhonebook_EntryNNN_marked_as_UTF-16 -> [Convert To ANSI (All Bytes)] -> LocalPhonebook_EntryNNN_ASCII -> [Intersystem Communications] . На приемной стороне делал Convert To UTF-16 (Pass Thru Mark as UTF-16) и Convert To UTF-16 (Smandard Order). В SG Xpanel ничего (подпись Advanced Button пустая) Хотя в отладчике видно вроде нормальную строку перед панелью: \x04\x22\x04\x35\x04\x41\x04\x42

Но. Работает с кириллицей, если я:
1. Не модифицирую модуль для Cisco вообще.
2. На приемной стороне простейшим парсером на SIMPL+ (внутри модуля кодировка ASCII !) вырезаю, например, последовательность для пятого сигнала, снаружи ее пропускаю через Convert To UTF-16 (Pass Thru Mark as UTF-16) и отправляю на Xpanel. Интересно, что если Convert To UTF-16 (Pass Thru Mark as UTF-16) заменить на Mark As (UTF16) то не работает.

Хотелось бы все-таки домучать первый вариант. Парсер сделать наверное получится, но хочется убедится, что мир 100% познаваем )))

 Отправлено: 10.10.19 03:32. Заголовок: Попробуйте заменить ..

Попробуйте заменить

цитата:

На приемной стороне делал Convert To UTF-16 (Pass Thru Mark as UTF-16)

на (Pass Thru Mark as ASCII)

На выходе из [Intersystem Communications] вы получаете "ASCII" строку а не "UTF-16"

 Отправлено: 10.10.19 11:58. Заголовок: Сделал парсер. Вроде..

Сделал парсер. Вроде работает.

А целиком на SIMPL так и не могу понять логику. Почему же на приемной стороне нужно менять Convert To UTF-16 (Pass Thru Mark as UTF-16) на (Pass Thru Mark as ASCII) ?

По идее:

1. В модуле SIMP+ используем директиву #ENCODING_UTF16 + Convert To ANSI (All Bytes) снаружи или, не меняя ничего в модуле, после него на каждом выходе Convert To UTF-16 (Pass Thru Mark as UTF-16) + Convert To ANSI (All Bytes) Пробовал так и так кстати. Этими действиями отучаем Intersystem Communications спотыкаться на Юникоде. Работал пока с одним, пятым выходом Intersystem Communications, там была кириллица.

2. На приемной стороне, на выходах Intersystem Communications, имеем байтовые последовательности, в принципе уже отвечающие правилу кодирования UTF-16, просто теперь нужно их пометить так, чтобы вся цепочка до SG Xpanel включительно понимала, что это Юникод и как его отображать. Для этого нужно Convert To UTF-16 (Pass Thru Mark as UTF-16) или как вариант, может даже Mark As (UTF16), на пятом выходе.

3. Это все не работает (((

 Отправлено: 10.10.19 14:11. Заголовок: CEA пишет: А целико..

CEA пишет:

цитата:

А целиком на SIMPL так и не могу понять логику.

1. Возьмём букву "Т" на выходе из simpl+ она выходит \u0422 что при #ENCODING_UTF16 что при #ENCODING_ASCII
2. Нам надо пропустить её через Intersystem Communications, которому пофиг что на входе он в xsig пропускает всё, но выход режит "СТАРШИЕ" байты \xXX22
3. Значит нам надо \u0422 разбить на \u0004 и \u0022
4. Если из модуля строка вышла с пометкой #ENCODING_UTF16 то [Convert To ANSI (All Bytes)] её обрабатывает правильно
Если же строка без этой пометки то он ("по непонятным никому причинам") игнорирует "СТАРШИЕ" байты и на выходе ничего не выдаёт, поэтому явно даём ему понять что строка UTF-16 при помощи Convert To UTF-16 (Pass Thru Mark as UTF-16)

цитата:

Почему же на приемной стороне нужно менять Convert To UTF-16 (Pass Thru Mark as UTF-16) на (Pass Thru Mark as ASCII) ?

5. На Выходе из Intersystem Communications мы имеем \u0004 \u0022 и нам надо их склеить обратно в \u0422
6. Всё в точности найоборот:
так как Convert To UTF-16 (Smandard Order) также тупит ("по непонятным никому причинам") без явного указания типа приходящей строки.указываем брать только младшие байты Convert To ASCII (Pass Thru Mark as ASCII)

P.S. \u0422 и \u0004 \u0022 это \x04\x22 в дебагере.

 Отправлено: 01.11.19 13:03. Заголовок: Если чо, вот код мод..

Если чо, вот код модуля, которым я заменил Intersystem Communications для вывода строк с адресной книги Cisco:

 
    #DEFINE_CONSTANT IN_BUFFER_SIZE 512 
    #DEFINE_CONSTANT MAXOUT 255 
  
  
 BUFFER_INPUT Rx[IN_BUFFER_SIZE];  
 STRING_OUTPUT sout[MAXOUT];  
 integer Working;                  
                   
 CHANGE Rx 
 { 
 	integer out; 
 	string temp[IN_BUFFER_SIZE]; 
  
 	if(Working) return; 
 	Working = 1; 
 	 
 	 
 	while(1) 
 	{ 
 		temp = Gather("\xFF", Rx); 
  
 		if(byte(temp, 1) = 0xC8) 
 		{ 
 			out = byte(temp, 2);  
 			sout[out+1] = mid(temp, 3, len(temp)-3); 
 		} 
 		else 
 		if(byte(temp, 1) = 0xFC) 
 		{ 
 			for(out=1 to MAXOUT) 
 				sout[out]=""; 
 		} 
 	}	 
 } 
  
 Function Main() 
 { 
     WaitForInitializationComplete(); 
 	Working = 0; 
 } 
 

 Отправлено: 02.11.19 00:04. Заголовок: Коллеги а почему пре..

Коллеги а почему пресеты не сохраняются (версия модуля 3.2.4)? Какая то хитрость с удержанием входа или предварительным созданием нужна?
Базовый 1 в список не подтягивается.
Или как фразу трактовать из хэлпа: NearEnd_SaveSettingsAsCurrentPreset Saves the current camera position as the currently selected preset. If the preset is not defined then this will not be saved.
Не определен где, кем? Понятное дело устанавливаю предварительно номер на входе NearEnd_SelectPreset