NFC手机钱包开发关键：NDEF技术规范解析

5星 · 超过95%的资源需积分: 50 177 浏览量更新于2024-07-24 收藏 579KB PDF 举报

"NFC NDEF Specification是NFC Forum发布的NFCDataExchangeFormat（NDEF）技术规范，适用于Android手机钱包开发。" NFC（Near Field Communication，近场通信）是一种短距离无线通信技术，允许设备在几厘米的距离内进行数据交换。NDEF（NFC Data Exchange Format）是NFC论坛定义的一种标准数据格式，它使得不同设备之间可以方便地共享各种类型的数据，如文本、URL、名片、图片等。 NDEF规范1.0版本（NFCForum-TS-NDEF_1.0）详细规定了如何在NFC标签、读卡器和设备之间交换数据。它定义了数据结构、消息和记录的创建、解析以及验证的规则。NDEF使得数据的封装和解封装过程标准化，从而提高了跨平台和跨设备的数据兼容性。 NDEF消息由一个或多个NDEF记录组成。每个记录都有其特定的类型，例如，Text Record用于存储文本信息，URI Record用于存储统一资源标识符，Smart Poster Record则包含一个URI和可选的标题文本，用于表示一种互动式的海报。此外，NDEF还支持自定义记录类型，以便扩展到更多种类的数据交换。在Android平台上，NDEF对于手机钱包应用尤其重要，因为它允许用户通过NFC技术轻松地进行支付、票务、会员卡等操作。开发者可以利用Android的NFC API来创建和解析NDEF消息，实现与NFC标签的交互。例如，通过`NdefRecord.createMime()`方法创建自定义MIME类型的数据记录，或者使用`NdefMessage`类来构建完整的NDEF消息。在使用NDEF规范时，需要注意版权和许可协议。NFC Forum对这份技术规范拥有版权，并要求使用者遵循特定的许可条款。通常，这包括仅限内部使用、不允许修改或创建衍生作品等限制。如果需要使用该规范，应访问NFC Forum的官方网站并同意当时的许可条款。 NFC NDEF Specification是NFC技术中的核心组件，它为数据交换提供了一种标准化的方式，对于开发基于NFC功能的应用，尤其是Android手机钱包应用，具有至关重要的作用。理解并熟练运用NDEF规范，能够帮助开发者构建高效、兼容性强的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页未读，继续阅读

拼客

粉丝: 0
资源: 1

NFC手机钱包开发关键：NDEF技术规范解析

NFC规范（NFC Forum Specifications）

NFC Data Exchange Format (NDEF) Technical Specification.zip

Specification（NFC规范）

NFC Simple NDEF Exchange Protocol Specification

NFC tech specification

NFC forum specification

NFC Forum Specification

NFC技术规范详解：NDEF Technical Specification

nfc data exchange format (ndef) technical specification

Android NDEF Push Protocol Specification

最新资源