Поводом написания этой маленькой статьи послужила странная ситуация, сложившаяся с настройкой сканеров штрих кода для работы с маркировкой в режиме именно клавиатуры.
Я думаю многие уже бились головой об стену не понимая - как настроить сканер для корректной работы с маркировкой в режиме клавиатуры.
Под корректной работой понимается, что считанный сканером код, сначала должен хотя бы распознаваться корректно онлайн сервером ОФД и конечно ещё сервером честного знака (это уже при включенном разрешительном режиме).
Но возможно это только, если в коде присутствуют байты 0х1D.Так изначально задуман тип кода маркировки Datamatrix.
Суть проблемы в том, что в коде маркировки по формату Datamatrix присутствуют обычно 2 разделителя со значением 0x1d или их ещё называют GS.
0x1D это управляющие символы, как они ещё применялись со времён программирования на перфокартах. Проблема в том, что они отсутствуют на физической клавиатуре визуально, располагаются в самом начале таблицы ASCII, и не имеют символьного представления. То есть в текстовом редакторе вы их просто так не увидите.
Да, надо отметить, что развлекаемся мы со сканерами мы в Виндоус. На Винде, как я понял, USB драйвер клавиатуры всегда передавал сканкоды в соответствии с таблицей XT стандарта, где за каждой клавишей закреплёно конкретное значение сканкода.
Надо понимать, что USB драйвер всегда передает байты, и всегда от конкретной клавиши идёт одно конкретное значение (байт если хотите).
Так вот далее именно операционная система, настройки конкретного пользователя интерпретируют эти байты в соответствие с выбранной раскладкой клавиатуры (или локалью) и у нас появляются разные языки русский, английский и т.д. Но изначально из канала USB байты одни те же поступают.
Теперь о сканере штрих кода. Сканер также как и человек с клавиатуры передает те же байты, как бы нажимая клавиши и передавая сканкоды..
Но как ему передать символ GS?
Передать как он есть GS и есть 0x01.
Заменить его на код клавиши F8.
Заменить на один или комбинацию нескольких из других символов.
Все эти варианты могут вполне себе работать, так как сканеры имеют специальные настроечные штрих-коды для замены передаваемых символов на другие значения. Но вот развлечение это очень себе не интересное, так как помнить как настраивается конкретный сканер, потом настраивать его по инструкции, потом может удаленно диктовать продавцу через анидеск какой штрих код считать для этого, все это головная боль, которая никому не нужна, но так сложилось исторически, что она есть.
Теперь хочу сказать по поводу первого варианта, что если оставить GS как есть и ничего не менять — это нормальный режим работы, во всяком случае для USB клавиатуры, все будет нормально передаваться и через RDP, и при работе через анидеск и поправьте меня если у кого были с этим какие‑то проблемы.
И можно так все было и оставить производителями сканеров штрих кода. Но как‑то так получилось, что по умолчанию они зачем‑то решили заменять GS на F8. Зачем? Наверное хотели как лучше...
А теперь попробуйте считать в блокноте клавишу F8, конечно вы не увидите ничего, как впрочем и символ GS вы тоже просто так не увидите.
И вот вы имеете последовательность от сканера, где GS заменён на F8, который вы никак не видите, и вы пихаете этот код для проверки серверу ОФД и конечно вы получаете отказ и очень начинаете переживать по поводу почему ничего не работает...
По факту вам надо было бы, чтобы ваша товароучетка заменила обратно F8 на GS. Но для начала надо знать, что происходит на уровне сканкодов.
Мы сделали небольшую программку на Qt (С++) для считывания данных от сканера в блокнот (на основе QPlainTextEdit) и включили лог через событие OnKeyPress.
Да и конечно еще мы задали сразу локаль Latin-1, понятно зачем.
И только теперь на самом деле мы поняли суть проблемы и самое главное как ее решать. На наш взляд разумнее не парится с настройкой сканеров каким-то особым образом. Лучше использовать настройки по умолчанию с одним небольшим «но» — надо смотреть в логе, что передается перед символами '91' и '92' и далее в товароучетке (конечно если там такая возможность есть) переопределять обратно, то есть восстанавливать F8 в GS.
Надо отметить, что если вы используете сканер в режиме COM порта, то конечно проблем с передачей GS у вас не будет изначально. Точнее символ GS будет передаваться как есть , без замены. Но очень многие десктопные приложения не поддерживают вариант COM порта.
К тому же есть большая коллекция программ, которые выполняются в облаке, то есть пользователь работает через браузер и теперь как из этой облачной программы получить доступ в COM порту компьютера? Правильно — только написать и запустить свой сервер на этом ПК. А вот режим клавиатуры всегда работает из коробки без дополнительных проблем.
Я не претендую на оригинальность подхода, просто потерял много времени у одного клиента пока не понял, что их товароучетка работать с маркировкой не будет «от слова совсем» по причине, что разработчик не понимает нюансы использования сканеров в режиме клавиатуры, при этом и поставщик сканеров удивленно говорил, что у всех все работает маркировка и разработчик товароучетки удивлялся, у всех работает, только у вас почему‑то нет...
Бесплатная программка с открытым исходным кодом на С++ для тестирования сканеров barcode_scanner_kb_test.exe если, что здесь (под виндоус).
https://rutube.ru/video/1f8b795ee6790f45b352da9a237ecfa8/?r=a/
Надеюсь хабровчане поделятся в комментариях своим опытом решения подобными проблемами со сканерами.
Ещё забыл сказать об интересной проблеме, связанной с просмотром считанных кодов маркировки в текстовых редакторах типа nodepad++ и вообще в любых других. Дело в том, что в зависимости от скорости поступления считанных символом от операционной системы, вы возможно получите разные результаты. То есть например один сканер считает одни символы, а более быстрый (или настроенный на более быструю передачу) другие символы в итоге. На самом деле текстовый редактор может банально не успевать обрабатывать поступающие символы То есть верить результату полученному в текстовом редакторе нельзя, чаще он будет правильным, но что хуже всего иногда результат будет не корректным. Так у нас было например со сканером миндео 6600, результат в текстовом редакторе получали без GS символов (хотя они там были точно), а почему - а потому, что он слишком быстрый.
Таким образом для проверки сканеров в режиме клавиатуры используйте только специальные программы, свои или нашу например, указанную по ссылке выше, где отслеживаются именно сканкоды, поступающие от ОС.
PS: Решил добавить случай из жизни, связанный с настройкой сканеров. Речь например от Миндео 6600. Все рекомендуют: быстрый, хорошо распознает плохие коды. По умолчанию настроен так, что заменяет GS на F12 и все хорошо работает в релизе. Но кто бы мог подумать, что в дебаге Qt при нажатии банально F12 (в поле ввода кода) приложение вылетает. Оказывается по клавише F12 в MSVS вход в отладчик, который крешится. Это я к тому, что считывая сканером в режиме клавиатуры штрих код нельзя быть уверенным, что в текущем приложении не переопределена какая-то из считываемых клавиш или комбинация клавиш таким образом, что у вас получится не предсказуемый вариант, например падение, перезагрузка, все что угодно может быть и зависеть это может от конкретного компьютера, на котором запускается приложение.
