NDEF-Format einfach erklärt
Halten Sie einen korrekt kodierten NFC-Tag an ein beliebiges aktuelles Smartphone: Der Link öffnet sich, die Visitenkarte erscheint, das WLAN verbindet sich.
Dass das überall gleich funktioniert, liegt daran, dass Tags und Smartphones ein gemeinsames Format teilen: NDEF.
Dieser Artikel erklärt, was eine NDEF-Nachricht enthält, und geht dann für alle, die es genauer wissen möchten, weiter ins Detail: den Aufbau eines Datensatzes Byte für Byte und die TLV-Strukturen, die ihn im Speicher des Chips aufnehmen.
NDEF, die gemeinsame Sprache von NFC
NDEF steht für NFC Data Exchange Format, das Datenaustauschformat, das vom NFC Forum definiert wird, der Organisation, die die Technologie standardisiert.
Seine Aufgabe ist es, sicherzustellen, dass auf einen Tag geschriebene Inhalte von jedem Lesegerät verstanden werden können, unabhängig davon, wer den Chip oder das Smartphone hergestellt hat.
NDEF ist außerdem unabhängig von der Hardware: Ob es sich um einen Tag vom Type 1, 2, 3, 4 oder 5 handelt, die darin enthaltene Nachricht wird auf genau dieselbe Weise geschrieben und gelesen. Deshalb funktioniert derselbe kodierte Link auf einem NTAG213 genauso gut wie auf einem Chip nach ISO 15693.
Eine Nachricht, mehrere Datensätze
Eine NDEF-Nachricht ist ein Container, der einen oder mehrere Datensätze enthält.
Jeder Datensatz besteht aus drei Teilen: einem kleinen Header von wenigen Byte, einem Typ, der die Art des Inhalts angibt (eine URL, ein Text, eine Visitenkarte ...), und der Nutzlast (Payload), dem eigentlichen Inhalt.
In den meisten Fällen enthält eine Nachricht nur einen Datensatz, typischerweise eine URL, aber nichts hindert Sie daran, mehrere zu schreiben: zum Beispiel eine URL plus einen Text-Datensatz plus einen App-Datensatz. Das Smartphone liest die Datensätze der Reihe nach, doch die meisten Smartphones interpretieren nur den ersten und führen ihn aus.
Wichtig: Wenn Sie mehrere Datensätze auf einem Tag ablegen, setzen Sie den Hauptinhalt immer an die erste Stelle, sonst ignoriert das Smartphone ihn vollständig.
Die häufigsten Datensatztypen
Hier die wichtigsten Inhaltstypen für einen NFC-Tag:
- URL / URI: Öffnet eine Website.
- Text: Zeigt einen Text an.
- vCard: Fügt einen Kontakt hinzu (Name, Telefonnummer, E-Mail ...).
- WLAN / Bluetooth: Verbindet mit einem Netzwerk oder einem Gerät.
- MIME / Media: Enthält Rohdateien oder Datenformate.
- External Type: Speichert benutzerdefinierte, anwendungsspezifische Daten.
- AAR (Android): Startet eine Android-App oder öffnet Google Play (wird von iPhones ignoriert).
Hinweis: Die meisten speziellen Aktionen (soziale Netzwerke, Zahlungen, benutzerdefinierte Links) beruhen tatsächlich auf URL- oder MIME-Datensätzen.
Aufbau eines URL-Datensatzes
NDEF wurde für Chips entwickelt, bei denen jedes Byte zählt, und URLs profitieren von einer eigenen Optimierung: Die gängigsten Präfixe werden durch einen Code von einem Byte ersetzt. Das gesamte „https://www.“ wird zum Code 02. So belegt die vollständige Adresse https://www.wakdev.com nur fünfzehn Byte.
Diese fünfzehn Byte sind: vier Byte Header (D1 01 0B 55, die einen einzelnen Datensatz vom Typ U für URI mit elf Byte Inhalt ankündigen), der Präfixcode 02, dann die zehn Zeichen von wakdev.com. Diese Komprimierung erlaubt es einem kleinen 64-Byte-Chip, einen kurzen Link aufzunehmen, und einem NTAG213, eine URL von rund 132 Zeichen zu speichern.
Jedes Bit dieses Headers hat eine Funktion.
Das erste Byte vereint fünf Flags und ein 3-Bit-Feld. MB (Message Begin) markiert den ersten Datensatz der Nachricht, ME (Message End) den letzten. CF (Chunk Flag) kennzeichnet in Teile zerlegte Inhalte, die Sie auf Tags fast nie antreffen. SR (Short Record) zeigt einen kurzen Datensatz an, dessen Länge in ein einzelnes Byte passt. IL (ID Length) kündigt das Vorhandensein einer optionalen Kennung an.
Die restlichen drei Bits bilden das TNF (Type Name Format), die Familie, zu der der Typ gehört. Für eine URL ist sein Wert 001, der Wert, der den Well-Known-Typen des NFC Forums zugewiesen ist. Es gibt weitere Werte für MIME-Typen oder extern definierte Typen, die hier aber nicht benötigt werden.
Auf unser erstes Byte D1, binär 1101 0001, angewendet: MB ist 1, ME ist 1 (der Datensatz steht allein, er eröffnet und schließt also die Nachricht), CF ist 0, SR ist 1 (Kurzformat), IL ist 0 (keine Kennung) und TNF ist 001 (Well-Known-Typ).
Dann folgen die Typlänge (01: ein einzelnes Zeichen), die Nutzlastlänge (0B: elf Byte, dank des SR-Flags in einem Byte geschrieben; ein langer Datensatz würde vier verwenden) und der Typ selbst: U (0x55), der Buchstabe, der einen URI ankündigt.
Die Nutzlast schließt den Datensatz ab. Bei einer URL ist ihr Aufbau einfach: ein erstes Byte für den Präfixcode (02 für https://www.), dann der Rest der Adresse Zeichen für Zeichen, je ein Byte pro Zeichen (die zehn Byte von wakdev.com).
Insgesamt elf Byte, genau das, was das Längenfeld angekündigt hat. In einer Nachricht mit mehreren Datensätzen trägt nur der erste Datensatz MB und nur der letzte ME: So weiß das Lesegerät, wo die Nachricht beginnt und endet.
TLVs: Die Nachricht im Speicher verpacken
Bei Tags vom Type 1, 2 und 5 wird die Nachricht im Speicher mithilfe von TLV-Strukturen abgelegt (TLV steht für Tag-Length-Value): Jeder Information geht ein T-Byte voraus, das ihre Art angibt, und ein L-Byte, das ihre Länge angibt. Die NDEF-Nachricht wird in einem TLV vom Typ 03 transportiert. Ein Terminator-TLV (FE) markiert das Ende der Nutzdaten, und einige weitere Typen übernehmen Verwaltungsaufgaben: 00 für ein Null- bzw. Füllbyte, 01 und 02 zur Beschreibung gesperrter und reservierter Speicherbereiche. Die Länge L passt bis zu 254 Byte Inhalt in ein Byte; darüber hinaus wechselt sie in ein langes Format (FF gefolgt von zwei Byte), das Nachrichten von mehreren Kilobyte auf größeren Chips ermöglicht.
Am Anfang des Speichers sitzt der Capability Container (CC), vier Byte, die den Tag dem Lesegerät vorstellen: das Magic Byte E1, die Formatversion (10), die Kapazität des NDEF-Bereichs in Vielfachen von acht Byte und die Zugriffsrechte. Bei einem NTAG213 enthält der CC E1 10 12 00 (0x12, also 18, mal 8: 144 Byte NDEF-Bereich, mit freiem Lese- und Schreibzugriff). Danach folgt im Benutzerspeicher 03 (eine NDEF-Nachricht folgt), 0F (fünfzehn Byte), die fünfzehn Byte unserer URL wakdev.com und FE (Ende der Daten). Drei Byte Zusatzdaten rund um die Nachricht: Das ist der ganze Mechanismus. Andere Tag-Familien verpacken die Dinge anders, folgen aber derselben Logik: Type 3 beschreibt seine Nachricht in einem 16-Byte-Attributblock, und Type 4 speichert sie in echten Dateien (einer CC-Datei und einer NDEF-Datei), auf die über APDU-Befehle zugegriffen wird.
NDEF schreiben, ohne sich um Bytes zu kümmern
In der Praxis setzen Sie diese Bytes nie selbst zusammen. Wählen Sie in der App NFC Tools „Schreiben“, fügen Sie einen oder mehrere Datensätze hinzu (eine URL auf https://www.wakdev.com, einen Text-Datensatz usw.) und halten Sie den Tag an Ihr Smartphone: Die App erstellt Nachricht, Header, TLVs und Capability Container gemäß der Spezifikation, sodass das Ergebnis von allen kompatiblen Smartphones gelesen werden kann.
Beim Lesen erkennt Android NDEF-Tags nativ. Auf dem iPhone funktioniert das automatische Lesen im Hintergrund ab dem iPhone XS und XR, und NFC Tools kann ab dem iPhone XS / XR mit iOS 17 oder höher lesen und schreiben, wenn der Scan aus der App heraus gestartet wird.
Das Wichtigste in Kürze
NDEF besteht im Kern aus wenigen Elementen: einer Nachricht, einem oder mehreren typisierten Datensätzen, einem Header, in dem jedes Bit eine Funktion hat, und TLVs, die das Ganze im Speicher hinter einem vier Byte großen Capability Container ablegen.
Genau das garantiert, dass ein heute kodierter Tag auch von den Smartphones von morgen verstanden wird, gleich auf welchem Chip. Und da NFC Tools streng standardkonformes NDEF schreibt, einschließlich TLVs und Header, funktionieren Ihre Tags überall.
