¿Cómo encuentra el código el archivo NDEF de una etiqueta de tipo 4?

Selecciona la aplicación

Una etiqueta de tipo 4 guarda el NDEF dentro de una aplicación propia, y el código llega a ella con SELECT por nombre. El código abierto de la pila NFC de Android documenta el comando en su fuente: 00 A4 04 00 07 D2760000850101 00 para las versiones 2.0 y 3.0 de la correspondencia, y D2760000850100, sin el último byte, para la versión 1.0.

La respuesta decide el resto. 90 00 quiere decir que la aplicación existe; 6A 82, no encontrada, quiere decir que la etiqueta no contiene ninguna aplicación NDEF, contenga lo que contenga. En iOS, el identificador tiene que aparecer en la lista del Info.plist de la aplicación antes de que una sesión de etiqueta envíe este SELECT, como explica la página de las declaraciones, y enumerarlo cambia además cómo se entrega una etiqueta DESFire.

Lee el contenedor de capacidad

El contenedor de capacidad es un archivo con el identificador E103. El código lo selecciona por identificador de archivo, 00 A4 00 0C 02 E1 03 en las versiones 2.0 y 3.0, con P2 a 00 en la versión 1.0, y después lo lee con READ BINARY, instrucción 0xB0. Contiene al menos quince bytes:

La versión 3.0 añade una segunda forma de ese bloque, tipo 0x06 y longitud 0x08, cuyo campo de tamaño ocupa cuatro bytes. El código lee el byte de tipo antes de leer los campos que van detrás.

MLe y MLc acotan todos los intercambios posteriores. La pila de Android rechaza un contenedor cuyo MLe esté por debajo de 0x000F, y recorta sus lecturas y escrituras a esos tamaños; un código que los ignora envía comandos que la etiqueta puede rechazar.

Selecciona y lee el archivo NDEF

SELECT por identificador de archivo otra vez, esta vez con el identificador del contenedor, y después READ BINARY en el desplazamiento 0 para dos bytes. Esos dos bytes, NLEN, dan la longitud del mensaje NDEF; un archivo descrito por la forma de cuatro bytes del bloque usa una longitud de cuatro bytes. Una longitud de cero quiere decir que la etiqueta no contiene ningún mensaje.

El mensaje empieza justo detrás de la longitud, en el desplazamiento 2 o 4, y el código lo lee en trozos no más largos que MLe ni que lo que el teléfono acepta. La página del mensaje NDEF cubre lo que contienen después esos bytes.

Escritura y derechos de acceso

Los dos últimos bytes del bloque de control del archivo gobiernan el acceso. 0x00 concede lectura o escritura libres, 0xFF las rechaza por completo, lo que deja el archivo en solo lectura cuando es el byte de escritura, y los valores desde 0x80 son propietarios: el chip aplica su propia condición, como una clave. La ficha del NTAG 424 DNA en wakdev.com describe una, un archivo NDEF libre de leer y escrito bajo una clave configurable.

La escritura usa UPDATE BINARY, instrucción 0xD6, en trozos no más largos que MLc. La pila de Android escribe NLEN como 0000 primero, después el mensaje, y después la longitud real, para que una escritura interrumpida deje un archivo vacío en lugar de un mensaje truncado; la página de las escrituras interrumpidas explica por qué importa el orden.

Nada de esto hace falta para leer o escribir NDEF: la clase Ndef de Android y las llamadas NDEF de Core NFC ejecutan la misma secuencia. El código la recorre él mismo para leer los derechos de acceso, para llegar a otro archivo, o para averiguar por qué la plataforma declara una etiqueta como sin formatear.