Chaque tag d'un lot peut-il porter une adresse différente ?
Oui, et il existe trois voies. Écrire chaque tag individuellement, ce qui est exact et lent. Employer une puce qui recopie son propre identifiant dans le contenu, ce qui fait que des écritures identiques produisent des résultats uniques. Ou accepter une adresse partagée et identifier le tag autrement.
Trois voies
| Voie | Effort par tag | Limite principale |
|---|---|---|
| Écritures individuelles | Élevé, une opération chacune | Lent, et le relevé devient indispensable |
| Miroir d'identifiant | Nul, écriture identique | Exige une puce qui le prévoit |
| Adresse partagée | Nul | Le tag lui-même n'est pas distinguable |
Le miroir, celle qui passe à l'échelle
Certaines puces savent injecter leur propre identifiant d'usine dans le contenu au moment de la lecture. Configurez le miroir une fois, écrivez le même message sur chaque tag, et chacun délivre une adresse différente parce que la puce ajoute ce qui le rend unique.
La conséquence mérite d'être dite clairement : mille tags écrits identiquement en série répétée arrivent malgré tout distinguables les uns des autres sur votre serveur. Toute l'étape d'encodage individuel disparaît.
Deux conditions s'appliquent. La puce doit prendre en charge la fonction, ce qui est une décision d'achat plutôt que quelque chose à ajouter ensuite. Et votre serveur doit savoir traiter une adresse à identifiant ajouté, ce qui est trivial.
L'écriture individuelle
La voie quand le miroir n'est pas disponible, et c'est un autre métier plutôt qu'une version plus lente du même.
Chaque tag demande son propre contenu, saisi ou fourni depuis une liste, et c'est là qu'un encodeur dédié gagne son coût. Le faire à la main sur un téléphone au-delà de quelques dizaines de tags est le moment où apparaissent les erreurs de transcription.
Cela rend aussi le relevé obligatoire. Avec des tags identiques, un relevé perdu est un désagrément ; avec des tags uniques, cela veut dire que vous pouvez changer les destinations sans savoir quel objet physique vous changez.
Choisir entre elles
Si les tags doivent être individuellement distinguables et que la quantité dépasse quelques dizaines, achetez des puces avec miroir. C'est la décision unique qui détermine si la série est une après-midi ou une semaine.
Si l'unicité est un agrément plutôt qu'une exigence, employez une adresse partagée et laissez la page de destination demander ce qu'elle a besoin de savoir. Beaucoup de déploiements qui exigent des tags uniques ne se servent jamais de la distinction.
Et si les tags sont déjà achetés sans miroir et que l'unicité est exigée, un encodeur piloté par une liste est la réponse honnête plutôt qu'un effort héroïque au téléphone.
Questions fréquentes
Le miroir fonctionne-t-il sur tous les téléphones ?
La substitution se produit dans la puce au moment où le contenu est lu : aucun lecteur n'a besoin de prendre quoi que ce soit en charge. Tout téléphone voit l'adresse modifiée sans savoir qu'il s'est passé quelque chose.
Peut-on recopier un compteur plutôt que l'identifiant ?
Les puces qui offrent le miroir permettent souvent aussi le compteur de lectures, ce qui donne une adresse qui change à chaque contact. C'est utile pour détecter un réemploi et c'est une autre finalité que d'identifier le tag.
L'identifiant recopié est-il unique ?
C'est l'identifiant d'usine, censé être unique dans l'allocation d'un fabricant. Ce n'est pas un secret, puisque n'importe qui peut le lire : il identifie plutôt qu'il n'authentifie.
Et si mes puces n'acceptent pas le miroir ?
Écrivez individuellement avec un encodeur piloté par une liste, ou redemandez-vous si l'unicité par tag est réellement nécessaire. Ajouter la fonction après coup n'est pas possible.