Сообщений в теме: 15

[laky]

Добрый день, господа и дамы.

Не знает ли кто решения проблемы использования нормального cp1251 русского в LoadRunner (последних версий)? Не очень забавно каждый раз составлять таблички с кодами всего алфавита, чтобы, скажем, в web_reg_find писать "Text=\xD0\xA2\xD0\xB5\xD0\xBB" и тд.. Также читать из переменных не непонятный набор символов, а в нормальной, отображаемой окошками кодировке, текст. Есть какая-то библиотечная функция lr_convert_string_encoding, но толку от нее никакого. Писать ручками конвертялку в LR явно негигиенично.

Огромное спасибо заранее всем откликнувшимся.

[Dmitry_NJ]

Есть какая-то библиотечная функция lr_convert_string_encoding, но толку от нее никакого.

A чего с ней не так? Не работает?

[laky]

она-то может и работает, но видимо не так, как хотелось бы.
Например:
СÐвенко - utf16
ꇐ냐닐뗐뷐뫐뻐í? - по идее тоже самое в utf8 - то что возвращает lr_convert_string_encoding, но видно, что ф-ия тупо сдвигает каждый байт, а не пару, как должно было.
Неужели никому никогда не приходилось в LR работать с русским? Может патчи какие есть? Я вот сейчас сижу пишу конвертер ручками, потому что идей больше не осталось. Поиск в инете ничего не дал.

[Green]

Посмотрите, что у Вас стоит в настройках операционной системы для non-Unicode программ? (Control Panel -> Regional and Language Options -> Advanced -> Language for non-Unicode programs)

Там нужно проставить Russian.

В следующем разделе - Code page conversion tables - проверте, что бы галочка стояла для таблицы 20866 (Russian - KOI8).

Надеюсь, это поможет.

[laky]

2Green:
спасибо за совет, но, чувствуется, вам не приходилось с этим сталкиваться лично эти настройки как-то вяло влияют на поведение LR, да они уже были в системе.

[Green]

2Green:
спасибо за совет, но, чувствуется, вам не приходилось с этим сталкиваться лично   эти настройки как-то вяло влияют на поведение LR, да они уже были в системе.

На прошлой неделе я занимался настройкой Лоад Раннера для нового сотрудника. Проблема отображения русских букв была решена описанным выше способом.

Но мы все же решили немного поэксперементировать.

При записи скрипта в открывшемся браузере мы поменяли кодировку с Windows-1251 на KOI8-U. После окончания записи, в режиме view tree страницы отображались в кодировке KOI8, но при этом ответ сервера был правильный и русские буквы в теле сообщения отображались корректно.

Что интересно, другие скрипты так же стали отображаться в кодировке KOI8 и найти переключения режима кодировки в настройках ЛР не удалось. Пришлось вновь записать скрипт, а в момент его записи в браузере (IE)переключить кодировку в Windows 1251. После этого все пришло в норму и русские буквы вновь стали отображаться корректно.

[laky]

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

[Green]

проблема не в отображении в самом LR (с этим все хорошо), а с передачей в качестве параметров функциям русского текста, равно как и получения его из переменных..

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

[swallow]

У меня такая же проблема. laky, вы ее решили? Если да, то каким образом? Очень напрягает пользоваться этим жутким "алфавитом"...

[laky]

перекодировочной таблицей :))
составил табличку, написал ф-ию перевода кириллицы в 2х байтный юникод и обратно, каждый раз при формировании строчной переменной либо при декодировании полученных данных вызывается данная ф-ия. хорошего мало - значительное падение производительности при выполнении скриптов. будет время - перепишу это на Сях: попробую запихнуть в дллку и вызывать напрямую (вроде такой механизм есть в ЛР, но еще не разбирался)

[swallow]

Ясно... то есть нормального решения видимо нет.

[Dmitry_NJ]

Может нормальное решение и существует, но для этого надо дергать саппорт. Видимо лень.

[laky]

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

спасибо.

[Dmitry_NJ]

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

Past perfromance is no guarantee of future results.

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

На суппорт можно не рассчитывать если ваша компания не платит деньги и не поддерживает в актуальном состоянии свой maintenance contract. А каким модулем LR вы при этом пользуетесь абсолютно не важно. Плохо то, что вы даже не знали есть ли у вас возможность обращаться в суппорт или нет.

[laky]

Past perfromance is no guarantee of future results.

agree but there was no time

На суппорт можно не рассчитывать если ваша компания не платит деньги и не поддерживает в актуальном состоянии свой maintenance contract. А каким модулем LR вы при этом пользуетесь абсолютно не важно. Плохо то, что вы даже не знали есть ли у вас возможность обращаться в суппорт или нет.

vugen is not licensed itself. нелицензионное по компания не использует. на тот момент была такая ситуация, что нужно было быстро сделать. ранее был опыт общения и с меркьюровским суппортом в штатах, также не надеялся особо на форум.

с уважением.

[Сергей]

Интересно, как сейчас решается вопрос?