Qu'est-ce que NDEF, et pourquoi tout tag lisible l'utilise-t-il ?
NDEF, le format d'échange de données NFC, est un petit conteneur qui dit ce que contient un tag en même temps qu'il le contient. Un tag écrit en NDEF est compris par tout lecteur conforme, y compris celui intégré au système d'exploitation. Un tag écrit sans lui contient des octets que seul son propre logiciel sait interpréter.
Le problème que NDEF résout
Un tag est un petit bloc de mémoire. Sans convention, les octets qu'il contient n'ont aucun sens pour qui ne les a pas écrits : est-ce une adresse web, un relevé de température, un identifiant, ou du bruit ?
NDEF fournit cette convention. Il enveloppe le contenu dans une structure qui déclare ce qu'est ce contenu, de sorte qu'un lecteur qui n'a jamais vu ce tag puisse malgré tout décider quoi en faire.
La forme d'un message
Un message NDEF est une suite d'enregistrements. Chacun porte un petit en-tête décrivant de quelle sorte de chose il s'agit et comment interpréter ce type, suivi du contenu lui-même.
Cet en-tête est tout l'enjeu. C'est lui qui permet à un téléphone de voir un enregistrement et de conclure « ceci est une adresse web » plutôt que « voici quarante octets ». Les enregistrements de types bien connus sont pris en charge par le système d'exploitation sans qu'aucune application n'intervienne, ce qui explique que toucher un tag puisse ouvrir un navigateur sur un appareil où rien n'a été installé pour cela.
À quoi ressemble un tag sans NDEF
Il a l'air cassé, et c'est là le problème pratique.
Le téléphone détecte le tag, identifie sa technologie, et signale qu'il n'y a rien sur quoi agir. Pour la personne qui a touché le tag, c'est indiscernable d'une lecture ratée, alors même que la lecture a parfaitement réussi et que la mémoire peut être pleine de données.
Cela explique une bonne part des signalements « mon téléphone voit le tag mais rien ne se passe ». Le côté radio a fonctionné. Il n'y avait simplement rien dans un format que quoi que ce soit puisse interpréter.
Ce que le conteneur vous coûte
Des octets. La structure a un surcoût, et sur un petit tag ce surcoût représente une fraction non négligeable de ce que vous avez payé. Un tag annoncé avec une capacité donnée en offre moins pour votre contenu réel, et le manque grandit avec le nombre d'enregistrements.
D'où une règle à appliquer : préférez un enregistrement à plusieurs. Une adresse web seule dans un enregistrement laisse plus de place et se lit plus vite que la même information répartie entre un lien, un titre et une note, car chaque enregistrement supplémentaire ajoute des octets d'en-tête que le lecteur doit lire.
L'exception est la redondance délibérée, comme ajouter un enregistrement en texte simple pour que quelque chose de lisible apparaisse sur les plateformes qui ignorent le type d'enregistrement principal. Celle-là vaut ses octets.
Questions fréquentes
Suis-je obligé d'utiliser NDEF ?
Pas techniquement, mais pour tout ce qui est lu par le téléphone de quelqu'un d'autre la réponse est oui en pratique. Sans lui, il faudrait distribuer une application connaissant votre organisation mémoire, ce qui ruine l'intérêt de coller un tag sur une affiche.
Tous les téléphones lisent-ils NDEF de la même façon ?
L'analyse est la même, la réaction ne l'est pas. Les deux plateformes lisent le conteneur à l'identique puis appliquent leurs propres règles sur les types d'enregistrement qui déclenchent une action, et c'est là que les comportements divergent.
Un tag peut-il contenir du NDEF et d'autres données en même temps ?
Sur de nombreuses puces oui, puisque NDEF occupe une zone définie et que le reste de la mémoire peut contenir ce que vous voulez. Seule la partie NDEF sera comprise par un lecteur générique, tout ce qui est en dehors exige votre propre logiciel.
Pourquoi mon tag affiche-t-il moins d'espace libre qu'annoncé ?
Une partie de la mémoire porte la structure qui décrit le tag lui-même, et le conteneur NDEF ajoute son propre surcoût. Les deux sont déduits avant votre contenu, et l'écart est normal plutôt que défectueux.