›

Code barre et champ en base

muqaddarmuqaddar Administrateur
mars 2012 modifié dans API AppKit #1
Je sais pas si il y a un crack des codes-barres ici, mais j'aimerais quelques précisions (je dois dire que c'est quelque chose qui m'a jamais intéressé). Je suis allé un peu me balader sur Wikipedia qui a éclairé ma lanterne.



Bon apparemment, on distingue 2 types de code-barres (1D et 2D).



1) Dans les 1D, j'avais prévu un champ UPC (CUP). Or j'ai compris que CPU faisait partie des codes EAN. Dans ce cas, mon champ devrait plutôt s'appeler EAN que CUP... (apparemment 13 chiffres maximum)



2) J'ai remarqué que les QRCode (2D) sont de plus en plus utilisés. Ils peuvent avoir environ 8000 caractères. Diable. Il semble exclu de les gérer en base de données non (en local sur device) ?



3) Est-ce que le système 2D va tuer le système 1D dans le futur ?



4) Juste une remarque: il existe pas mal d'API de code barres pour iOS SDK il me semble.

Réponses

  • DrakenDraken Membre
    #2
    'muqaddar' a écrit:


    2) J'ai remarqué que les QRCode (2D) sont de plus en plus utilisés. Ils peuvent avoir environ 8000 caractères.


    Oo les possibilités sont impressionnantes ! *pense à  refaire sa carte de visite *
  • KubernanKubernan Membre
    mars 2012 modifié #3
    Je pense que ça dépend à  quel genre de produit se rapportent tes codes barres. Pour la grande distribution, la plupart des procédures informatiques utilisent l'EAN 13 (il y a aussi l'EAN 8), stocké tel que. Ce code à  encore de beaux jours devant lui.



    Le QRCode je ne connais pas trop, sauf à  l'avoir vu apparaà®tre dans un jeu télé :-)
  • CéroceCéroce Membre, Modérateur
    mars 2012 modifié #4
    'muqaddar' a écrit:


    Bon apparemment, on distingue 2 types de code-barres (1D et 2D).


    Pas vraiment, un code-barre est forcément 1D. Un QRcode n'est pas un code-barre, même si le principe est similaire.


    'muqaddar' a écrit:


    1) Dans les 1D, j'avais prévu un champ UPC (CUP). Or j'ai compris que CPU faisait partie des codes EAN. Dans ce cas, mon champ devrait plutôt s'appeler EAN que CUP... (apparemment 13 chiffres maximum)


    Oui. Je ne suis pas allé relire l'article de Wikipédia, mais de mémoire celui qui est utilisé pour les biens de consommation courante est l'EAN 13. Il me semble que pour certains produits (livres ?), ça peut être un autre standard.


    'muqaddar' a écrit:


    2) J'ai remarqué que les QRCode (2D) sont de plus en plus utilisés. Ils peuvent avoir environ 8000 caractères. Diable. Il semble exclu de les gérer en base de données non ?


    ça reste du binaire. Si le QRCode mesure 32 x 32 cases, ça fait 1024 bits, soient 128 caractères.

    Les très gros QRCodes existent par ex. dans l'industrie pour les inventaires, mais ça reste rare dans notre petit monde, où il servent le plus souvent à  encoder des URL.


    'muqaddar' a écrit:


    3) Est-ce que le système 2D va tuer le système 1D dans le futur ?


    Non. Ou alors un futur lointain. Compte 20 ans.

    C'est bien simple, il n'existe pas de standard pour identifier les produits pour les QRCodes, et on ne va pas changer toutes les caisses enregistreuses s'il n'y a pas de besoin. Même en imaginant que les codes EAN 13 soient trop restreints, je pense qu'on commencerait par les allonger.



    J'ai lu une blague qui disait à  peu près: "Hé les marketeux, vous connaissez quelqu'un qui utilise les QRCodes, hormis d'autres marketeux"?

    Quasiment le seul endroit où tu peux voir des QRCode sont sur les affiches de pub. Et je n'ai encore vu personne scanner un code alors que les utilisateurs de smartphones sont très nombreux dans le métro. Bref, ça a fait un bide.
  • muqaddarmuqaddar Administrateur
    #5
    Merci pour toutes ces précisions.



    Je pense qu'un des avantages du QRCode, c'est la place qu'il prend, par exemple, sur une étiquette d'une bouteille de vin où il n'y a pas beaucoup de place. image/wink.png' class='bbc_emoticon' alt=';)' /> (du moins, ça dépend la matrice choisie...)



    Sinon, là , où je voulais en venir, c'est qu'un produit X peut avoir une identité 1D et 2D, ce n'est pas l'un ou l'autre.



    Bon, merci en tout cas, je vais me contenter d'un champ EAN pour l'instant.
  • KubernanKubernan Membre
    #6
    'muqaddar' a écrit:


    Je pense qu'un des avantages du QRCode, c'est la place qu'il prend, par exemple, sur une étiquette d'une bouteille de vin où il n'y a pas beaucoup de place. image/wink.png' class='bbc_emoticon' alt=';)' /> (du moins, ça dépend la matrice choisie...)




    Le code EAN 8 prend moins de place, il peut être choisi à  la place de l'EAN 13.
  • muqaddarmuqaddar Administrateur
    #7
    OK. Merci pour l'info.
  • MonsieurPaulMonsieurPaul Membre
    mars 2012 modifié #8
    Les codes QR, je connais un peu, c'est ma première app sur le Mac App Store: QRBeam image/wink.png' class='bbc_emoticon' alt=';)' />



    8000 caractères c'est grandement exagéré, le max que j'ai pu mettre sur un code QR c'est environ 3000 caractères avec le plus faible niveau de correction d'erreur. Sur mon app j'ai mis une limite de 2400 à  800 caractères suivant le niveau de correction d'erreur. En fait, c'est la résolution de l'appareil photo utilisé pour décoder le code qui va être déterminant. En tout cas, c'est largement suffisant pour transmettre une URL ou une vCard (sans la photo).



    Un des avantages des codes QR c'est aussi qu'ils peuvent être lus dans n'importe quel sens. Souvent, les programmes de lecteurs de codes-barres obligent à  bien aligner le code barre avec des repères sur l'écran, pour les codes QR, on peut les flasher n'importe comment, et avec un niveau de correction d'erreur élevé, on peut mettre un peu n'importe quoi dedans.



    Pour les créer j'ai utilisé une librairie C : libqrencode
Connectez-vous ou Inscrivez-vous pour répondre.