El formato NDEF explicado de forma sencilla
Acerca una etiqueta NFC bien codificada a cualquier smartphone reciente: se abre el enlace, aparece la tarjeta de presentación, se conecta el Wi-Fi.
Si esto funciona igual en todas partes, es porque las etiquetas y los teléfonos comparten un mismo formato: NDEF.
Este artículo explica qué contiene un mensaje NDEF y luego profundiza para quienes quieran conocer los detalles: la anatomía de un registro, byte a byte, y las estructuras TLV que lo guardan en la memoria del chip.
NDEF, el lenguaje común del NFC
NDEF son las siglas de NFC Data Exchange Format, el formato de intercambio de datos definido por el NFC Forum, la organización que normaliza la tecnología.
Su función es garantizar que cualquier lector pueda entender el contenido escrito en una etiqueta, sea quien sea el fabricante del chip o del teléfono.
NDEF también es independiente del hardware: tanto si la etiqueta es de Type 1, 2, 3, 4 o 5, el mensaje que contiene se escribe y se lee exactamente de la misma manera. Por eso un mismo enlace codificado funciona igual de bien en un NTAG213 que en un chip ISO 15693.
Un mensaje, varios registros
Un mensaje NDEF es un contenedor que incluye uno o varios registros.
Cada registro consta de tres partes: una pequeña cabecera de unos pocos bytes, un tipo que declara la naturaleza del contenido (una URL, un texto, una tarjeta de presentación...) y la carga útil, el propio contenido.
En la mayoría de los casos un mensaje contiene un solo registro, normalmente una URL, pero nada impide escribir varios: una URL más un registro de texto más un registro de aplicación, por ejemplo. El teléfono lee los registros por orden, pero la mayoría de los smartphones solo interpretan y ejecutan el primero.
Importante: si colocas varios registros en una etiqueta, pon siempre el contenido principal en primera posición; de lo contrario, el teléfono lo ignorará por completo.
Los tipos de registro más habituales
Estos son los principales tipos de contenido de una etiqueta NFC:
- URL / URI: abre un sitio web.
- Texto: muestra un texto.
- vCard: añade un contacto (nombre, teléfono, correo electrónico, ...).
- Wi-Fi / Bluetooth: se conecta a una red o a un dispositivo.
- MIME / Media: transporta archivos o formatos de datos en bruto.
- Tipo externo: guarda datos personalizados, específicos de una aplicación.
- AAR (Android): inicia una aplicación Android o abre Google Play (los iPhone lo ignoran).
Nota: la mayoría de las acciones específicas (redes sociales, pagos, enlaces personalizados) se basan en realidad en registros URL o MIME.
Anatomía de un registro URL
NDEF se diseñó para chips en los que cada byte cuenta, y las URL se benefician de una optimización específica: los prefijos más habituales se sustituyen por un código de un solo byte. Todo el "https://www." se convierte en el código 02. Como resultado, la dirección completa https://www.wakdev.com ocupa solo quince bytes.
Esos quince bytes son: cuatro bytes de cabecera (D1 01 0B 55, que anuncian un único registro de tipo U, de URI, con once bytes de contenido), el código de prefijo 02 y, después, los diez caracteres de wakdev.com. Esta compresión es la que permite que un chip pequeño de 64 bytes guarde un enlace corto, y que un NTAG213 almacene una URL de unos 132 caracteres.
Cada bit de esta cabecera tiene una función.
El primer byte agrupa cinco indicadores y un campo de 3 bits. MB (Message Begin) marca el primer registro del mensaje y ME (Message End), el último. CF (Chunk Flag) señala un contenido fragmentado, algo que casi nunca verás en las etiquetas. SR (Short Record) indica un registro corto, cuya longitud cabe en un solo byte. IL (ID Length) anuncia la presencia de un identificador opcional.
Los tres bits restantes forman el TNF (Type Name Format), la familia a la que pertenece el tipo. Para una URL, su valor es 001, el valor asignado a los tipos conocidos del NFC Forum. Existen otros valores para los tipos MIME o los definidos externamente, pero aquí no hacen falta.
Aplicado a nuestro primer byte, D1, o 1101 0001 en binario: MB vale 1, ME vale 1 (el registro está solo, así que abre y cierra el mensaje), CF vale 0, SR vale 1 (formato corto), IL vale 0 (sin identificador) y TNF vale 001 (tipo conocido).
Después vienen la longitud del tipo (01: un solo carácter), la longitud de la carga útil (0B: once bytes, escritos en un solo byte gracias al indicador SR; un registro largo usaría cuatro) y el propio tipo: U (0x55), la letra que anuncia un URI.
La carga útil cierra el registro. Para una URL, su estructura es sencilla: un primer byte para el código de prefijo (02 para https://www.) y, a continuación, el resto de la dirección carácter a carácter, un byte por cada uno (los diez bytes de wakdev.com).
Once bytes en total, exactamente lo que anunciaba el campo de longitud. En un mensaje con varios registros, solo el primero lleva MB y solo el último lleva ME: así sabe el lector dónde empieza y dónde termina el mensaje.
TLV: envolver el mensaje en la memoria
En las etiquetas Type 1, 2 y 5, el mensaje se guarda en la memoria mediante estructuras TLV, de Tag-Length-Value (etiqueta-longitud-valor): cada dato va precedido de un byte T que anuncia su naturaleza y de un byte L que indica su longitud. El mensaje NDEF viaja dentro de un TLV de tipo 03. Un TLV de terminación (FE) marca el final de los datos útiles, y algunos otros tipos se encargan de tareas auxiliares: 00 para un byte nulo o de relleno, 01 y 02 para describir las zonas de memoria bloqueadas y reservadas. La longitud L cabe en un byte hasta 254 bytes de contenido; a partir de ahí, pasa a un formato largo (FF seguido de dos bytes), que permite mensajes de varios kilobytes en chips más grandes.
En la parte superior de la memoria está el Capability Container (CC), cuatro bytes que presentan la etiqueta al lector: el byte mágico E1, la versión del formato (10), la capacidad de la zona NDEF expresada en múltiplos de ocho bytes y los derechos de acceso. En un NTAG213, el CC contiene E1 10 12 00 (0x12, o 18, por 8: 144 bytes de zona NDEF, con acceso abierto de lectura y escritura). La memoria de usuario continúa entonces con 03 (llega un mensaje NDEF), 0F (quince bytes), los quince bytes de nuestra URL wakdev.com y FE (fin de los datos). Tres bytes de sobrecarga alrededor del mensaje: ese es todo el mecanismo. Otras familias de etiquetas lo organizan de otra manera, pero siguen la misma lógica: el Type 3 describe su mensaje en un bloque de atributos de 16 bytes, y el Type 4 lo guarda en archivos reales (un archivo CC y un archivo NDEF), a los que se accede mediante comandos APDU.
Escribir NDEF sin preocuparte por los bytes
En la práctica, nunca tendrás que ensamblar estos bytes por tu cuenta. Con la aplicación NFC Tools, selecciona "Escribir", añade uno o varios registros (una URL a https://www.wakdev.com, un registro de texto, etc.) y acerca la etiqueta: la aplicación compone el mensaje, las cabeceras, los TLV y el Capability Container según la especificación, de modo que el resultado se puede leer en todos los smartphones compatibles.
En cuanto a la lectura, Android reconoce las etiquetas NDEF de forma nativa. En iPhone, la lectura automática en segundo plano funciona a partir del iPhone XS y XR, y NFC Tools puede leer y escribir desde el iPhone XS / XR con iOS 17 o posterior, iniciando el escaneo desde la propia aplicación.
Ideas clave
NDEF se resume en unos pocos elementos: un mensaje, uno o varios registros con tipo, una cabecera en la que cada bit tiene una función y unos TLV que almacenan todo en la memoria, tras un Capability Container de cuatro bytes.
Esto es lo que garantiza que una etiqueta codificada hoy será entendida por los teléfonos de mañana, sea cual sea el chip que la lleve. Y como NFC Tools escribe NDEF estrictamente estándar, TLV y cabeceras incluidos, tus etiquetas funcionarán en todas partes.
