29 918
modifications
Modifications
Sauter à la navigation
Sauter à la recherche
Ligne 2 :
Ligne 2 : + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
aucun résumé de modification
{{traduction}}
{{traduction}}
== NDEF ==
{{bloc-etroit|text=NDEF est l'accronyme de '''''N'''FC '''D'''ata '''E'''xchange '''F'''ormat'' signifiant "format d'échange de donnée NFC".
The NFC Data Exchange Format (NDEF) is a standardised data format that can be used to exchange information between any compatible NFC device and another NFC device or tag. The data format consists of '''NDEF Messages''' (messages NDEF) and '''NDEF Records''' (enregistrement NDEF). The standard is maintained by the NFC Forum and is freely available for consultation but requires accepting a license agreement to [http://www.nfc-forum.org/specs/spec_list/ download].
The NDEF format is used to store and exchange information like URIs, plain text, etc., using a commonly understood format. NFC tags like Mifare Classic cards can be configured as NDEF tags, and data written to them by one NFC device (NDEF Records) can be understood and accessed by any other NDEF compatible device. NDEF messages can also be used to exchange data between two active NFC devices in "peer-to-peer" mode. By adhering to the NDEF data exchange format during communication, devices that would otherwise have no meaningful knowledge of each other or common language are able to share data in an organised, mutually understandable manner.
Some helpful app notes and white papers relating to NDEF are listed below:
* [http://www.nfc-forum.org/specs/spec_list/ NFC Data Exchange Format (NDEF) Technical Specification] (requires accepting the license terms)
* [http://www.nfc-forum.org/specs/spec_list/ NFC Record Type Definition (RTD) Specification] (requires accepting the license terms)
* [http://www.nxp.com/acrobat_download2/other/identification/173110_NFC_Forum_Type_Tags_WhitePaper.pdf NXP White Paper - NFC Forum Type Tags]
== Messages NDEF ==
NDEF Messages are the basic "transportation" mechanism for NDEF records, with each message containing one or more NDEF Records.
== Enregistrements NDEF ==
Les enregistrements NDEF (dit "''NDEF Records''") contain a specific payload, and have the following structure that identifies the contents and size of the record:
<nowiki> Bit 7 6 5 4 3 2 1 0
------ ------ ------ ------ ------ ------ ------ ------
[ MB ] [ ME ] [ CF ] [ SR ] [ IL ] [ TNF ]
[ TYPE LENGTH ]
[ PAYLOAD LENGTH ]
[ ID LENGTH ]
[ RECORD TYPE ]
[ ID ]
[ PAYLOAD ]</nowiki>
=== L'entête (octet 0)===
Aussi appelé "''record header''" contains a number of important fields, including a 3-bit field that identifies the type of record that follows (the '''Type Name Format''' or TNF que nous traduirons par "''le nom du type de format''"):
==== Le champs TNF ====
The Type Name Format or TNF Field of an NDEF record is a 3-bit value that describes the record type, and sets the expectation for the structure and content of the rest of the record. Possible record type names include:
<nowiki> TNF Value Record Type
--------- -----------------------------------------
0x00 Empty Record
Indicates no type, id, or payload is associated with this NDEF Record.
This record type is useful on newly formatted cards since every NDEF tag
must have at least one NDEF Record.
0x01 Well-Known Record
Indicates the type field uses the RTD type name format. This type name is used
to stored any record defined by a Record Type Definition (RTD), such as storing
RTD Text, RTD URIs, etc., and is one of the mostly frequently used and useful
record types.
0x02 MIME Media Record
Indicates the payload is an intermediate or final chunk of a chunked NDEF Record
0x03 Absolute URI Record
Indicates the type field contains a value that follows the absolute-URI BNF
construct defined by RFC 3986
0x04 External Record
Indicates the type field contains a value that follows the RTD external
name specification
0x05 Unknown Record
Indicates the payload type is unknown
0x06 Unchanged Record
Indicates the payload is an intermediate or final chunk of a chunked NDEF Record</nowiki>
==== IL: champ ID LENGTH ====
IL est l'acronyme de '''''I'''D '''L'''ength'', c'est un flag (''drapeau'') indiquant si le champ "ID Length Field" est présent ou non. {{traduction}} If this is set to 0, then the ID Length Field is ommitted in the record.
==== SR: Short Record Bit ====
The SR flag is set to one if the PAYLOAD LENGTH field is 1 byte (8 bits/0-255) or less. This allows for more compact records.
CF: Chunk Flag ====
The CF flag indicates if this is the first record chunk or a middle record chunk.
==== ME: Message End ====
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.
=== Type Length ===
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.
=== 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===
Indicates the length in bytes of the ID field. 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:
<nowiki> 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)</nowiki>
The '''URI Identifier Code''' is use to shorten the URI length, and can have any of the following values:
<nowiki> 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:</nowiki>
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 ===
<small>A faire...</small>
=== Smart Poster Records ===
<small>A faire...</small>
== 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.
<small>A faire...</small>
==== Text Record ====
<small>A faire...</small>
==== Smartposter Record ====
<small>A faire...</small>
==== Absolute URI Record ====
<small>A faire...</small>
== 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:
[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:
[http://www.nxp.com/documents/application_note/AN10787.pdf 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) ===
{{traduction}}
{{PN532-RFID-NFC-TRAILER}}
{{PN532-RFID-NFC-TRAILER}}