PN532-RFID-NFC-Format-NDEF
 | Page(s) en cours de traduction/élaboration. Page(s) under translation/construction |
NDEF
NDEF est l'acronyme de NFC Data Exchange Format signifiant "format d'échange de donnée NFC".
Le format d'échange de donnée NFC (NDEF) est un format de donnée normalisé qui peut être utilisé pour échanger des informations entre n'importe quel périphériques compatible NFC et un autre périphérique NFC (ou tag). Le format de donnée est composé de NDEF Messages (messages NDEF) et NDEF Records (enregistrement NDEF). Le standard est maintenu par le Forum NFC et librement consultable mais nécessite que vous acceptiez un accord de licence à télécharger.
Le format NDEF est utilisé pour stocker et échanger des informations tels que URIs, du texte, etc., en utilisant un format facilement compréhensible. Les tags NFC comme les cartes Mifare Classic peuvent être configurées comme tags NDEF et les données écrites sur celles-ci par un périphérique NFC (des NDEF Records) peuvent être comprises/interprétées et être accédées par un autre périphérique compatible NDEF. Les messages NDEF peuvent également être utilisés pour échanger des informations entre deux périphériques NFC actifs en mode "peer-to-peer". En adhérent au format d'échange de données NDEF durant la communication, des périphériques qui ne connaissent absolument rien l'un de l'autre deviennent alors capable de partager des données de façon organisée et de se comprendre mutuellement. Voici une liste de quelques notes applicatives et documents de référence concernant NDEF:
- NFC Data Exchange Format (NDEF) Technical Specification (Nécessite que vous acceptiez les termes de la licence)
- NFC Record Type Definition (RTD) Specification (Nécessite que vous acceptiez les termes de la licence)
- NXP White Paper - NFC Forum Type Tags
Messages NDEF
Les messages NDEF (dit NDEF Messages en anglais) sont des mécanismes de base concernant le "transport" d'enregistrements NDEF (le NDEF records). Chaque messahe peut contenir un ou plusieurs enregistrement NDEF.
Enregistrements NDEF
Les enregistrements NDEF (dit "NDEF Records") contiennent une quantité spécifique de donnée (dite "payload" dans la documentation anglaise. PayLoad cela correspond à la charge utile... comprenez la charge utile de donnée).
Un enregistrement NDEF à la structure suivante qui permet d'identifier le contenu et la taille de l'enregistrement:
Bit 7 6 5 4 3 2 1 0
------ ------ ------ ------ ------ ------ ------ ------
[ MB ] [ ME ] [ CF ] [ SR ] [ IL ] [ TNF ]
[ TYPE LENGTH ] -- longueur du champ type (record type)
[ PAYLOAD LENGTH ] -- longueur de la charge utile (le Payload, donc les données)
[ ID LENGTH ] -- longueur du champ d'identification (ID)
[ RECORD TYPE ] -- champ: Type d'enregistrement
[ ID ] -- champ: identification
[ PAYLOAD ] -- champ: charge utile (les données)
L'entête (octet 0)
[ MB ] [ ME ] [ CF ] [ SR ] [ IL ] [ TNF ]
Aussi appelé "record header" (l'entête de l'enregistrement) contient plusieurs champs importants incluant un champ de 3 bits qui identifie le type d'enregistrement qui suivra. Nous parlons du champs TNF ou Type Name Formatque nous traduirons par "le nom du type de format":
Le champs TNF
Le champ Type Name Format (ou TNF ou encore nom du type de format) d'un enregistrement NDEF est une valeur 3-bits qui décrit le type d'enregistrement ET prédéfini donc les attentes de la structure et du contenu qui suivra dans le reste de l'enregistrement.
Voici différentes valeurs possible pour le champ TNF:
TNF Value Record Type
--------- -----------------------------------------
0x00 Empty Record / Enregistrement vide.
Indique qu'il n'y a aucun type, id, ou donnée/payload associé à
l'enregistrement NDEF.
Ce type d'enregistrement est utile sur les cartes nouvellements
formatées puisque chaque tag NDEF doit contenir au moins un
enregistrement NDEF.
0x01 Well-Known Record / Enregistrement au contenu identifié.
Indique que le type de champs utilise un type de nom de format RTD.
Ce "type de nom" est utilisé pour stocker n'importe quel enregistrement
définit par un ''Record Type Definition'' (RTD) tel que RTD Text,
RTD URIs, etc. Il s'agit d'un des types d'enregistrement le plus
fréquemment utilisé et les plus utile.
0x02 MIME Media Record / Enregistrement Média au format MIME
Indique que les données / payload un morceau intermédiaire (''chunk'') ou le
dernier morceau d'un enregistrement NDEF décomposé en morceau (chunked NDEF Record).
0x03 Absolute URI Record / enregistrement avec URI absolu
Indique que le type de champ (''type field'') contient la valeur qui suit la
la structure définie par RFC 3986 (absolute-URI construct)
0x04 External Record / enregistrement externe
Indique que le type de champ contient une valeur suivant les spécifications
de nom RTD externe (''RTD external name specification'')
0x05 Unknown Record / Enregistrement inconnu
Indique que le type de donnée / payload est inconnu
0x06 Unchanged Record / Enregistrement nom modifié
Indique que les données / payload est un morceau intermédiaire d'un
enregistrement NDEF découpé en morceau (''chunked NDEF Record'')
IL: champ ID LENGTH
IL est l'acronyme de ID Length, c'est un flag (drapeau) indiquant si le champ "ID Length Field" est présent ou non. S'il est placé à la valeur 0 alors le champs 'ID Length' est omis dans l'enregistrement NDEF.
SR: Short Record Bit
SR indique un enregistrement court (avec des bits).
Le drapeau/flag SR placé à 1 sur le si le champ "PAYLOAD LENGTH" fait 1 octet/byte (8 bits/0-255) ou moins. Cela permet de faire des enregistrements plus compactes.
CF: Chunk Flag
CF est un drapeau/flag indiquant un morceau.
Le drapeau/flag CF indique que c'est le premier morceau (chunck) ou un morceau intermédiaire d'un enregistrement découpé en morceau.
ME: Message End
Drapeau/Flag "fin de message".
Le drapeau/flag ME indique qu'il s'agit du dernier enregistrement du message.
MB: Message Begin
Drapeau/flag début de message.
Le drapeau/flag MB indique l'élément actuel est le début d'un message NDEF.
Type Length
Indique la longeur (en octet/byte) du champs "Record Type" (type d'enregistrement). Cette valeur est toujours à zéro poue certains types d'enregistrement défini dans le champ TNF traité ci-dessus (TNF: Type Name Format ou nom du type de format).
Payload Length
Indique la longueur (en octets/bytes) du payload de l'enregistrement. Il s'agit donc de la longueur des données (de la 'charge utile'). Si le champs SR (décrit ci-dessus) est placé à 1 alors cette valeur fait un octet/byte de long (pour un payload de 0 à 255 bytes). Si le champ SR est à 0, cette valeur occupera 4 octets/bytes et sera donc une valeur 32-bits.
ID Length
Indique la longueur du champ d'identification (ID) . Ce champ est uniquement présent si le drapeau/flag IL (décrit ci-dessus) est à 1 dans l'entête de l'enregistrement (record header).
Record Type
Cette valeur décrit le 'type' d'enregistrement qui suit. Les valeurs pour le champ type doit correspondre à la valeur renseignée dans les bits TNF de l'entête de l'enregistrement.
Record ID
La valeur du champ ID (identification) si ID est inclus (le bit IL dans l'entête d'enregistrement doit être à 1). Ce champ est omis si le bit IL est placé à 0.
Payload
Le payload de l'enregistrement (les données transportées) qui aura exactement le nombre d'octets/bytes tels que décrit dans le champ "Payload Length" décrit ci-dessus.
Well-Known Records (TNF Record Type 0x01)
Les types d'enregistrement bien connu. Type Name Field = 0x01.
Le type d'enregistrement le plus utile est certainement TNF Type 0x01 qui n'est autre que celui correspondant à "NFC Forum Well-Known Type" (que nous traduirons par "Type bien connu du Forum NFC").
Les types d'enregistrement qui adhèrent aux types "Well-Defined" (bien défini) sont tous décrit par un document appelé RTD (Record Type Definition que l'on traduira par définition de type d'enregistrement).
Quelques uns de ces définitions d'enregistrement bien défini ("Well-Defined RTD") sont:
URI Records (0x55/'U')
Le "Type bien connu" ("Well Known Type") pour les enregistrement URI est 0x55 ('U'). Ce type d'enregistrement peut être utilisé pour stocker une variété d'information utiles tel que des n° de téléphone (tel:), adresses de site web, liens vers un fichier FTP, etc.
Les enregistrement URI sont définit dans le document "URI Record Type Definition" du Forum NFC. Cet enregistrement à la structure suivante:
Nom Offset Taille Description
---- ------ ---- -----------
Identifier Code 0 1 octet Code d'identification de l'URI, Voir la table ci-dessous
Champ URI 1 N octets Le reste de l'URI (dépend de l'octet/byte 0 ci-dessus)
Le code d'identification de l'URI (URI Identifier Code) est utilisé pour raccourcir la longueur de l'URI et peut avoir l'une des valeurs suivantes:
Valeur Protocole
----- --------
0x00 Pas d'utilisation de préfix... l'URI est entièrement inclus dans le champ URI
0x01 http://www.
0x02 https://www.
0x03 http://
0x04 https://
0x05 tel:
0x06 mailto:
0x07 ftp://anonymous:anonymous@
0x08 ftp://ftp.
0x09 ftps://
0x0A sftp://
0x0B smb://
0x0C nfs://
0x0D ftp://
0x0E dav://
0x0F news:
0x10 telnet://
0x11 imap:
0x12 rtsp://
0x13 urn:
0x14 pop:
0x15 sip:
0x16 sips:
0x17 tftp:
0x18 btspp://
0x19 btl2cap://
0x1A btgoep://
0x1B tcpobex://
0x1C irdaobex://
0x1D file://
0x1E urn:epc:id:
0x1F urn:epc:tag:
0x20 urn:epc:pat:
0x21 urn:epc:raw:
0x22 urn:epc:
0x23 urn:nfc:
Le champ URI suis le code d'identification URI. Ce champ contient le reste du champ URI, reste de l'URI suivant la partie ajoutée en fonction de "code d'identification de l'URI". L'URI est conforme au RFC 3987). Note: Si l'URI ID = 0x00 alors il faut préciser complètement l'URI (+protocole) dans le champs URI.
Test Records
A faire...
Smart Poster Records
A faire...
Exemple d'enregistrement NDEF
Well Known Records
URI Record
An example of a URI record is shown in "Memory Dump of a Mifare Classic 1K Card with an NDEF Record" below. A faire...
Text Record
A faire...
Smartposter Record
A faire...
Absolute URI Record
A faire...
Using Mifare Classic Cards as an NDEF Tag
| | Page(s) en cours de traduction/élaboration. Page(s) under translation/construction |
Mifare Classic 1K and 4K cards can be configured as NFC Forum compatible NDEF tags, but they must be organised in a certain manner to do so. The requirements to make a Mifare Classic card "NFC Forum compliant" are described in the following App Note from NXP:
AN1304 - NFC Type MIFARE Classic Tag Operation
While the App Note above is the authoritative source on the matter, the following notes may also offer a quick overview of the key concepts involved in using Mifare Classic cards as NFC Forum compatible 'NDEF' tags:
Mifare Application Directory (MAD)
In order to form a relationship between the sector-based memory of a Mifare Classic card and the individual NDEF records, the Mifare Application Directory (MAD) structure is used. The MAD indicates which sector(s) contains which NDEF record. The definitive source of information on the Mifare Application Directory is the following application note:
AN10787 - MIFARE Application Directory (MAD)
For reference sake, the two types of MADs (depending on the size of the card in question) are defined below:
Mifare Application Directory 1 (MAD1)
| | Page(s) en cours de traduction/élaboration. Page(s) under translation/construction |
Source: PN532 RFID/NFC Breakout and Shield créé par LadyAda pour AdaFruit Industries. Crédit [www.adafruit.com AdaFruit Industries]
Traduit par Meurisse D. pour MCHobby.be
Traduit avec l'autorisation d'AdaFruit Industries - Translated with the permission from Adafruit Industries - www.adafruit.com
Toute référence, mention ou extrait de cette traduction doit être explicitement accompagné du texte suivant : « Traduction par MCHobby (www.MCHobby.be) - Vente de kit et composants » avec un lien vers la source (donc cette page) et ce quelque soit le média utilisé.
L'utilisation commercial de la traduction (texte) et/ou réalisation, même partielle, pourrait être soumis à redevance. Dans tous les cas de figures, vous devez également obtenir l'accord du(des) détenteur initial des droits. Celui de MC Hobby s'arrêtant au travail de traduction proprement dit.