search

lovasoa / sanipasse

Vérificateur de passe sanitaire open-source
https://sanipasse.ophir.dev
GNU Affero General Public License v3.0
173 stars 40 forks source link

Problématique 2D-DOC à partir d'un scanner de code barre #48

Closed mouuuut closed 3 years ago

mouuuut commented 3 years ago

Bonjour,

Tentant de mettre en place une borne équipée d'une tête de lecture Datalogic Magellan 1500i, je rencontre un souci de lecture des 2D-DOC, aucun souci pour les QR-Code.

En effet, malgré un paramétrage complet, tout 2D-DOC scanné depuis la douchette me donne un résultat invalide ("certificat invalide"), là où le scan du même 2D-DOC depuis une caméra est OK.

Après analyse des données remontées par les deux méthodes, une seule différence ; une balise de contrôle est interprétée par la caméra mais pas la douchette. Les autres balises sont interprétées dans les deux cas.

D'autres personnes ont-elles rencontré ce souci ?

Merci d'avance, et bon courage pendant cette période encore difficile.

lovasoa commented 3 years ago

Bonjour, Les codes 2D-DOC contiennent des caractères ASCII non imprimable. Je suppose que votre douchette a un bug et ne rapporte pas bien ces caractères. Pour vérifier, vous pouvez utiliser un service comme https://www.soscisurvey.de/tools/view-chars.php pour vérifier que tous les caractères non imprimables du code sont bien lus par la douchette.

mouuuut commented 3 years ago

Bonjour, merci pour votre retour rapide.

C'est ce vers quoi je suis allé, et effectivement la douchette n'envoyait aucun caractère de contrôle, je l'ai constaté en inspectant les lignes interprétées par voie vidéo et voie douchette.

J'ai donc creusé dans la notice de paramétrage, suis arrivé à activer des balises de contrôle mais ce n'est pas encore ça...

Des balises (Group Separator) sont désormais interprétées, mais une balise ( ASCII Code 31) ne l'est toujours pas...pièce jointe à l'appui, montrant la différence entre interprétation Vidéo et Douchette.

Merci en tout cas pour votre retour, je continue de chercher et vous ferai part de mes résultats.

Cordialement.

Le mer. 11 août 2021 à 10:58, Ophir LOJKINE @.***> a écrit :

Bonjour, Les codes 2D-DOC contiennent des caractères ASCII non imprimable. Je suppose que votre douchette a un bug et ne rapporte pas bien ces caractères. Pour vérifier, vous pouvez utiliser un service comme https://www.soscisurvey.de/tools/view-chars.php pour vérifier que tous les caractères non imprimables du code sont bien lus par la douchette.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lovasoa/sanipasse/issues/48#issuecomment-896637546, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN6Q4X4IHA6S6JHYYPYM7A3T4I3UNANCNFSM5B5YRR3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

lovasoa commented 3 years ago

Je ferme l'issue parce que ce n'est pas un bug de sanipasse, mais je laisse les commentaires ouverts.

N'hésitez pas à commenter ici ce que vous trouvez, et la manière dont vous paramétrez la douchette pour aider les éventuels autres utilisateurs affectés par le même problème.

mouuuut commented 3 years ago

Bonjour,

Suite et fin, c'est effectivement le modèle de douchette (Datalogic Magellan 1500i) qui n'est actuellement pas en mesure d'interpréter le code ASCII31...

Une solution de contournement proposée par Datalogic : substitution du caractère par un autre, imprimable, faisant office de séparateur.

N'étant par développeur je botte en touche, cela implique d'adapter votre code...mes compétences sont insuffisantes...

On sait au moins quelle est l'origine.

Merci encore, et bonne continuation!

lovasoa commented 3 years ago

Si je comprends bien, ce qu'ils proposent, c'est de changer les spécifications du format 2DDOC de l'agence des titres sécurisés, pas de modifier l'interprétation du résultat...

Pour cela je ne peux rien faire, et puisque c'est leur matériel qui est en faute, je pense que vous pouvez demander à être remboursé.

mouuuut commented 3 years ago

Ce n'est pas au niveau du 2D Doc qu'une modification aurait lieu.

La douchette détecte le caractère en question mais ne le transmets pas. Cela sous entend que la lecture comprend bien le caractère. Datalogic s'en est rendu compte en le substituant par un @, qui pour le coup est imprimable et peut donc être exploité en tant que séparateur. Cela interviendrait comme étape intermédiaire.

Dans le fichier 2ddoc.ts on remarque que ce fameux caractère sert bien de séparateur, dans la constitution de TOTAL_REGEX (\x1F). L'idée du contructeur était de le substituer par un caractère exploitable. Le tout est que le code identifie non plus le caractère initial mais celui de substituion (un caractère que l'on ne retrouve pas dans le 2DDOC lui-même, exemple le @ ou €...

J'espère avoir été plus précis.

Le ven. 13 août 2021 à 13:46, Ophir LOJKINE @.***> a écrit :

Si je comprends bien, ce qu'ils proposent, c'est de changer les spécifications du format 2DDOC de l'agence des titres sécurisés, pas de modifier l'interprétation du résultat...

Pour cela je ne peux rien faire, et puisque c'est leur matériel qui est en faute, je pense que vous pouvez demander à être remboursé.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lovasoa/sanipasse/issues/48#issuecomment-898400392, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN6Q4X3DQ55D72JAO3WN5MLT4UAX3ANCNFSM5B5YRR3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

lovasoa commented 3 years ago

Datalogic s'en est rendu compte en le substituant par un @, qui pour le coup est imprimable et peut donc être exploité en tant que séparateur. Cela interviendrait comme étape intermédiaire.

Je ne suis pas sûr de comprendre. Ils ont fait une mise à jour du firmware de leur lecteur pour qu'il transmette un @ au lieu du code ASCII 31 ? Mais dans ce cas pourquoi ne pas faire une mise à jour qui corrige juste leur bug ?

Ou bien ils ont généré un autre code qui contenait un @ à la place du caractère non imprimable ? Dans ce cas, c'est un peu inutile, on ne va pas modifier les codes déjà imprimés...