Unicode
#1
Отправлено 05 декабря 2005 - 13:11
Не знает ли кто решения проблемы использования нормального cp1251 русского в LoadRunner (последних версий)? Не очень забавно каждый раз составлять таблички с кодами всего алфавита, чтобы, скажем, в web_reg_find писать "Text=\xD0\xA2\xD0\xB5\xD0\xBB" и тд.. Также читать из переменных не непонятный набор символов, а в нормальной, отображаемой окошками кодировке, текст. Есть какая-то библиотечная функция lr_convert_string_encoding, но толку от нее никакого. Писать ручками конвертялку в LR явно негигиенично.
Огромное спасибо заранее всем откликнувшимся.
#2
Отправлено 06 декабря 2005 - 04:05
A чего с ней не так? Не работает?Есть какая-то библиотечная функция lr_convert_string_encoding, но толку от нее никакого.
#3
Отправлено 06 декабря 2005 - 09:32
Например:
СÐвенко - utf16
ê‡ëƒë‹ë—ë·ë«ë»í? - по идее тоже самое в utf8 - то что возвращает lr_convert_string_encoding, но видно, что ф-ия тупо сдвигает каждый байт, а не пару, как должно было.
Неужели никому никогда не приходилось в LR работать с русским? Может патчи какие есть? Я вот сейчас сижу пишу конвертер ручками, потому что идей больше не осталось. Поиск в инете ничего не дал.
#4
Отправлено 06 декабря 2005 - 14:52
Там нужно проставить Russian.
В следующем разделе - Code page conversion tables - проверте, что бы галочка стояла для таблицы 20866 (Russian - KOI8).
Надеюсь, это поможет.
#5
Отправлено 06 декабря 2005 - 17:32
спасибо за совет, но, чувствуется, вам не приходилось с этим сталкиваться лично эти настройки как-то вяло влияют на поведение LR, да они уже были в системе.
#6
Отправлено 07 декабря 2005 - 09:06
2Green:
спасибо за совет, но, чувствуется, вам не приходилось с этим сталкиваться лично эти настройки как-то вяло влияют на поведение LR, да они уже были в системе.
На прошлой неделе я занимался настройкой Лоад Раннера для нового сотрудника. Проблема отображения русских букв была решена описанным выше способом.
Но мы все же решили немного поэксперементировать.
При записи скрипта в открывшемся браузере мы поменяли кодировку с Windows-1251 на KOI8-U. После окончания записи, в режиме view tree страницы отображались в кодировке KOI8, но при этом ответ сервера был правильный и русские буквы в теле сообщения отображались корректно.
Что интересно, другие скрипты так же стали отображаться в кодировке KOI8 и найти переключения режима кодировки в настройках ЛР не удалось. Пришлось вновь записать скрипт, а в момент его записи в браузере (IE)переключить кодировку в Windows 1251. После этого все пришло в норму и русские буквы вновь стали отображаться корректно.
#7
Отправлено 07 декабря 2005 - 14:33
#8
Отправлено 12 декабря 2005 - 07:20
проблема не в отображении в самом LR (с этим все хорошо), а с передачей в качестве параметров функциям русского текста, равно как и получения его из переменных..
Теперь проблема стала понятнее. Действительно, раньше с ней сталкиваться не приходилось - все проекты англоязычные. Надо будет покрутить русскоязычный ресурс.
#9
Отправлено 27 декабря 2005 - 10:07
#10
Отправлено 23 января 2006 - 16:49
составил табличку, написал ф-ию перевода кириллицы в 2х байтный юникод и обратно, каждый раз при формировании строчной переменной либо при декодировании полученных данных вызывается данная ф-ия. хорошего мало - значительное падение производительности при выполнении скриптов. будет время - перепишу это на Сях: попробую запихнуть в дллку и вызывать напрямую (вроде такой механизм есть в ЛР, но еще не разбирался)
#11
Отправлено 02 февраля 2006 - 12:52
#12
Отправлено 02 февраля 2006 - 23:57
#13
Отправлено 14 апреля 2006 - 07:14
спасибо.
#14
Отправлено 14 апреля 2006 - 15:48
Past perfromance is no guarantee of future results.но опыт общения с разными суппортами не позволял в очередной раз тратить на это время.
На суппорт можно не рассчитывать если ваша компания не платит деньги и не поддерживает в актуальном состоянии свой maintenance contract. А каким модулем LR вы при этом пользуетесь абсолютно не важно. Плохо то, что вы даже не знали есть ли у вас возможность обращаться в суппорт или нет.к тому же в тот момент я пользовался только VUGen, который не лицензируется, так что на суппорт, наверное, можно было и не рассчитывать.
#15
Отправлено 17 апреля 2006 - 18:24
agree but there was no timePast perfromance is no guarantee of future results.
vugen is not licensed itself. нелицензионное по компания не использует. на тот момент была такая ситуация, что нужно было быстро сделать. ранее был опыт общения и с меркьюровским суппортом в штатах, также не надеялся особо на форум.На суппорт можно не рассчитывать если ваша компания не платит деньги и не поддерживает в актуальном состоянии свой maintenance contract. А каким модулем LR вы при этом пользуетесь абсолютно не важно. Плохо то, что вы даже не знали есть ли у вас возможность обращаться в суппорт или нет.
с уважением.
#16
Отправлено 16 марта 2015 - 13:43
Интересно, как сейчас решается вопрос?
"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных