PN532-RFID-NFC-Format-NDEF

De MCHobby - Wiki
Sauter à la navigation Sauter à la recherche


MCHobby investit du temps et de l'argent dans la réalisation de traduction et/ou documentation. C'est un travail long et fastidieux réalisé dans l'esprit Open-Source... donc gratuit et librement accessible.
SI vous aimez nos traductions et documentations ALORS aidez nous à en produire plus en achetant vos produits chez MCHobby.
Page-under-construction.pngPage(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:

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 Field" traité ci-dessus.

Payload Length

Indicates the length (in bytes) of the record payload. If the SR field (described above) is set to 1 in the record header, this value will be one byte long (for a payload length from 0-255 bytes). If the SR field is set to 0, this value will be a 32-bit value occupying 4 bytes.

ID Length

 Page(s) en cours de traduction/élaboration.

Page(s) under translation/construction

Indique la longueur du champ d'identification (ID) . This field is present only if the IL flag (described above) is set to 1 in the record header.

Record Type

This value describes the 'type' of record that follows. The values of the type field must corresponse to the value entered in the TNF bits of the record header.

Record ID

The value of the ID field if an ID is included (the IL bit in the record header is set to 1). If the IL bit is set to 0, this field is ommitted.

Payload

The record payload, which will be exactly the number of bytes described in the Payload Length field earlier.

Well-Known Records (TNF Record Type 0x01)

Probably the most useful record type is the "NFC Forum Well-Known Type" (TNF Type 0x01). Record types that adhere to the "Well-Defined" type are each described by something called an RTD or Record Type Definition. Some of the current Well-Defined RTDs are:

URI Records (0x55/'U')

The "Well Known Type" for a URI record is 0x55 ('U'), and this record type can be used to store a variety of useful information such as telephone numbers (tel:), website addresses, links to FTP file locations, etc.

URI Records are defined in the document "URI Record Type Definition" from the NFC Forum, and it has the following structure:

    Name            Offset   Size      Description
    ----            ------   ----      -----------
    Identifier Code 0        1 byte    See table below
    URI Field       1        N bytes   The rest of the URI (depending on byte 0 above)

The URI Identifier Code is use to shorten the URI length, and can have any of the following values:

    Value    Protocol
    -----    --------
    0x00     No prepending is done ... the entire URI is contained in the URI Field
    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:

Following the URI Identifier Code is the URI Field. This field provides the URI as per RFC 3987 and contains the rest of the URI after the value corresponding to the URI Identifier is prepended (unless the URI ID is 0x00, in which case the complete URI will be contained in the URI Field).

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

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.