Wie sendet man einen rohen Befehl an einen Tag?
Über die Klasse oder das Protokoll, das zur Funkschicht des Tags passt: NfcA, NfcV oder IsoDep unter Android, NFCMiFareTag, NFCISO15693Tag oder NFCISO7816Tag in einer Tag-Sitzung unter iOS. Der Code baut die Bytes des Befehls, die Plattform setzt den Rahmen darum, und die Antwort kommt als Bytes zurück, die nur der Code beurteilen kann. Web NFC sendet keine.
Den Weg nach der Funkschicht wählen
Unter Android stellen die Technologieklassen, die Bytes unverändert senden, alle transceive() bereit. NfcA erreicht NFC-A-Tags, darunter jeden Type-2-Tag; NfcV erreicht Tags nach ISO/IEC 15693; IsoDep trägt APDU zu Tags und Karten nach ISO/IEC 14443-4. MifareUltralight.transceive() ist laut seiner Referenz dasselbe wie eine Verbindung über NfcA und ein Aufruf von deren Methode.
Unter iOS brauchen rohe Befehle eine Tag-Sitzung, da eine NDEF-Sitzung keinen Weg für Befehle übergibt, wie die Seite zu den Sitzungen erklärt. Der erkannte Tag kommt als eines der Protokolle an, die Core NFC festlegt: NFCMiFareTag, dessen sendMiFareCommand MIFARE-Ultralight-, Plus- und DESFire-Tags bedient, aber nicht das Crypto1-Protokoll von MIFARE Classic; NFCISO15693Tag, mit einer Methode je genormtem Befehl; NFCISO7816Tag, dessen sendCommand(apdu:) APDU sendet; und NFCFeliCaTag für FeliCa.
Eine Webseite hat überhaupt keinen Weg. Web NFC hört mit Absicht bei NDEF auf, wie die Seite zum Schreiben mit Web NFC beschreibt, ein Vorhaben mit rohen Befehlen braucht also eine Anwendung.
Was Ihre Bytes enthalten
Die Plattform setzt einen Rahmen um das, was der Code sendet, und jede Referenz sagt, wo dieser Rahmen aufhört. NfcA.transceive() nimmt vollständige Bytes und fügt den CRC selbst hinzu: Die Referenz zu NfcA sagt Anwendungen, ihn nicht anzuhängen, und schließt die Befehle der Suche aus. NfcV.transceive() erwartet das Flags-Byte, den Befehlscode und dessen Parameter, und fügt den CRC ebenfalls hinzu. IsoDep.transceive() nimmt die APDU allein, ohne Rahmenzeichen, und teilt eine lange selbst auf.
Core NFC zieht die Linie nicht an derselben Stelle. Apples Referenz zu sendMiFareCommand bittet die Anwendung, die zwei CRC-Bytes eines Befehls der MIFARE-Ultralight-Familie zu berechnen und anzuhängen, das Gegenteil der Regel von Android, sodass ein aus Android-Code übernommener Befehl ohne sie ankommt. Die Methoden für ISO 15693 bauen die ganze Anfrage und richten sie voreingestellt an die Kennung des Tags.
Welche Plattform auch immer, ein Befehl, den kein Tag-Typ festlegt, gehört einem Chip. Sein Code und seine Parameter stammen aus dem Datenblatt dieses Chips, das diese Website den Chip-Datenblättern auf wakdev.com überlässt.
Die Antwort lesen
Ein Aufruf, der zurückkehrt, hat Bytes geliefert, und mehr hat die Plattform nicht geprüft. Ob der Tag den Befehl angenommen hat, steht in diesen Bytes, in einer Form, die zum Protokoll gehört.
Ein Tag nach ISO 15693 beginnt seine Antwort mit einem Flags-Byte, dessen unterstes Bit einen Fehler meldet, gefolgt von einem Fehlercode, so die Festlegungen im quelloffenen NFC-Stack von Android. Core NFC macht aus einer solchen Antwort einen Fehler, dessen Angaben NFCISO15693TagResponseErrorKey tragen, mit dem Code aus der Norm.
Eine APDU endet mit zwei Statusbytes, 90 00, wenn der Befehl durchlief. Apples Referenz zu sendCommand gibt sie als sw1 und sw2 zurück, immer gültig, und behält ihren Fehler für Übertragungsprobleme: Eine Karte, die einen Befehl verweigert, antwortet normal, mit der Weigerung in den Statusbytes. Die Seite zur APDU führt die üblichen Werte auf.
Zwei Arten von Fehlschlag
Ein Fehlschlag der Übertragung heißt, dass keine brauchbare Antwort ankam. Unter Android wirft der Aufruf TagLostException, wenn der Tag das Feld verlassen hat, und IOException bei anderen Fehlschlägen. Unter iOS gehören zu den Fehlercodes readerTransceiveErrorTagConnectionLost, readerTransceiveErrorPacketTooLong für einen Befehl, der länger ist als der Tag annimmt, und readerTransceiveErrorTagResponseError, wenn der Tag mit einem Fehler geantwortet hat.
Ein Schreibvorgang, der in einem Fehlschlag der Übertragung endet, hat ein unbekanntes Ergebnis. Der Befehl kann den Tag erreicht haben, bevor seine Antwort verloren ging, lesen Sie den Speicher also zurück, bevor Sie erneut etwas senden, und schreiben Sie in einer Reihenfolge, die nie eine halb gültige Nachricht hinterlässt, das Thema der Seite zu abgebrochenen Schreibvorgängen.
Grenzen gelten vor alledem. Wie viele Bytes ein Aufruf tragen kann und wie lange er wartet, ist von einem Android-Telefon zum nächsten verschieden, wie die Seite zu den Grenzen des Controllers erklärt: Ein Befehl, der auf dem Testtelefon arbeitet, kann auf einem anderen scheitern, bevor er den Tag erreicht.
Häufige Fragen
Kann eine Webseite einen rohen Befehl an einen Tag senden?
Nein. Web NFC liest und schreibt nur NDEF, rohe Befehle brauchen also eine Anwendung unter Android oder iOS.
Fügt mein Code den CRC hinzu?
Unter Android nicht, dort fügen NfcA und NfcV ihn hinzu. Apples Referenz verlangt ihn bei Befehlen der MIFARE-Ultralight-Familie, die mit sendMiFareCommand gesendet werden.
Warum kehrt ein Befehl zurück, ohne etwas zu bewirken?
Die Plattform meldet eine gelieferte Antwort, keinen angenommenen Befehl. Lesen Sie das Fehler-Bit einer Antwort nach ISO 15693 oder die Statusbytes einer APDU, bevor Sie dem Ergebnis trauen.
Woher stammen die Befehle eines bestimmten Chips?
Aus dem Datenblatt dieses Chips. Diese Rubrik behandelt die Befehle, die die Tag-Typen des NFC Forum festlegen, und die Chip-Datenblätter auf wakdev.com den Rest.