Заметил, довольно многие разработчики шаблонов применяют массу приемов для обработки распознанной капчи перед ее отправлением в запрос. Лично я не любитель захламлять код ненужными условиями. При том что по факту достаточно сравнить распознанную капчу с предлагаемыми ответами.
Разберем на конкретном примере применение универсального метода:
[READ_FILE_ALL][file/$MODEL_NAME_temp.txt] {{читаем файл с вариантами ответа и токенами к каждому из них}}
[REG_PARSE][Verify\('(\w+)'\); false;">capca<] {{парсим данные файла на наличие ответа для capca, где capca - это наш ответ полученный в результате распознавания}}
[IF][$bool=0]
[LOG_DISPLAY][Капчи не совпадают. Начинаем заново | $TIME]
[GO_TO_BREAK_POINT][surfing]
[ENDIF]
[VAR][final][$2]
[CLEAR_BUFFER]
В данном примере в файле с названием шаблона хранятся спасренные предварительно варианты ответа вместе с токенами присвоенными каждому ответу. В файле эта информация хранится в виде:
Verify('токен для ответа gba'); false;">gba<
токен для ответа gba
Verify('токен для ответа vbn); false;">vbn<
токен для ответа vbn
Verify('токен для ответа zhu'); false;">zhu<
и т.д.
После распознавания капчи считываем данные из файла. Парсим на наличие токена для нашей capca. Если токена не найдено - переходим к условию с переходом в точку surfing. Где surfing - это начало. Если токен для нашей capca найден - то записываем его в VAR под названием final, так как токен в нашем случае находится в ответе парса во второй строке то берем токен из $2. Далее всовываем токен (final) куда нам нужно.
По такому же принципу проводится проверка на совпадение, когда варианты ответа идут без токена к ним: парсим ответы, сохраняем в файл или как VAR, распознаем капчу, сравниваем ответ с имеющимися ответами, совпадения нет - начинаем заново.
На этом всё. Нет нужды городить лишние проверки типа: состоит ли ответ капчи из цифр, или сколько символов в ответ капчи и т.д и т.п. Если капча плохо распознается - это проблема обработки самой картинки.
