Barcode Scanner Emulator
L'émulation clavier HID expliquée
Le keyboard wedge est le mode de fonctionnement par défaut de l'immense majorité des lecteurs de codes-barres. Ce guide explique ce que c'est, comment cela fonctionne au niveau USB et ce que cela implique pour tester votre application.
Qu'est-ce qu'un keyboard wedge ?
Le terme vient d'anciens lecteurs sur port série qui étaient littéralement « intercalés » entre un clavier et le port de l'ordinateur, interceptant le signal du clavier et y injectant les caractères lus. Les lecteurs modernes n'ont plus besoin de cette intercalation physique : l'expression désigne désormais tout lecteur qui présente les données lues comme si elles venaient d'un clavier, quel que soit le type de connexion.
USB HID et émulation de clavier
L'USB définit une classe Human Interface Device (HID) spécialement pour les claviers, les souris et les périphériques de saisie similaires. Quand un lecteur s'énumère en USB comme clavier HID, le système d'exploitation charge son pilote clavier générique intégré : aucun pilote spécifique au lecteur n'est nécessaire. Le micrologiciel du lecteur convertit chaque caractère décodé en keycode HID qu'un clavier physique enverrait, et les rapports sont livrés par le même mécanisme de transfert par interruption que n'importe quel clavier USB.
Comment votre application voit la saisie du lecteur
Rafale rapide de frappes contre frappe humaine : le lecteur envoie toute la charge utile comme une suite rapide de paires keydown/keyup, en général en moins d'une seconde, quelle que soit la longueur du code-barres.
Aucun événement souris : les lecteurs en mode clavier HID ne génèrent jamais d'événements de pointeur, de clic ou de focus. Si votre champ n'a pas le focus au moment de la lecture, la saisie est perdue ou part vers l'élément qui a le focus.
Aucun événement de collage : comme les données arrivent sous forme de frappes individuelles et non d'une opération du presse-papiers, les gestionnaires de l'événement paste ne voient pas la saisie du lecteur, et les masques de saisie qui n'écoutent que paste la manquent silencieusement.
Problèmes de disposition de clavier
Pourquoi de mauvais caractères apparaissent : le lecteur associe les caractères décodés à des keycodes HID selon sa propre disposition de clavier configurée. Si cette disposition ne correspond pas à celle du système d'exploitation, les caractères peuvent être transposés. Un symptôme classique est que des chiffres ou de la ponctuation sont lus comme le mauvais caractère entre des systèmes QWERTY et AZERTY.
Décalage de paramètres régionaux : il s'agit d'un problème de configuration côté lecteur, pas d'un bug logiciel. La plupart des lecteurs permettent de changer les paramètres régionaux grâce à des codes-barres de configuration imprimés dans leur manuel, et la correction consiste à reprogrammer le lecteur pour qu'il corresponde aux paramètres régionaux du système, pas à modifier le code de l'application.
Préfixes et suffixes
Les lecteurs prennent en général en charge des séquences de préfixe et de suffixe configurables autour de la charge utile. Les suffixes les plus courants sont ENTER (CR, 0x0D), TAB (0x09) et, parfois, une paire CR+LF complète. Les préfixes sont moins fréquents, mais servent parfois à orienter les lectures vers des champs précis dans d'anciennes applications terminal.
Limites pour les tests dans le navigateur
Un navigateur ne voit pas les paquets USB HID bruts, ne peut pas énumérer les périphériques HID connectés comme des lecteurs en particulier (en dehors de l'API WebHID, par laquelle la plupart des lecteurs n'exposent pas leurs données) et ne peut pas distinguer un lecteur en mode clavier HID d'un vrai clavier. Seuls les événements clavier visibles par le navigateur (keydown, keyup, keypress) sont accessibles à JavaScript, et ce sont exactement ceux qu'inspectent les outils de ce site.
Pour aller plus loin
Utilisez le testeur d'événements clavier pour inspecter les événements clavier bruts, ou lisez le guide Suffixes ENTER et TAB pour le détail de la configuration des suffixes.