Il formato NDEF spiegato in modo semplice
Avvicina un tag NFC codificato correttamente a un qualsiasi smartphone recente: il link si apre, compare il biglietto da visita, il Wi-Fi si connette.
Se funziona allo stesso modo ovunque è perché tag e telefoni condividono un unico formato comune: NDEF.
Questo articolo spiega cosa contiene un messaggio NDEF, poi approfondisce per chi vuole entrare nei dettagli: l'anatomia di un record, byte per byte, e le strutture TLV che lo racchiudono nella memoria del chip.
NDEF, il linguaggio comune dell'NFC
NDEF è la sigla di NFC Data Exchange Format, il formato di scambio dati definito dall'NFC Forum, l'organizzazione che standardizza la tecnologia.
Il suo scopo è garantire che il contenuto scritto su un tag possa essere compreso da qualsiasi lettore, indipendentemente da chi abbia prodotto il chip o il telefono.
NDEF è inoltre indipendente dall'hardware: che il tag sia Type 1, 2, 3, 4 o 5, il messaggio che contiene viene scritto e letto esattamente allo stesso modo. Per questo lo stesso link codificato funziona altrettanto bene su un NTAG213 e su un chip ISO 15693.
Un messaggio, più record
Un messaggio NDEF è un contenitore che include uno o più record.
Ogni record è composto da tre parti: una piccola intestazione di pochi byte, un tipo che dichiara la natura del contenuto (un URL, un testo, un biglietto da visita...) e il payload, cioè il contenuto vero e proprio.
Nella maggior parte dei casi un messaggio contiene un solo record, in genere un URL, ma nulla ti impedisce di scriverne più di uno: ad esempio un URL, più un record di testo, più un record di applicazione. Il telefono legge i record in ordine, ma la maggior parte degli smartphone interpreta ed esegue solo il primo.
Importante: se inserisci più record su un tag, metti sempre il contenuto principale in prima posizione, altrimenti il telefono lo ignorerà completamente.
I tipi di record più comuni
Ecco i principali tipi di contenuto di un tag NFC:
- URL / URI: apre un sito web.
- Testo: mostra un testo.
- vCard: aggiunge un contatto (nome, telefono, e-mail, ...).
- Wi-Fi / Bluetooth: si connette a una rete o a un dispositivo.
- MIME / Media: trasporta file o formati di dati grezzi.
- Tipo esterno: memorizza dati personalizzati, specifici di un'applicazione.
- AAR (Android): avvia un'app Android o apre Google Play (ignorato dagli iPhone).
Nota: la maggior parte delle azioni specifiche (social network, pagamenti, link personalizzati) si basa in realtà su record URL o MIME.
Anatomia di un record URL
NDEF è stato progettato per chip in cui ogni byte conta, e gli URL beneficiano di un'ottimizzazione dedicata: i prefissi più comuni vengono sostituiti da un codice di un solo byte. L'intero "https://www." diventa il codice 02. Di conseguenza l'indirizzo completo https://www.wakdev.com occupa solo quindici byte.
Questi quindici byte sono: quattro byte di intestazione (D1 01 0B 55, che annunciano un solo record di tipo U per URI con undici byte di contenuto), il codice prefisso 02, poi i dieci caratteri di wakdev.com. Questa compressione permette a un piccolo chip da 64 byte di contenere un link breve e a un NTAG213 di memorizzare un URL di circa 132 caratteri.
Ogni bit di questa intestazione ha un ruolo.
Il primo byte raggruppa cinque flag e un campo da 3 bit. MB (Message Begin) segna il primo record del messaggio, ME (Message End) l'ultimo. CF (Chunk Flag) segnala un contenuto frammentato, cosa che sui tag non vedrai quasi mai. SR (Short Record) indica un record breve, la cui lunghezza sta in un solo byte. IL (ID Length) annuncia la presenza di un identificatore opzionale.
I restanti tre bit formano il TNF (Type Name Format), la famiglia a cui appartiene il tipo. Per un URL il suo valore è 001, il valore assegnato ai tipi noti (well-known) dell'NFC Forum. Esistono altri valori per i tipi MIME o per quelli definiti esternamente, ma qui non servono.
Applicato al nostro primo byte, D1, ovvero 1101 0001 in binario: MB è 1, ME è 1 (il record è da solo, quindi apre e chiude il messaggio), CF è 0, SR è 1 (formato breve), IL è 0 (nessun identificatore) e TNF è 001 (tipo noto).
Poi arrivano la lunghezza del tipo (01: un solo carattere), la lunghezza del payload (0B: undici byte, scritta su un solo byte grazie al flag SR; un record lungo ne userebbe quattro) e il tipo vero e proprio: U (0x55), la lettera che annuncia un URI.
Il payload chiude il record. Per un URL la sua struttura è semplice: un primo byte per il codice prefisso (02 per https://www.), poi il resto dell'indirizzo carattere per carattere, un byte ciascuno (i dieci byte di wakdev.com).
Undici byte in totale, esattamente quanto annunciato dal campo lunghezza. In un messaggio con più record solo il primo porta MB e solo l'ultimo porta ME: è così che il lettore sa dove il messaggio inizia e dove finisce.
TLV: racchiudere il messaggio in memoria
Nei tag Type 1, 2 e 5 il messaggio viene memorizzato usando strutture TLV, ovvero Tag-Length-Value (tag-lunghezza-valore): ogni informazione è preceduta da un byte T che ne annuncia la natura e da un byte L che ne indica la lunghezza. Il messaggio NDEF viaggia dentro un TLV di tipo 03. Un TLV Terminator (FE) segna la fine dei dati utili e alcuni altri tipi si occupano della gestione: 00 per un byte nullo/di riempimento, 01 e 02 per descrivere le aree di memoria bloccate e riservate. La lunghezza L sta in un solo byte fino a 254 byte di contenuto; oltre, passa a un formato lungo (FF seguito da due byte), che consente messaggi di diversi kilobyte sui chip più grandi.
In cima alla memoria si trova il Capability Container (CC), quattro byte che presentano il tag al lettore: il magic byte E1, la versione del formato (10), la capacità dell'area NDEF espressa in multipli di otto byte e i diritti di accesso. Su un NTAG213 il CC contiene E1 10 12 00 (0x12, ovvero 18, per 8: 144 byte di area NDEF, con accesso libero in lettura e scrittura). Segue la memoria utente con 03 (sta arrivando un messaggio NDEF), 0F (quindici byte), i quindici byte del nostro URL wakdev.com e FE (fine dei dati). Tre byte in più attorno al messaggio: questo è l'intero meccanismo. Altre famiglie di tag organizzano le cose in modo diverso ma seguono la stessa logica: il Type 3 descrive il proprio messaggio in un blocco di attributi da 16 byte e il Type 4 lo memorizza in veri e propri file (un file CC e un file NDEF), a cui si accede tramite comandi APDU.
Scrivere NDEF senza pensare ai byte
In pratica non dovrai mai assemblare questi byte a mano. Con l'app NFC Tools seleziona "Scrittura", aggiungi uno o più record (un URL verso https://www.wakdev.com, un record di testo, ecc.) e avvicina il tag: l'app compone il messaggio, le intestazioni, i TLV e il Capability Container secondo la specifica, così il risultato è leggibile da tutti gli smartphone compatibili.
Per quanto riguarda la lettura, Android riconosce nativamente i tag NDEF. Su iPhone la lettura automatica in background funziona a partire da iPhone XS e XR, e NFC Tools può leggere e scrivere da iPhone XS / XR con iOS 17 o versioni successive, avviando la scansione dall'interno dell'app.
Concetti chiave
NDEF si riduce a pochi elementi: un messaggio, uno o più record tipizzati, un'intestazione in cui ogni bit ha una funzione e dei TLV che memorizzano il tutto, dietro un Capability Container di quattro byte.
È questo che garantisce che un tag codificato oggi sarà compreso dai telefoni di domani, qualunque sia il chip su cui si trova. E poiché NFC Tools scrive NDEF rigorosamente standard, TLV e intestazioni compresi, i tuoi tag funzioneranno ovunque.
