¿Cómo habla un ordenador con un lector NFC por USB?

Dónde se sitúa el código

Un programa no habla nunca con el aparato USB. Habla con el gestor de recursos que proporciona el sistema operativo, que habla con el lector, que habla con la tarjeta o con la etiqueta. Las especificaciones PC/SC definen esa cadena parte por parte y se publican en abierto; la parte 3 es la del lector en sí, y es donde acaba un desarrollo cuando una etiqueta se comporta de forma distinta a una tarjeta.

Lo que viaja entre el programa y la tarjeta es una APDU, la unidad que describe la página de las APDU. Un lector sin contacto la lleva hasta una etiqueta de tipo 4 o una tarjeta sin cambiar nada; todo lo demás de esta página existe porque los otros tipos de etiqueta no hablan ese idioma.

El mismo intercambio, dos sistemas

En Windows las llamadas pertenecen a winscard: un contexto, la lista de lectores, y luego SCardConnect, que toma un modo de uso compartido, exclusivo o directo, y los protocolos que el programa acepta, T=0 o T=1. SCardTransmit envía el comando con la estructura de control de protocolo que corresponde y devuelve la respuesta.

En macOS y en iOS el mismo intercambio pasa por CryptoTokenKit. TKSmartCardSlotManager enumera las ranuras y exige la autorización com.apple.security.smartcard; TKSmartCard abre una sesión, transmite y la termina, y expone send(ins:p1:p2:data:le:), que construye la APDU por ti, con cla, useExtendedLength y useCommandChaining al lado.

Desde iOS 26, el mismo marco de trabajo puede abrir una ranura sobre la propia radio del teléfono: createNFCSlot(message:completion:) crea una ranura de tarjeta inteligente NFC y presenta una interfaz del sistema, lo que pone una etiqueta detrás de la API que habría usado un lector. Core NFC sigue siendo el marco de trabajo para las etiquetas que no son tarjetas, como describe la página de las sesiones.

Etiquetas sin aplicación de tarjeta

Una etiqueta de tipo 2 o de tipo 5 no tiene aplicación que seleccionar ni APDU que responder. La parte 3 de la especificación las trata haciendo que sea el lector quien trabaje: un lector conforme tiene que admitir Read Binary, Update Binary, Load Keys, General Authenticate, Verify para las tarjetas con código de seguridad, y Get Data. La especificación dice con todas las letras que esos comandos vienen del sector y no de la ISO, y que los fabricantes de lectores reúnen los detalles pidiéndoselos a los fabricantes de chips.

Get Data es el que usa todo proyecto: clase FF, instrucción CA, parámetros 00 00, y una longitud esperada de 00 para el identificador entero. La especificación fija lo que vuelve: 4, 7 o 10 bytes para una etiqueta ISO 14443 A, el PUPI de 4 bytes para una tarjeta 14443 B, 8 bytes para ISO 15693, en el orden recibido durante la anticolisión, rellenado en vez de convertido, y 6A 81 cuando la tarjeta no tiene ningún identificador.

Así que un lector que lee una etiqueta que tu código no lee suele ser un lector que implementa un comando que el tuyo no envía, y no una radio mejor.

Lo que el lector dice que es una etiqueta

Una etiqueta sin contacto no tiene respuesta al reinicio, el ATR que trae una tarjeta, y los programas escritos para tarjetas esperan una. El lector construye entonces una sintética, cuyos campos define el suplemento de la parte 3: el identificador registrado del PC/SC Workgroup, A0 00 00 03 06, un byte que nombra la norma, ISO 14443 A parte 3, ISO 15693 parte 1, FeliCa y demás, y luego dos bytes que nombran el chip a partir de un registro que el grupo mantiene a petición.

Léelo antes de enviar nada. Le dice a tu código qué familia tiene entre manos, y un chip desconocido aparece como información no facilitada en vez de como un fallo, que es la diferencia entre un programa que se adapta y otro que denuncia un lector roto.