NFC技术规范详解：NDEF Technical Specification

需积分: 10 20 浏览量更新于2024-07-23 收藏 612KB PDF 举报

"NFC技术规范(英文版)，包含NFCDataExchangeFormat(NDEF)的技术细节" NFC（Near Field Communication）是一种短距离无线通信技术，它允许电子设备在靠近时进行数据交换。NFC技术规范是定义了这项技术如何运作的官方文档，由NFC ForumTM发布，版本为NDEF 1.0，日期为2006年7月24日。这个规范主要关注NFCDataExchangeFormat（NDEF），这是NFC中用于数据传输的标准格式。 NDEF（NFC Data Exchange Format）是NFC技术的核心部分，它定义了如何在不同的NFC设备之间传递数据。NDEF消息可以包含各种类型的数据，如文本、URI、智能卡模拟数据、图片等。它的设计目标是简单、可扩展，并且与不同操作系统和应用兼容。 NDEF规范中包含了以下几个关键概念： 1. **NDEF消息（NDEF Message）**：一个NDEF消息由一个或多个NDEF记录（NDEF Records）组成。每个记录可以携带不同类型的数据，并且可以设置不同的属性，如类型、标识符和数据。 2. **NDEF记录（NDEF Record）**：每个NDEF记录都包含一个类型字段，用于识别数据类型；一个标识符字段，可以用来区分相同类型的数据；以及一个数据字段，用于存储实际的信息。 3. **NDEF记录类型**：NDEF支持多种预定义的记录类型，例如，Text类型用于存储文本信息，URI类型用于存储网址，Smart Poster类型可以包含一个URI和附加信息，如动作指示。 4. **兼容性**：NDEF被设计成跨平台兼容，这意味着任何支持NDEF的设备都能读取和写入NDEF消息，无论设备使用的是Android、iOS、Windows或其他操作系统。 5. **安全性**：虽然NDEF本身不包含内置的安全机制，但可以通过其他协议层来增强安全，例如使用加密的通信通道。 6. **可扩展性**：NDEF规范允许定义新的自定义记录类型，以适应未来可能出现的新需求和技术发展。 7. **限制使用**：NFC Forum拥有NFC技术规范的版权，并通过特定的许可协议授权使用。使用者必须遵守这些协议条款，例如，不能修改或基于此规范创建衍生作品。 NFC技术规范，特别是NDEF部分，是理解如何在NFC设备间交换数据的关键。它不仅定义了数据格式，还规定了数据交换的流程，从而确保了不同设备间的互操作性。对于开发NFC应用或者需要集成NFC功能的产品来说，这份规范是不可或缺的参考材料。

NDEF Mechanisms

NDEF provides no support for error handling. It is up to the NDEF parser to determine the

implications of receiving a malformed NDEF message or an NDEF message containing a field

length beyond its processing capabilities. It is the responsibility of the user applications involved

to provide any additional functionality such as QoS that they may need as part of the overall

system in which they participate.

2.3 NDEF Encapsulation Constructs

2.3.1 Message

An NDEF message is composed of one or more NDEF records. The first record in a message is

marked with the MB (Message Begin) flag set and the last record in the message is marked with

the ME (Message End) flag set (see sections

3.2.1 and 3.2.2). The minimum message length is

one record which is achieved by setting both the MB and the ME flag in the same record. Note

that at least two record chunks are required in order to encode a chunked payload (see section

2.3.3). The maximum number of NDEF records that can be carried in an NDEF message is

unbounded.

NDEF messages MUST NOT overlap; that is, the MB and the ME flags MUST NOT be used to

nest NDEF messages. NDEF messages MAY be nested by carrying a full NDEF message as a

payload within an NDEF record.

NDEF Message

MB=1 … R

… R

ME=1

Figure 1. Example of an NDEF Message with a Set of Records

The message head is to the left and the tail to the right, with the logical record indices t > s > r >

1. The MB (Message Begin) flag is set in the first record (index 1) and the ME (Message End)

flag is set in the last record (index t).

Actual NDEF records do not carry an index number; the ordering is implicitly given by the order

in which the records are serialized. For example, if records are repackaged by an intermediate

application, then that application is responsible for ensuring that the order of records is preserved.

2.3.2 Record

A record is the unit for carrying a payload within an NDEF message. Each payload is described

by its own set of parameters (see section

2.4).

2.3.3 Record Chunks

A record chunk carries a chunk of a payload. Chunked payloads can be used to partition

dynamically generated content or very large entities into multiple subsequent record chunks

serialized within the same NDEF message.

Chunking is not a mechanism for introducing multiplexing or data streaming into NDEF and it

MUST NOT be used for those purposes. It is a mechanism to reduce the need for outbound

buffering on the generating side. This is similar to the message chunking mechanism defined in

HTTP/1.1 [RFC 2616].

An NDEF message can contain zero or more chunked payloads. Each chunked payload is

encoded as an initial record chunk followed by zero or more middle record chunks and finally by

NFC Data Exchange Format (NDEF) Page 8

NDEF Mechanisms

a terminating record chunk. Each record chunk is encoded as an NDEF record using the

following encoding rules:

• The initial record chunk is an NDEF record with the CF (Chunk Flag) flag set (see section

3.2.3). The type of the entire chunked payload MUST be indicated in the TYPE field

regardless of whether the PAYLOAD_LENGTH field value is zero or not. The ID field MAY

be used to carry an identifier of the entire chunked payload. The PAYLOAD_LENGTH field

of this initial record indicates the size of the data carried in the PAYLOAD field of the initial

record only, not the entire payload size (see section

2.4.1).

• Each middle record chunk is an NDEF record with the CF flag set indicating that this record

chunk contains the next chunk of data of the same type and with the same identifier as the

initial record chunk. The value of the TYPE_LENGTH and the IL fields MUST be zero and

the TNF (Type Name Format) field value MUST be 0x06 (Unchanged) (see section

3.2.6).

The PAYLOAD_LENGTH field indicates the size of the data carried in the PAYLOAD field

of this single middle record only (see section

2.4.1).

• The terminating record chunk is an NDEF record with the CF flag cleared, indicating that

this record chunk contains the last chunk of data of the same type and with the same identifier

as the initial record chunk. As with the middle record chunks, the value of the

TYPE_LENGTH and the IL fields MUST be zero and the TNF (Type Name Format) field

value MUST be 0x06 (Unchanged) (see section

3.2.6). The PAYLOAD_LENGTH field

indicates the size of the data carried in the PAYLOAD field of this terminating record chunk

(see section

2.4.1).

A chunked payload MUST be entirely encapsulated within a single NDEF message. That is, a

chunked payload MUST NOT span multiple NDEF messages. As a consequence, neither an

initial nor a middle record chunk can have the ME (Message End) flag set.

2.4 NDEF Payload Description

Each record contains information about the payload carried within it. This section introduces the

mechanisms by which these payloads are described.

2.4.1 Payload Length

Regardless of the relationship of a record to other records, the payload length always indicates the

length of the payload encapsulated in this record. The length of the payload is indicated in the

PAYLOAD_LENGTH field. The PAYLOAD_LENGTH field is one octet for short records and

four octets for normal records. Short records are indicated by setting the SR bit flag to a value of 1

(see section

3.2.4). Zero is a valid payload length.

2.4.2 Payload Type

The payload type of a record indicates the kind of data being carried in the payload of that record.

This may be used to guide the processing of the payload at the discretion of the user application.

The type of the first record, by convention, SHOULD provide the processing context not only for

the first record but for the whole NDEF message. Additional context for processing the message

MAY be provided, for example, by the link layer service access point (LSAP) or transport service

port (e.g. TCP, UDP, etc) at which the message was received and by other communication

parameters.

It is important to emphasize that NDEF mandates no specific processing model for NDEF

messages. The usage of the payload types is entirely at the discretion of the user application. The

NFC Data Exchange Format (NDEF) Page 9

NDEF Mechanisms

comments regarding usage above should be taken as guidelines for building processing

conventions, including mappings of higher level application semantics onto NDEF.

The format of the TYPE field value is indicated using the TNF (Type Name Format) field (see

section

3.2.6). This specification supports TYPE field values in the form of NFC Forum well-

known types, NFC Forum external types, absolute URIs [RFC 3986], and MIME media-type

constructs. The first allows for NFC Forum specified payload types supporting NFC Forum

reference applications [NFC RTD]; URIs provide for decentralized control of the value space;

media types allow NDEF to take advantage of the media type value space maintained by IANA

[RFC 1700].

The media type registration process is outlined in RFC 2048 [RFC 2048]. Use of non-registered

media types is discouraged. The URI scheme registration process is described in RFC 2717 [RFC

2717]. It is RECOMMENDED that only well-known URI schemes registered by IANA be used

(see [URI SCHEME] for a current list).

URIs can be used for message types that are defined by URIs. Records that carry a payload with

an XML-based message type MAY use the XML namespace identifier of the root element as the

TYPE field value. A SOAP/1.1 message, for example, may be represented by the URI

http://schemas.xmlsoap.org/soap/envelope/

NOTE: Encoding of URI characters which fall outside the US-ASCII range is left to the NDEF

application. Therefore, an NDEF parser must not assume any particular encoding for this field.

See [RFC 3986] and the specifications of particular protocol schemes (e.g. HTTP, URN, etc.) for

more information on parsing of URIs and character encoding requirements for non-ASCII

characters.

Records that carry a payload with an existing, registered media type SHOULD carry a TYPE

field value of that media type. The TYPE field indicates the type of the payload; it does NOT

refer to a MIME message that contains an entity of the given type. For example, the media type

image/jpeg

indicates that the payload is an image in JPEG format using JFIF encoding as defined by RFC

2046 [RFC 2046]. Similarly, the media type

message/http

indicates that the payload is an HTTP message as defined by RFC 2616 [RFC 2616]. The value

application/xml; charset=“utf-16”

indicates that the payload is an XML document as defined by RFC 3023 [RFC3023].

2.4.3 Payload Identification

The optional payload identifier allows user applications to identify the payload carried within an

NDEF record. By providing a payload identifier, it becomes possible for other payloads

supporting URI-based linking technologies to refer to that payload. NDEF does not mandate any

particular linking mechanism or format but leaves this to the user application to define in the

language it prefers.

It is important that payload identifiers are maintained so that references to those payloads are not

broken. If records are repackaged, for example, by an intermediate application, then that

application is responsible for ensuring that the linked relationship between identified payloads is

preserved.

NFC Data Exchange Format (NDEF) Page 10

剩余68页未读，继续阅读

喜欢听风的人

粉丝: 152
资源: 102

NFC技术规范详解：NDEF Technical Specification

NFC技术规范NFC技术规范 NFC技术规范 NFC技术规范

NFC标准技术规范文档

NFC 四大技术规范

NFC论坛模拟技术规范2.0版是如何规定NFC设备之间通信的电气特性的？请提供技术细节。

NFC论坛模拟技术规范2.0版对NFC设备的电气特性有哪些具体要求，以保证有效通信？

NFCForum发布的NFC数据交换格式技术规范NDEF 1.0版本具体包含哪些核心组件和技术特点？

如何根据NFC Forum Type 1 Tag技术规范，设计一款支持基本交互的NFC标签读写应用？请结合规范中的命令集进行说明。

如何基于NFC Forum Type 1 Tag技术规范设计一款支持基本交互的NFC标签读写应用？请提供详细的设计思路和关键步骤。

nfc reader tool电脑版

nfc analog technical specification 2.1

最新资源