29 917
modifications
Modifications
Sauter à la navigation
Sauter à la recherche
Ligne 1 :
Ligne 1 : − − {{traduction}} Ligne 99 :
Ligne 97 : − + − {{traduction}}+ − The ME flag indicates if this is the last record in the message.MB: Message BeginThe MB flag indicates if this is the start of an NDEF message.+ + + + − Indicates the length (in bytes) of the Record Type field. This value is always zero for certain types of records defined with the TNF Field described above.+ − 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.+ − + − {{traduction}}+ − − 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.+ − 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.+ − The record payload, which will be exactly the number of bytes described in the Payload Length field earlier.+ − 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:+ + + + + + + − 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.+ − + − + − + − + − The '''URI Identifier Code''' is use to shorten the URI length, and can have any of the following values: + − + − + Ligne 178 :
Ligne 184 : − 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). + Ligne 189 :
Ligne 195 : − An example of a URI record is shown in "Memory Dump of a Mifare Classic 1K Card with an NDEF Record" below.+ Ligne 202 :
Ligne 208 : − + + + − [http://www.nxp.com/documents/application_note/AN1304.pdf 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: − + − For reference sake, the two types of MADs (depending on the size of the card in question) are defined below:+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + − {{traduction}}+ + + +
PN532-RFID-NFC-Format-NDEF (voir la source)
Version du 26 octobre 2015 à 09:18
, 26 octobre 2015 à 09:18aucun résumé de modification
{{PN532-RFID-NFC-NAV}}
{{PN532-RFID-NFC-NAV}}
== NDEF ==
== NDEF ==
==== ME: Message End ====
==== ME: Message End ====
Drapeau/Flag "fin de message".
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 ===
=== 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 ===
=== 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===
=== 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'').
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 ===
=== 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 ===
=== 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 ===
=== 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) ==
== 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 ('''R'''ecord '''T'''ype '''D'''efinition 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') ===
=== 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.
URI Records are defined in the document "URI Record Type Definition" from the NFC Forum, and it has the following structure:
Les enregistrement URI sont définit dans le document "URI Record Type Definition" du Forum NFC. Cet enregistrement à la structure suivante:
<nowiki> Name Offset Size Description
<nowiki> Nom Offset Taille Description
---- ------ ---- -----------
---- ------ ---- -----------
Identifier Code 0 1 byte See table below
Identifier Code 0 1 octet Code d'identification de l'URI, Voir la table ci-dessous
URI Field 1 N bytes The rest of the URI (depending on byte 0 above)</nowiki>
Champ URI 1 N octets Le reste de l'URI (dépend de l'octet/byte 0 ci-dessus)</nowiki>
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:
<nowiki> Value Protocol
<nowiki> Valeur Protocole
----- --------
----- --------
0x00 No prepending is done ... the entire URI is contained in the URI Field
0x00 Pas d'utilisation de préfix... l'URI est entièrement inclus dans le champ URI
0x01 http://www.
0x01 http://www.
0x02 https://www.
0x02 https://www.
0x23 urn:nfc:</nowiki>
0x23 urn:nfc:</nowiki>
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 ===
=== Test Records ===
=== Well Known Records ===
=== Well Known Records ===
==== URI Record ====
==== 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.
<small>A faire...</small>
<small>A faire...</small>
== Using Mifare Classic Cards as an NDEF Tag ==
== 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:
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):
* [http://www.nxp.com/documents/application_note/AN1304.pdf AN1304 - NFC Type MIFARE Classic Tag Operation]
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:
[http://www.nxp.com/documents/application_note/AN10787.pdf AN10787 - MIFARE Application Directory (MAD)]
* [http://www.nxp.com/documents/application_note/AN10787.pdf AN10787 - MIFARE Application Directory (MAD)]
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 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:
<nowiki> 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</nowiki>
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:
<nowiki> 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</nowiki>
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.<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.
=== 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:
<nowiki>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</nowiki>
=== 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:
<nowiki> 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)</nowiki>
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
<nowiki>[ 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 ]</nowiki>
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.
<nowiki>Block 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 Char Value
----- ----------------------------------------------- ------------
04 00 00 ..</nowiki>
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.
<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
05 74 2E 63 6F 6D t.com</nowiki>
Il commence avec les données du '''bloc TLV''' dans les deux premiers octets/bytes, nous pouvons déterminer les informations suivante:
<nowiki>octet(s) Valeur Description
------- ----- -----------
04:02 0x03 Type de champ (0x03 = Message NDEF)
04:03 0x11 Longueur du champ (17 octets/bytes)</nowiki>
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:
<nowiki>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</nowiki>
=== Le terminateur TLV ===
Egalement appelé ''TLV Terminator'' en anglais.
<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>
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.
{{PN532-RFID-NFC-TRAILER}}
{{PN532-RFID-NFC-TRAILER}}