Quelle mémoire du tag le surcoût NDEF consomme-t-il ?
Assez pour compter sur un petit tag et pas assez pour inquiéter sur un grand. De la mémoire part dans la structure du tag, dans le conteneur NDEF, et dans un en-tête sur chaque enregistrement, le tout déduit avant que votre contenu ne commence.
Trois déductions, dans l'ordre
D'abord, le tag réserve de la mémoire pour lui-même : l'identifiant, les données du fabricant, les bits de verrouillage et le conteneur de capacité qui décrit l'organisation aux lecteurs. Rien de tout cela ne vous est disponible et rien n'est optionnel.
Ensuite, le conteneur NDEF ajoute son propre encadrement pour qu'un lecteur sache où le message commence et quelle est sa longueur.
Enfin, chaque enregistrement à l'intérieur du message porte un en-tête avant son contenu.
Ce qui parvient à votre contenu est la capacité annoncée moins ces trois postes, et c'est pourquoi un tag vendu avec une capacité affichée rapporte nettement moins d'espace libre dans un outil.
Chaque enregistrement coûte de nouveau
L'en-tête est par enregistrement et non par message. Répartir le même contenu sur trois enregistrements coûte donc trois en-têtes au lieu d'un, et l'écart est significatif rapporté à un petit tag.
C'est l'une des raisons pratiques de préférer un enregistrement unique. L'autre est le temps de lecture, ces en-têtes étant des octets de plus à lire, bloc par bloc, sur un canal où un seul côté parle à la fois.
Quand cela cesse de compter
Vite, à mesure que la capacité croît. Sur un tag qui a de la place pour quelques centaines d'octets de contenu, un en-tête de quelques octets est du bruit. Sur les plus petits tags courants, où vous logez une adresse dans un espace très serré, ce même en-tête peut faire la différence entre une écriture qui passe et une écriture qui échoue.
La conséquence est que le surcoût est un problème de petit tag spécifiquement. Si un déploiement se bat pour des octets, la réponse est d'ordinaire un tag plus grand plutôt qu'un encodage plus astucieux.
Travailler avec de la marge
Lisez l'espace libre avec un outil plutôt que de le calculer d'après l'emballage. Les outils rapportent ce qui est réellement disponible, et ce nombre est le seul sur lequel bâtir.
Laissez ensuite de la place. Le contenu grossit : une adresse gagne un paramètre de suivi, un nom gagne une initiale, une campagne gagne une seconde langue. Spécifier un tag qui loge votre contenu au caractère près aujourd'hui, c'est spécifier un tag qu'il faudra remplacer.
Et rappelez-vous qu'une adresse peut être raccourcie au serveur plutôt que sur le tag. Passer d'une adresse longue à une adresse courte est le gain de capacité le moins cher qui soit et il ne coûte rien par tag.
Questions fréquentes
Pourquoi mon tag annonce-t-il moins d'espace libre que la capacité affichée ?
Parce que la structure, le conteneur et les en-têtes d'enregistrements sont tous déduits d'abord. L'écart est normal et attendu, et comparer les espaces libres plutôt que les capacités annoncées est la façon de comparer des tags.
Une adresse plus courte aide-t-elle vraiment ?
Sur un petit tag, oui et sensiblement. Chaque caractère de l'adresse est un octet de contenu, et raccourcir l'adresse suffit souvent à faire passer une écriture qui échouait.
Le surcoût est-il le même sur tous les types de tags ?
Non, la structure différant selon le type de tag et la famille de puce. Deux tags de capacité annoncée identique peuvent offrir des quantités d'espace utilisable différentes.
Peut-on éviter NDEF pour économiser le surcoût ?
Techniquement oui, et cela vous coûte l'interopérabilité. Un contenu hors NDEF n'est lisible que par un logiciel qui en connaît l'organisation, ce qui annule l'intérêt de tout ce qui est lu par le téléphone d'un tiers.