Différences entre versions de « PN532-RFID-NFC-Format-NDEF »

De MCHobby - Wiki
Sauter à la navigation Sauter à la recherche
 
(18 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
 
{{PN532-RFID-NFC-NAV}}
 
{{PN532-RFID-NFC-NAV}}
−
 
−
{{traduction}}
 
  
 
== NDEF ==
 
== NDEF ==
Ligne 210 : Ligne 208 :
  
 
== Using Mifare Classic Cards as an NDEF Tag ==
 
== Using Mifare Classic Cards as an NDEF Tag ==
−
{{traduction}}
 
−
 
 
Les carte Mifare Classic 1K et 4K peuvent être configurées comme des tags NDEF compatible "NFC Forum" '''mais''' elles doivent être organisée d'une façon bien précise. Les exigences pour réaliser une carte Mifare "confirme NFC Forum" sont décrites dans les notes applicative de NXP (voir ci dessous):
 
Les carte Mifare Classic 1K et 4K peuvent être configurées comme des tags NDEF compatible "NFC Forum" '''mais''' elles doivent être organisée d'une façon bien précise. Les exigences pour réaliser une carte Mifare "confirme NFC Forum" sont décrites dans les notes applicative de NXP (voir ci dessous):
  
Ligne 228 : Ligne 224 :
  
 
=== Mifare Application Directory 1 (MAD1) ===
 
=== Mifare Application Directory 1 (MAD1) ===
−
{{traduction}}
+
"Mifare Application Directory" signifie ''Répertoire Applicatif Mifare''.
  
−
'''MAD1 can be used in any Mifare Classic card''' regardless of the size of the EEPROM, although if it is used with cards larger than 1KB only the first 1KB of memory will be accessible for NDEF records.
+
'''MAD1 peut être utilisé avec toutes les cartes Mifare Classic''' quelque soit la taille de EEPROM, bien que cela puisse être utilisé avec des cartes plus grande que 1KB seul le premier 1KB de mémoire sera accessible pour les enregistrements NDEF.
  
−
The MAD1 is stored in the Manufacturer Sector (Sector 0x00) on the Mifare Classic card.
+
Le MAD1 est stocké dans le secteur fabriquant (secteur ''Manufacturer'', secteur 0x00) sur la carte Mifare Classic.
  
 
=== Mifare Application Directory 2 (MAD2) ===
 
=== Mifare Application Directory 2 (MAD2) ===
−
MAD2 can only be used on Mifare Classic cards with '''more than 1KB of storage''' (Mifare Classic 4K cards, etc.). It is '''NOT''' compatible with cards containing only 1KB of memory!
+
MAD2 peut uniquement être utilisé avec les cartes Mifare Classic ayant '''plus de 1KB de mémoire de stockage''' (cartes Mifare Classic 4K, etc.). Il n'est '''PAS''' compatible avec les carte contenant uniquement 1KB de mémoire!
  
−
The MAD2 is stored in sectors 0x00 (the Manufacturer Sector) and 0x10.
+
Le MAD2 est stocké dans le secteur 0x00 (le secteur fabriquant, dit ''Manufacturer'') et le secteur 0x10.
  
 
=== MAD Sector Access ===
 
=== MAD Sector Access ===
−
The sectors containing the MAD1 (0x00) and MAD2 (0x00 and 0x10) are protected with a KEY A and KEY B (if you're not familiar with this concept, consult the Mifare Classic summary elsewhere in the PN532/NFC wiki). To ensure that these sectors can be read by any application, the following common KEY A should always be used:
+
Les secteurs contenant le MAD1 (0x00) et MAD2 (0x00 et 0x10) sont protégés à l'aide d'une clé A et clé B (''KEY A'' et ''KEY B'' en anglais, si vous n'êtes pas familiarisé avec ce concept, vous pouvez consulter le sommaire Mifare Classic ailleurs sur le wiki consacré au PN532/NFC).  
 +
 
 +
Pour assurer la lecture de ces secteurs par les applications, le clé A ''standard'' suivante devrait toujours être utilisée:
  
−
  <nowiki>  Public KEY A of MAD Sectors
+
  <nowiki>  Clé publique A pour les secteurs MAD
 
   CLE A publique des secteurs MAD
 
   CLE A publique des secteurs MAD
 
   ---------------------------------------------------
 
   ---------------------------------------------------
Ligne 248 : Ligne 246 :
 
   0xA0    0xA1    0xA2    0xA3    0xA4    0xA5</nowiki>
 
   0xA0    0xA1    0xA2    0xA3    0xA4    0xA5</nowiki>
  
−
The MAD sector may optionally be write-protected using KEY B if you wish to limit the ability of customers to modify the card contents. The public KEY A will ensure that they can always read the data.
+
Le secteur MAD peut éventuellement être protégé en écriture (''write-protected '') en utilisant la clé B si vous voulez limiter la capacité de modification de la carte (par les applications de vos consommateurs). La clé publique A assure que la carte puisse toujours lire les données.
  
−
== Storing NDEF Messages in Mifare Sectors ==
+
== Stocker des messages NDEF dans les secteurs Mifare ==
−
NDEF messages/records may be stored in any sector of the Mifare card, other than the sector(s) use by the MAD or sectors beyond the 1K range if a MAD1 table is used.  
+
Des messages/enregistrements NDEF peuvent être stockées dans n'importe quel secteur de la carte Mifare, autre que le(s) secteur(s) utilisé par MAD ou secteurs au-dela de l'espace 1K si la table MAD1 est utilisée).  
  
−
When a sector is used to store NDEF records, it is referred to as an NFC Sector. As with the MAD Sector(s) described above, these sectors must always be accessible in at least read-only mode, and as such a common public KEY A also exists for NFC Sectors, though it is not the same KEY A used in the MAD sector(s):  
+
Lorsqu'un secteur est utilisé pour stocker des enregistrements NDEF, il est appelé un "secteur NFC" (''NFC Sector''). Comme pour le(s) secteur(s) MAD décrit ci-dessus, ces secteurs doivent toujours être accessible -au moins- en lecture seule, et en conséquence une clé publique A standard existe également pour ces secteurs NFC. Notez qu'il ne s'agit pas exactement de la même clé A que pour les secteurs MAD:  
  
 
  <nowiki>  Public KEY A of NFC Sectors
 
  <nowiki>  Public KEY A of NFC Sectors
Ligne 261 : Ligne 259 :
 
   0xD3    0xF7    0xD3    0xF7    0xD3    0xF7</nowiki>
 
   0xD3    0xF7    0xD3    0xF7    0xD3    0xF7</nowiki>
  
−
In order to store an NDEF Message on the Mifare Classic card, the message needs to be wrapped inside something called a TLV Block. The basic structure of a '''TLV''' Block is described below.
+
Pour pouvoir stocker un message NDEF dans une carte Mifare Classic, le message doit être inclus (englobé) dans un bloc TLV. Les fondements de la structure d'un bloc '''TLV''' est décrit ci-dessous.
 +
 
 +
== Les blocs TLV ==
 +
TLV est l'abréviation correspondant à 3 champs différents:
 +
* '''T''' pour le champ Tag,
 +
* '''L''' pour la longueur du champ,
 +
* '''V''' pour le champ valeur.  
  
−
== TLV Blocks ==
+
Un bloc TLV est constitué d'un ou plusieurs octets/bytes, en fonction de ces trois champs présents.<br />Note que le bloc TLV aura toujours au moins un byte/octet étant donné que le champ T est obligatoire dans tous les cas.  
−
TLV is an abbreviation for three different fields: T for Tag Field, L for Length Field and V for Value Field. A TLV Block consist of one or more bytes, depending on which of these three fields is present. Note that the TLV Block will always be at least one byte since the T Field is mandatory in every case.  
 
  
−
=== Tag Field ===
+
=== Le champ Tag ===
−
The Tag Field (or T Field) is the only mandatory field, and uses a single-byte to identify the type of TLV block accordingly to a pre-determined table of values:  
+
Le champ Tag (ou champ T) est le seul champ obligatoire et utilise un seul octet pour identifier le bloc TLV. La valeur de T est prédéterminé, voyez la table ci-dessous pour les différentes valeurs disponibles:  
  
 
  <nowiki>TLV Block Types
 
  <nowiki>TLV Block Types
 
    
 
    
−
   Block Type   Value Description
+
   Type de bloc  Valeur Description
−
   ------------- ----- --------------------------------------
+
   ------------- -----   --------------------------------------
−
   NULL          0x00   These blocks should be ignored
+
   NULL          0x00   Ces blocs devraient être ignorés
−
   NDEF Message  0x03   Block contains an NDEF message
+
   NDEF Message  0x03   Le bloc contient un message NDEF
−
   Proprietary  0xFD   Block contains proprietary information
+
   Proprietary  0xFD   Le bloc contient des information propriétaires
−
   Terminator    0xFE   Last TLV block in the data area</nowiki>
+
   Terminator    0xFE   Dernier bloc TLV dans cette zone de donnée</nowiki>
  
−
=== Length Field ===
+
=== Le champ longueur ===
−
The Length Field (or L Field) contains the size (in bytes) of the value field. The Length Field can be organised in two different ways, using either one or three bytes.
+
Le champ longueur (''Length'' en anglais --ou-- champ L) contient la taille du champ valeur, taille exprimée en octets/bytes. Le champs longueur est organisé de deux façons différentes, en utilisant soit un ou 3 octets.
  
−
The one byte format simple contains a single byte value from 0x00..0xFF.
+
Le format '''un octet''' contient une simple valeur entre 0x00 et 0xFE (soit pour une valeur 0 et 254 exprimé en base 10).
  
−
The three byte format consists of the following format:
+
Le format '''trois octets''' est constitué du format suivant:
−
  <nowiki> Byte 0:      Always 0xFF to indicate that we are using the three byte format
+
  <nowiki> Octet 0:      Always 0xFF to indicate that we are using the three byte format
−
  Byte 1..2:    Can be a value between 0x00FF and 0xFFFE</nowiki>
+
Octet 1..2:    Peut être une valeur entre 0x00FF et 0xFFFE (soit entre 0 et 65534)</nowiki>
  
−
Both the one byte and three byte format must be supported for NFC Forum and NDEF compatability.
+
Les deux formats (1 et 3 octets) doivent supporter la compatibilité pour NDEF et NFC Forum.
  
−
=== Value Field ===
+
=== Champ valeur (value) ===
−
The Value Field (or V Field) is only present if the Length Field (described above) is present and not equal to 0x00. If the Length Field is not equal to 0, the Value Fields will contain N bytes of data in the format indicated by the T Field above.
+
Le champ valeur (''Value Field'' en anglais, ou encore 'V') est uniquement présent sur le champ longueur (''Length Field'', décrit ci-dessus) est présent and différent de 0x00.  
  
−
The value field is where the payload (an '''NDEF Message''', for example) is stored.
+
Si le champs longueur n'est plus grand que 0 alors le champ valeur (''Value'') contient les N octets/bytes de données au format indiqué par le champs T (ci-dessus).
 +
 
 +
Le champs valeur est l'endroit où la charge de donnée (''payload'') est stockée. Par exemple, un '''message NDEF'''.
  
 
=== Terminator TLV ===
 
=== Terminator TLV ===
−
The Terminator TLV is the last TLV block in the data area, and consist of a single byte: 0x0FE (see the TLV Block Type table above). This TLV Block in mandatory.
+
Le terminateur TLV (le ''TLV terminator'') est le dernier bloc TLV dans la zone de donnée et est composé d'un simple octet/byte: 0x0FE (voyez la table des 'types de bloc TLV' ci-dessus). '''Ce bloc TLV est obligatoire'''.
  
 
== Dump mémoire d'une Mifare Classic NDEF ==
 
== Dump mémoire d'une Mifare Classic NDEF ==
Ligne 388 : Ligne 393 :
  
 
=== Enregistrement 1 ===
 
=== Enregistrement 1 ===
−
The first record on the card can be identified by looking at the first byte of block 4 in sector 1.
+
Le premier enregistrement sur la carte peut être identifier en regardant le premier octet/byte du bloc 4 sur le secteur 1.
  
 
  <nowiki>Block  00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15  Char Value
 
  <nowiki>Block  00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15  Char Value
Ligne 394 : Ligne 399 :
 
04    00 00                                            ..</nowiki>
 
04    00 00                                            ..</nowiki>
  
−
Every record on the Mifare card starts with the '''TLV Block''' (described above), and the first byte of the TLV Block (the Tag Field) indicates that this is a '''NULL Block type (value 0x00)'''. The second byte is the Length Field, and is 0. Since there is no payload for this record (Length = 0), the third byte of the TLV block is not present (the Value Field).
+
Chaque enregistrement sur une carte MiFare commence avec un '''block TLV''' (décrit ci-avant dans le tutoriel).
 +
* Le premier octet/byte d'un block TLV (le champs 'Tag') indique qu'il s'agit d'un '''bloc de type NULL''' (valeur 0x00, ''NULL Block type '').  
 +
* Le second octet/byte indique la longueur du champ... qui est 0.
 +
 
 +
Etant donné qu'il n'y a pas de ''payload'' (charge de donnée) pour cet enregistrement (Longueur = 0), le troisième octet/byte du bloc TLV n'est pas présent (le champ valeur/value).
  
−
This record was likely inserted when the card was first formatted to ensure that at least one record is present.
+
Cet enregistrement est 'insérer' lors du premier formatage de la carte pour assurer qu'il y ait au moins un enregistrement présent sur la carte.
  
 
=== Enregistrement 2 ===
 
=== Enregistrement 2 ===
−
The second record on the card starts at byte 0x02 of block 4 and continues into block 5.
+
Le second enregistrement de la carte commence à l'octet/byte 0x02 du bloc 4 et continue dans le bloc 5.
  
−
  <nowiki>Block  00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15  Char Value
+
  <nowiki>Bloc  00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15  Valeur caractère/Char Value
 
-----  -----------------------------------------------  ------------
 
-----  -----------------------------------------------  ------------
 
04          03 11 D1 01 0D 55 01 61 64 61 66 72 75 69  Ñ..U.adafrui
 
04          03 11 D1 01 0D 55 01 61 64 61 66 72 75 69  Ñ..U.adafrui
 
05    74 2E 63 6F 6D                                  t.com</nowiki>
 
05    74 2E 63 6F 6D                                  t.com</nowiki>
  
−
Starting with les données du '''bloc TLV''' in the first two bytes, we can determine the following:  
+
Il commence avec les données du '''bloc TLV''' dans les deux premiers octets/bytes, nous pouvons déterminer les informations suivante:  
  
−
  <nowiki>Byte(s)   Value  Description
+
  <nowiki>octet(s) Valeur  Description
 
-------  -----  -----------
 
-------  -----  -----------
−
04:02    0x03    Field Type (0x03 = NDEF Message)
+
04:02    0x03    Type de champ (0x03 = Message NDEF)
−
04:03    0x11    Length Field (17 bytes)</nowiki>
+
04:03    0x11    Longueur du champ (17 octets/bytes)</nowiki>
  
−
This indicates to us that the record contains an '''NDEF Message''' (value 0x03), and that the message is 17 bytes long (0x11 in hexadecimal = 17 in decimal value). This means that our NDEF message is contained in the next 17 bytes (04:04..05:04). The NDEF record can then be analysed as follows:
+
Qui nous indique que l'enregistrement contient un '''message NDEF''' (valeur 0x03), et que le message fait 17 octets/bytes de long (0x11 en hexadécimal, soit la valeur 17 en décimal). Cela signifie que notre message NDEF est contenu dans les 17 octets/bytes suivants (de 04:04 à 05:04).  
  
−
  <nowiki>Byte(s)       Value  Description
+
L'enregistrement NDEF peut alors être analysé comme suit:
 +
 
 +
  <nowiki>Octet(s)     Valeur Description
 
-------      -----  -----------
 
-------      -----  -----------
−
04:04        0xD1  This byte is the **NDEF Record Header**, and indicates that this is
+
04:04        0xD1  Cet octet/bytes est **l'entête d'enregistrement NDEF**,  
−
                     an NFC Forum Well Known Record (0x01 in the first 3 bits),  
+
                     et indique qu'il s'agit d'un enregistrement bien connu
−
                     and that this is the first and last record (MB=1, ME=1),
+
                    (Well Known Record) du Forum NDEF (0x01 dans les 3 premiers bits),  
−
                     and that this is a short record (SR = 1) meaning the payload
+
                     et il n'agit du premier et dernier enregistrement (MB=1, ME=1),
−
                     length is less than or equal to 255 chars (len=one byte).
+
                     et c'est un record "court" (short record, SR=1) signifiant que
 +
                    la charge de donnée (payload) fait moins de 256 caractères
 +
                     (longueur=un octet/byte).
 +
 
 
                     TNF = 0x01 (NFC Forum Well Known Type)
 
                     TNF = 0x01 (NFC Forum Well Known Type)
−
                     IL  = 0    (No ID present, meaning there is no ID Length or ID Field either)
+
                     IL  = 0    (Pas d'ID présent, donc pas de champs 'ID Length' et 'ID')
−
                     SR  = 1    (Short Record)
+
                     SR  = 1    (Enregistrement court, Short Record)
−
                     CF  = 0    (Record is not 'chunked')
+
                     CF  = 0    (L'enregistrement n'est pas coupé en morceau, record is not 'chunked')
−
                     ME  = 1    (End of message)
+
                     ME  = 1    (Fin de message, Message End)
−
                     MB  = 1    (Beginning of message)
+
                     MB  = 1    (Début de message, Message Begin)
−
04:05        0x01  This byte is the **Type Length** for the Record Type Indicator
+
04:05        0x01  Cet octet/byte est la longueur du type **Type Length**  
−
                     (see above for more information), which is 1 byte (0x55/'U' below)
+
                    pour le type d'enregistrement (Record Type)
−
04:06        0x0D  This is the payload length (13 bytes)
+
                     (voir ci-dessus pour plus d'information.
−
04:07        0x55  Record Type Indicator (0x55 or 'U' = URI Record)
+
                    Fait 1 octet/byte (0x55/'U' ci-dessous)
−
04:08        0x01  This is the **start of the record payload**, which contains the
+
04:06        0x0D  Longueur de la charge de donnée (payload), soit 13 octets/bytes
−
                     URI Identifier ("http://www.") since this is a URI Well-Defined
+
04:07        0x55  Type d'enregistrement (0x55 ou 'U' = enregistrement URI)
−
                     Record Type (see Well-Defined Records above).  This will be
+
04:08        0x01  Ceci est le **début de la charge de donnée (payload)**, qui contient
−
                     prepended to the rest of the URI that follows in the rest of the
+
                     l'identification d'URI ("http://www.") étant donné qu'il s'agit d'un
−
                    message payload
+
                    type d'enregistrement bien connu de type URI (URI Well-Defined
−
04:09..05:04  ...    The remainder of the URI ("adafruit.com"), which combined with the
+
                     Record Type, voir ci-avant pour les explications).  Le préfixe sera
−
                     pre-pended value from byte 04:08 yields: http://www.adafruit.com</nowiki>
+
                     ajouté au restant de l'URI contenu dans le reste du 'payload'
 +
04:09..05:04  ...    Le reste de l'URI ("adafruit.com"), qui est combiné avec le préfix
 +
                     ajouté suivant la valeur de l'octet/byte 04:08 .
 +
                    Cela donne: http://www.adafruit.com</nowiki>
  
−
=== TLV Terminator ===
+
=== Le terminateur TLV ===
 +
Egalement appelé ''TLV Terminator'' en anglais.
  
−
  <nowiki>Block  00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15  Char Value
+
  <nowiki>Bloc  00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15  Valeur en caractère
 
-----  -----------------------------------------------  ------------
 
-----  -----------------------------------------------  ------------
 
05                    FE                                þ</nowiki>
 
05                    FE                                þ</nowiki>
  
−
The final byte (block 5, byte 5), with the value 0xFE, is the '''TLV Terminator''' and indicates that this is the end of the TLV Block.  
+
L'octet/byte final (bloc 5, octet/byte 5) qui à la valeur 0xFE est le '''TLV Terminator''' qui indique que ceci est la fin du bloc TLV.  
−
 
 
−
{{traduction}}
 
−
 
 
  
 
{{PN532-RFID-NFC-TRAILER}}
 
{{PN532-RFID-NFC-TRAILER}}

Version actuelle datée du 26 octobre 2015 à 09:18


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.

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 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

Un exemple d'enregistrement URI est visible dans "le dump mémoire d'une carte Mifare Classic 1K avec un enregistrement NDEF" ci-dessous. A faire...

Text Record

A faire...

Smartposter Record

A faire...

Absolute URI Record

A faire...

Using Mifare Classic Cards as an NDEF Tag

Les carte Mifare Classic 1K et 4K peuvent être configurées comme des tags NDEF compatible "NFC Forum" mais elles doivent être organisée d'une façon bien précise. Les exigences pour réaliser une carte Mifare "confirme NFC Forum" sont décrites dans les notes applicative de NXP (voir ci dessous):

Alors que les notes ci-dessous est une source faisant "autorité" en la matière, les notes suivantes offrent un survol rapide des prinicpaux concepts impliqués si l'on désire réaliser un tag Mifare Classic compatible 'NDEF':

Mifare Application Directory (MAD)

La structure Mifare Application Directory (MAD, répertoire applicatif Mifare) est utilisé pour permettre l'établissement d'une "liaison"/échange entre une mémoire organisée en secteur (celle de la carte Mifare Classic) ET et des enregistrements NDEF individuels.

La structure MAD indique "quel secteur" contient "tel enregistrement NDEF". Vous trouverez toutes les informations sur MAD (Mifare Application Directory) dans les notes applicatives suivantes:

Cette reférence mélange les deux types de MAD (dépendant de la taille de la carte en question) comme définit ci-dessous:

Mifare Application Directory 1 (MAD1)

"Mifare Application Directory" signifie Répertoire Applicatif Mifare.

MAD1 peut être utilisé avec toutes les cartes Mifare Classic quelque soit la taille de EEPROM, bien que cela puisse être utilisé avec des cartes plus grande que 1KB seul le premier 1KB de mémoire sera accessible pour les enregistrements NDEF.

Le MAD1 est stocké dans le secteur fabriquant (secteur Manufacturer, secteur 0x00) sur la carte Mifare Classic.

Mifare Application Directory 2 (MAD2)

MAD2 peut uniquement être utilisé avec les cartes Mifare Classic ayant plus de 1KB de mémoire de stockage (cartes Mifare Classic 4K, etc.). Il n'est PAS compatible avec les carte contenant uniquement 1KB de mémoire!

Le MAD2 est stocké dans le secteur 0x00 (le secteur fabriquant, dit Manufacturer) et le secteur 0x10.

MAD Sector Access

Les secteurs contenant le MAD1 (0x00) et MAD2 (0x00 et 0x10) sont protégés à l'aide d'une clé A et clé B (KEY A et KEY B en anglais, si vous n'êtes pas familiarisé avec ce concept, vous pouvez consulter le sommaire Mifare Classic ailleurs sur le wiki consacré au PN532/NFC).

Pour assurer la lecture de ces secteurs par les applications, le clé A standard suivante devrait toujours être utilisée: 

  Clé publique A pour les secteurs MAD
   CLE A publique des secteurs MAD
  ---------------------------------------------------
  BYTE 0   BYTE 1   BYTE 2   BYTE 3   BYTE 4   BYTE 5
  0xA0     0xA1     0xA2     0xA3     0xA4     0xA5

Le secteur MAD peut éventuellement être protégé en écriture (write-protected ) en utilisant la clé B si vous voulez limiter la capacité de modification de la carte (par les applications de vos consommateurs). La clé publique A assure que la carte puisse toujours lire les données.

Stocker des messages NDEF dans les secteurs Mifare

Des messages/enregistrements NDEF peuvent être stockées dans n'importe quel secteur de la carte Mifare, autre que le(s) secteur(s) utilisé par MAD ou secteurs au-dela de l'espace 1K si la table MAD1 est utilisée).

Lorsqu'un secteur est utilisé pour stocker des enregistrements NDEF, il est appelé un "secteur NFC" (NFC Sector). Comme pour le(s) secteur(s) MAD décrit ci-dessus, ces secteurs doivent toujours être accessible -au moins- en lecture seule, et en conséquence une clé publique A standard existe également pour ces secteurs NFC. Notez qu'il ne s'agit pas exactement de la même clé A que pour les secteurs MAD: 

  Public KEY A of NFC Sectors
  CLE A plubique des secteurs NFC
  ---------------------------------------------------
  BYTE 0   BYTE 1   BYTE 2   BYTE 3   BYTE 4   BYTE 5
  0xD3     0xF7     0xD3     0xF7     0xD3     0xF7

Pour pouvoir stocker un message NDEF dans une carte Mifare Classic, le message doit être inclus (englobé) dans un bloc TLV. Les fondements de la structure d'un bloc TLV est décrit ci-dessous.

Les blocs TLV

TLV est l'abréviation correspondant à 3 champs différents:

  • T pour le champ Tag,
  • L pour la longueur du champ,
  • V pour le champ valeur.

Un bloc TLV est constitué d'un ou plusieurs octets/bytes, en fonction de ces trois champs présents.
Note que le bloc TLV aura toujours au moins un byte/octet étant donné que le champ T est obligatoire dans tous les cas.

Le champ Tag

Le champ Tag (ou champ T) est le seul champ obligatoire et utilise un seul octet pour identifier le bloc TLV. La valeur de T est prédéterminé, voyez la table ci-dessous pour les différentes valeurs disponibles: 

TLV Block Types
  
  Type de bloc  Valeur  Description
  ------------- -----   --------------------------------------
  NULL          0x00    Ces blocs devraient être ignorés
  NDEF Message  0x03    Le bloc contient un message NDEF
  Proprietary   0xFD    Le bloc contient des information propriétaires
  Terminator    0xFE    Dernier bloc TLV dans cette zone de donnée

Le champ longueur

Le champ longueur (Length en anglais --ou-- champ L) contient la taille du champ valeur, taille exprimée en octets/bytes. Le champs longueur est organisé de deux façons différentes, en utilisant soit un ou 3 octets.

Le format un octet contient une simple valeur entre 0x00 et 0xFE (soit pour une valeur 0 et 254 exprimé en base 10).

Le format trois octets est constitué du format suivant: 

 Octet 0:       Always 0xFF to indicate that we are using the three byte format
 Octet 1..2:    Peut être une valeur entre 0x00FF et 0xFFFE (soit entre 0 et 65534)

Les deux formats (1 et 3 octets) doivent supporter la compatibilité pour NDEF et NFC Forum.

Champ valeur (value)

Le champ valeur (Value Field en anglais, ou encore 'V') est uniquement présent sur le champ longueur (Length Field, décrit ci-dessus) est présent and différent de 0x00.

Si le champs longueur n'est plus grand que 0 alors le champ valeur (Value) contient les N octets/bytes de données au format indiqué par le champs T (ci-dessus).

Le champs valeur est l'endroit où la charge de donnée (payload) est stockée. Par exemple, un message NDEF.

Terminator TLV

Le terminateur TLV (le TLV terminator) est le dernier bloc TLV dans la zone de donnée et est composé d'un simple octet/byte: 0x0FE (voyez la table des 'types de bloc TLV' ci-dessus). Ce bloc TLV est obligatoire.

Dump mémoire d'une Mifare Classic NDEF

Voici le dump mémoire d'une carte Mifare classique ayant un enregistrement NDEF 

[                      Début du mémoire                             ]
------------------------Secteur 0-------------------------
Block 0  3E 39 AB 7F D3 88 04 00 47 41 16 57 4D 10 34 08  >9«?Ó?..GA.WM.4.
Block 1  14 01 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1  ...á.á.á.á.á.á.á
Block 2  03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1  .á.á.á.á.á.á.á.á
Block 3  00 00 00 00 00 00 78 77 88 C1 00 00 00 00 00 00  ......xw?Á......
------------------------Secteur 1-------------------------
Block 4  00 00 03 11 D1 01 0D 55 01 61 64 61 66 72 75 69  ....Ñ..U.adafrui
Block 5  74 2E 63 6F 6D FE 00 00 00 00 00 00 00 00 00 00  t.comþ..........
Block 6  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 7  00 00 00 00 00 00 7F 07 88 40 00 00 00 00 00 00  ......?.?@......
------------------------Secteur 2-------------------------
Block 8  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 9  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 11 00 00 00 00 00 00 7F 07 88 40 00 00 00 00 00 00  ......?.?@......
------------------------Secteur 3-------------------------
Block 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 13 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 15 00 00 00 00 00 00 7F 07 88 40 00 00 00 00 00 00  ......?.?@......
------------------------Secteur 4-------------------------
Block 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 19 00 00 00 00 00 00 7F 07 88 40 00 00 00 00 00 00  ......?.?@......
------------------------Secteur 5-------------------------
Block 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 22 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 23 00 00 00 00 00 00 7F 07 88 40 00 00 00 00 00 00  ......?.?@......
------------------------Secteur 6-------------------------
Block 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 26 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 27 00 00 00 00 00 00 7F 07 88 40 00 00 00 00 00 00  ......?.?@......
------------------------Secteur 7-------------------------
Block 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 29 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 31 00 00 00 00 00 00 7F 07 88 40 00 00 00 00 00 00  ......?.?@......
------------------------Secteur 8-------------------------
Block 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 35 00 00 00 00 00 00 7F 07 88 40 00 00 00 00 00 00  ......?.?@......
------------------------Secteur 9-------------------------
Block 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 37 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 39 00 00 00 00 00 00 7F 07 88 40 00 00 00 00 00 00  ......?.?@......
------------------------Secteur 10-------------------------
Block 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 43 00 00 00 00 00 00 7F 07 88 40 00 00 00 00 00 00  ......?.?@......
------------------------Secteur 11-------------------------
Block 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 45 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 46 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 47 00 00 00 00 00 00 7F 07 88 40 00 00 00 00 00 00  ......?.?@......
------------------------Secteur 12-------------------------
Block 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 49 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 51 00 00 00 00 00 00 7F 07 88 40 00 00 00 00 00 00  ......?.?@......
------------------------Secteur 13-------------------------
Block 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 53 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 55 00 00 00 00 00 00 7F 07 88 40 00 00 00 00 00 00  ......?.?@......
------------------------Secteur 14-------------------------
Block 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 57 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 58 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 59 00 00 00 00 00 00 7F 07 88 40 00 00 00 00 00 00  ......?.?@......
------------------------Secteur 15-------------------------
Block 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 62 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Block 63 00 00 00 00 00 00 7F 07 88 40 00 00 00 00 00 00  ......?.?@......
[                        Fin du dump mémoire                              ]

L'exemple ci-dessus contient deux enregistrements, tout deux localisé dans le secteur 1 (le secteur 0 contenant le MAD).

Voici comment les données sont organisées:

Enregistrement 1

Le premier enregistrement sur la carte peut être identifier en regardant le premier octet/byte du bloc 4 sur le secteur 1. 

Block  00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15  Char Value
-----  -----------------------------------------------  ------------
04     00 00                                            ..

Chaque enregistrement sur une carte MiFare commence avec un block TLV (décrit ci-avant dans le tutoriel).

  • Le premier octet/byte d'un block TLV (le champs 'Tag') indique qu'il s'agit d'un bloc de type NULL (valeur 0x00, NULL Block type ).
  • Le second octet/byte indique la longueur du champ... qui est 0.

Etant donné qu'il n'y a pas de payload (charge de donnée) pour cet enregistrement (Longueur = 0), le troisième octet/byte du bloc TLV n'est pas présent (le champ valeur/value).

Cet enregistrement est 'insérer' lors du premier formatage de la carte pour assurer qu'il y ait au moins un enregistrement présent sur la carte.

Enregistrement 2

Le second enregistrement de la carte commence à l'octet/byte 0x02 du bloc 4 et continue dans le bloc 5. 

Bloc   00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15  Valeur caractère/Char Value
-----  -----------------------------------------------  ------------
04           03 11 D1 01 0D 55 01 61 64 61 66 72 75 69  Ñ..U.adafrui
05     74 2E 63 6F 6D                                   t.com

Il commence avec les données du bloc TLV dans les deux premiers octets/bytes, nous pouvons déterminer les informations suivante: 

octet(s)  Valeur  Description
-------   -----   -----------
04:02     0x03    Type de champ (0x03 = Message NDEF)
04:03     0x11    Longueur du champ (17 octets/bytes)

Qui nous indique que l'enregistrement contient un message NDEF (valeur 0x03), et que le message fait 17 octets/bytes de long (0x11 en hexadécimal, soit la valeur 17 en décimal). Cela signifie que notre message NDEF est contenu dans les 17 octets/bytes suivants (de 04:04 à 05:04).

L'enregistrement NDEF peut alors être analysé comme suit: 

Octet(s)      Valeur Description
-------       -----  -----------
04:04         0xD1   Cet octet/bytes est **l'entête d'enregistrement NDEF**, 
                     et indique qu'il s'agit d'un enregistrement bien connu
                     (Well Known Record) du Forum NDEF (0x01 dans les 3 premiers bits), 
                     et il n'agit du premier et dernier enregistrement (MB=1, ME=1),
                     et c'est un record "court" (short record, SR=1) signifiant que
                     la charge de donnée (payload) fait moins de 256 caractères
                     (longueur=un octet/byte).

                     TNF = 0x01 (NFC Forum Well Known Type)
                     IL  = 0    (Pas d'ID présent, donc pas de champs 'ID Length' et 'ID')
                     SR  = 1    (Enregistrement court, Short Record)
                     CF  = 0    (L'enregistrement n'est pas coupé en morceau, record is not 'chunked')
                     ME  = 1    (Fin de message, Message End)
                     MB  = 1    (Début de message, Message Begin)
04:05         0x01   Cet octet/byte est la longueur du type **Type Length** 
                     pour le type d'enregistrement (Record Type)
                     (voir ci-dessus pour plus d'information.
                     Fait 1 octet/byte  (0x55/'U' ci-dessous)
04:06         0x0D   Longueur de la charge de donnée (payload), soit 13 octets/bytes
04:07         0x55   Type d'enregistrement (0x55 ou 'U' = enregistrement URI)
04:08         0x01   Ceci est le **début de la charge de donnée (payload)**, qui contient
                     l'identification d'URI ("http://www.") étant donné qu'il s'agit d'un 
                     type d'enregistrement bien connu de type URI (URI Well-Defined
                     Record Type, voir ci-avant pour les explications).  Le préfixe sera
                     ajouté au restant de l'URI contenu dans le reste du 'payload'
04:09..05:04  ...    Le reste de l'URI ("adafruit.com"), qui est combiné avec le préfix
                     ajouté suivant la valeur de l'octet/byte 04:08 .
                     Cela donne: http://www.adafruit.com

Le terminateur TLV

Egalement appelé TLV Terminator en anglais. 

Bloc   00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15  Valeur en caractère
-----  -----------------------------------------------  ------------
05                    FE                                þ

L'octet/byte final (bloc 5, octet/byte 5) qui à la valeur 0xFE est le TLV Terminator qui indique que ceci est la fin du bloc TLV.

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.

Récupérée de « https://wiki.mchobby.be/index.php?title=PN532-RFID-NFC-Format-NDEF&oldid=16324 »