译者：陈广 日期：2020-3-3
国际标准 ISO/IEC 18092，近场通信 - 接口与协议（NFCIP-1），为 13.56MHz 近耦合设备间的简单无线互联定义了接口和协议。
NFC 数据交换格式（NDEF）规范定义了一个 NFC 论坛设备与另一个 NFC 论坛设备或一个 NFC 标签进行信息交换的数据格式。通过 NDEF 交换的信息可以描述 NFC 论坛设备或 NFC 论坛标签提供哪些服务，它可以包含应用程序或特定于服务的参数和元数据，或者它可以描述 NFC 论坛设备或 NFC 论坛标签的功能。
NDEF 支持使用标准化的 MIME 内容类型和 URIs 来描述 NFC 论坛之外指定的记录内容。本规范描述了两种 NFC 论坛特定类型，称为“NFC 论坛知名类型”和“NFC 外部类型”。
NFC 数据交换格式（NDEF）规范是 NFC 论坛设备的通用数据格式。
NFC 数据交换格式规范定义了 NDEF 数据结构格式以及规则以构建有效的 NDEF 数据包作为 NDEF 记录集合。此外，它还定义了由不同方式构建唯一 NDEF 记录类型名称的机制，包括 NFC 论坛知名类型格式。
NDEF 规范只定义数据结构格式，以便以可互操作的方式交换应用程序或服务特定数据，并且没有详细定义任何记录类型。特定的记录类型在单独的文档中定义。
本规范的第一部分讲述 NFC 论坛知名类型的类型格式--即当“TNF”首部字段值为 0x01（NFC 知名类型）时，NDEF 类型字段的内容。
本规范的第二部分讲述被称为“NFC 外部类型”的第三方扩展类型，TNF首部字段值为 0x04。
确保 NFC 技术在各种设备中的互操作性是 NFC 论坛的使命。RTD 规范旨在通过提供一种方法来保留已知的记录类型和第三方扩展类型，从而支持 NFC 特定的应用程序和服务框架。
RTD 规范为在 NFC 论坛设备之间以及 NFC 论坛设备和 NFC 论坛标签之间交换的 NDEF 消息中包含已知类型的规范提供了指南。
实际类型注册不在本规范中提供，但预计将包括在其他文件中。
本节剩余略
NDEF 记录的记录类型字符串字段包含记录类型的名称（称为“record type name”）。记录类型名称由 NDEF 应用程序使用，用于标识记录内容的语义和结构。
记录类型名称可被指定为多种格式，称为类型名称格式，如 NDEF 记录首部的TNF字段所示。记录类型名称可以为 MIME 媒体类型、绝对 URIs，NFC 论坛外部类型名称，也可以为知名 NFC 类型名称（RTD 的本规范的主题）。
每个记录类型的定义是由它的记录类型名称来标识的。
记录类型名称可由 NFC 论坛以及第三方定义。在以下章节中，定义了控制 RTD 类型名称空间的规则。
NFC 论坛知名类型是一种密集的格式，用于为某种常见类型创建原语。它的意义在于在没有等效的 URI 或 MIME 类型可用的情况下使用，或者当消息大小限制需要一个非常短的名称时使用。
在 NDEF 规范中定义中，通过将记录的TNF字段值设置为 0x01 以便在 NDEF 消息中标识 NFC 论坛知名类型。
NFC 论坛知名类型是一个[RFC 2141]定义的 URN，具有命名空间标识符（NID）“nfc”。
NFC 知名类型 URN 的命名空间特定字符串前缀为“wkt:”。然而，在 NDEF 消息中编码时，知名类型必须被写为一个相对 URI 构造[RFC 3896]，省略 NID 和 “wkt:” 前缀。
例如，知名类型 “urn:nfc:wkt:a” 将被编码为 “a”。知名类型 “urn:nfc :wkt: Very-complicated-type” 将被编码为 “Very-complicated-type”。
后面章节将详细讨论两种 NFC 论坛知名类型。为了简洁起见，我们从示例中排除了 URN NID 和 NSS 前缀。
有关知名类型中使用的字符范围的定义，请参阅第3章。
NFC 论坛负责定义和管理 NFC 论坛全局类型。其它各方不得定义和重新定义它们。
NFC 论坛全局类型应当使用大写字节开始（字符范围<upper>）。例如 NFC 论坛全局类型：“U”、“Cfq”、“Trip-to -Texas”。
NFC 论坛本地类型应当以<Lower>或<number>集中的字母开始。
NFC 论坛本地类型在另一个记录的上下文中使用。当应用程序上下文不可用时，处理应用程序不能处理这些类型。当使用一个长的、基于域名的外部类型的负担太多时，就会使用本地类型，并且没有必要在本地上下文之外定义它的含义。
RTD 或应用程序定义了本地类型解释的上下文。本地类型可以由另一个应用程序在不同的上下文和不同的内容中重用。
例如 NFC 论坛本地类型：“0”、“foo”、“u”。
外部类型名称是为希望自我分配一个名称空间的组织指定的，以用于特定目的。
在 NDEF 记录中将TNF字段值设置为 0x04 可标识使用外部类型，如 NDEF 规范[NDEF]中所定义。
外部类型就像一个知名类型，如 URN、具有 NID 的“nfc”。然而，NSS 特定的部分被放入另一个名为“ext”的命名空间中。外部类型名称的规范版本看起来像：
urn:nfc:ext:example.com:f
外部类型名称必须通过获取发行组织的域名、添加冒号、然后添加由组织管理的类型名称来形成。
与知名类型一样，NDEF 消息中外部类型名称的二进制编码必须省略“ext”的 NID 和 NSS 前缀。
测试要求1：记录类型一般要求
| 定义为 RTD 记录的 NFC 论坛标准类型应使用 NFC 论坛知名类型名称。 |
| 当打包到 NDEF 记录中时，定义为 RTD 记录的 NFC 论坛标准类型应以 0x01（NFC论坛知名类型）的类型名称格式（TNF）字段值在 NDEF 记录首部中签名。 |
| NFC 知名类型应当为拥有“urn:nfc:wkt:”前缀的 URN |
| NFC 论坛全局类型不可以被 NFC 论坛以外的各方定义或重新定义 |
NFC 论坛全局类型应当以第3章定义的<upper>范围内的字符开始 |
NFC 论坛本地类型应当以第3章定义的<lower> 或 <number>范围内的字符开始 |
| 如果应用程序上下文不可用，则处理应用程序不能处理 NFC 论坛本地类型。 |
| NFC 论坛本地类型可以由另一个应用程序在不同的上下文和不同的内容中重用。 |
NFC 论坛外部类型应当以TNF字段值 0x04 进行标识 |
| NFC 论坛外部类型应当为以 “urn:nfc:ext” 为前缀的 URN |
| 在 NDEF 二进制格式中，不可使用 URN 前缀 |
| 外部类型必须通过获取发行组织的域名、添加冒号、然后添加类型名称来形成。外部类型必须包括冒号和非零长度类型名称。 |
本节定义了 NFC 论坛知名类型名称的规范要求（下面是 RTD-URI）。所使用的语言是 RFC 2234[RFC 2234]中定义的 ABNF 格式。
RTD-URI = “urn:nfc:” nfc-nss
nfc-nss = wkt-nss / external-nss
wkt-nss = wkt-id “:” WKT-type
external-nss = external-id “:” external-type
wkt-id = “wkt”
external-id = “ext”
WKT-type = local / global
local = ( lower / number ) *WKT-char
global = upper *WKT-char
external-type = dns-part “:” name-part
dns-part = 1*DNS-char
name-part = 1*WKT-char
WKT-char = upper / lower / number / other
DNS-char = upper / lower / number / “.” / “-”
upper = “A” / “B” / “C” / “D” / “E” / “F” / “G” / “H” /
“I” / “J” / “K” / “L” / “M” / “N” / “O” / “P” /
“Q” / “R” / “S” / “T” / “U” / “V” / “W” / “X” /
“Y” / “Z”
lower = “a” / “b” / “c” / “d” / “e” / “f” / “g” / “h” /
“i” / “j” / “k” / “l” / “m” / “n” / “o” / “p” /
“q” / “r” / “s” / “t” / “u” / “v” / “w” / “x” /
“y” / “z”
number = “0” / “1” / “2” / “3” / “4” / “5” / “6” / “7” /
“8” / “9”
other = “(“ / “)” / “+” / “,” / “-” /
“:” / “=“ / “@” / “;” / “$” /
“_” / “!” / “*” / “'“ / “.”
reserved = “%” / “/” / “?” / “#”
NDEF 的知名类型和外部类型名称的二进制编码必须根据附录 A 中的 ASCII 表进行。
URN NID 和 NFC NSS 前缀不可被包含在二进制 NDEF 格式中。（尽管如此，如果 RTD 如果在其它格式中使用，如 XML，）
注意：本规范不定义任何特定记录内容的合法字符。记录内容在其它文档中指定，特定于这些记录类型。
为了帮助定义 NFC 论坛知名类型的等价规则，NFC论坛不会发布使用[RFC 2141]中定义的百分比编码的全局类型名称。任何由第三方使用的本地类型名称不可使用百分比编码。
外部类型不应使用百分比编码。但是，使用这样一种外部类型的应用程序必须首先对 UTF-8 中的字符串进行编码，然后才能将其转换为百分比编码。
记录类型名称的比较是在逐个字符的基础上完成的。
两个知名类型名称必须以区分大小写的方式进行比较。由于编码是固定在 US-ASCII 上的，这也意味着两种知名类型当且仅当它们的二进制表示是相同时，才会被认为是相等的。
例如：
“Foobar”
“fooBar”
“fOoBaR”
“foobar”
以上4个例子是不同的知名类型名称。
两个外部类型名称必须以不区分大小写的方式进行比较，如：
“example.com:foobar”
“Example.com:foobar”
“Example.COM:Foobar”
“eXaMpLe.CoM:fOoBaR”
以上四个例子表现同一外部类型名称。
测试要求2：RTD 类型名称要求
| 知名类型（包括全局和本地名称）以及外部类型名称的二进制编码必须按照附录 A 中的 ASCII 表进行。 |
| 知名类型（包括全局和本地名称）不可使用 RFC 2141 中定义的百分比编码。 |
| 外部类型不应当使用 RFC 2141 定义的百分比编码。 |
| 两种知名类型（包括全局和本地名称）必须在逐字的基础上以区分大小写的方式进行对比。换句话说，当且仅当两种知名类型的二进制表示相同，它们才是相等的。 |
| 两种外部类型必须在不区分大小写、逐个字符的基础上进行比较。 |
如果一条记录的类型名称包含的字符超出第3章中定义的字符有效范围，则必须忽略它。
如果应用程序不能识别记录中的知名类型或外部类型，则必须忽略它们。
测试要求3：错误处理要求
| 任何未在第 3 章中定义为有效的字符，应视为记录类型名称中的非法字符。 |
| 如果记录类型名称中包含非法字符，则该记录必须被忽略。 |
| 如果应用程序无法识别记录类型名称，则必须忽略整条记录。 |
记录类型名称应由美国 ASCII [ASCII]字符集的字符组成。如下表所示，F十进制 [0 - 31] 和 127 号字符不得用于记录类型名称。
表3：ASCII 字符表
Binary Dec Hex Graph. Binary Dec Hex Graph. Binary Dec Hex Graph.
0010 0000 32 20 (blank) 0100 0000 64 40 @ 0110 0000 96 60 `
0010 0001 33 21 ! 0100 0001 65 41 A 0110 0001 97 61 a
0010 0010 34 22 “ 0100 0010 66 42 B 0110 0010 98 62 b
0010 0011 35 23 # 0100 0011 67 43 C 0110 0011 99 63 c
0010 0100 36 24 $ 0100 0100 68 44 D 0110 0100 100 64 d
0010 0101 37 25 % 0100 0101 69 45 E 0110 0101 101 65 e
0010 0110 38 26 & 0100 0110 70 46 F 0110 0110 102 66 f
0010 0111 39 27 ’ 0100 0111 71 47 G 0110 0111 103 67 g
0010 1000 40 28 ( 0100 1000 72 48 H 0110 1000 104 68 h
0010 1001 41 29 ) 0100 1001 73 49 I 0110 1001 105 69 i
0010 1010 42 2A * 0100 1010 74 4A J 0110 1010 106 6A j
0010 1011 43 2B + 0100 1011 75 4B K 0110 1011 107 6B k
0010 1100 44 2C , 0100 1100 76 4C L 0110 1100 108 6C l
0010 1101 45 2D - 0100 1101 77 4D M 0110 1101 109 6D m
0010 1110 46 2E . 0100 1110 78 4E N 0110 1110 110 6E n
0010 1111 47 2F / 0100 1111 79 4F O 0110 1111 111 6F o
0011 0000 48 30 0 0101 0000 80 50 P 0111 0000 112 70 p
0011 0001 49 31 1 0101 0001 81 51 Q 0111 0001 113 71 q
0011 0010 50 32 2 0101 0010 82 52 R 0111 0010 114 72 r
0011 0011 51 33 3 0101 0011 83 53 S 0111 0011 115 73 s
0011 0100 52 34 4 0101 0100 84 54 T 0111 0100 116 74 t
0011 0101 53 35 5 0101 0101 85 55 U 0111 0101 117 75 u
0011 0110 54 36 6 0101 0110 86 56 V 0111 0110 118 76 v
0011 0111 55 37 7 0101 0111 87 57 W 0111 0111 119 77 w
0011 1000 56 38 8 0101 1000 88 58 X 0111 1000 120 78 x
0011 1001 57 39 9 0101 1001 89 59 Y 0111 1001 121 79 y
0011 1010 58 3A : 0101 1010 90 5A Z 0111 1010 122 7A z
0011 1011 59 3B ; 0101 1011 91 5B [ 0111 1011 123 7B {
0011 1100 60 3C < 0101 1100 92 5C \ 0111 1100 124 7C |
0011 1101 61 3D = 0101 1101 93 5D ] 0111 1101 125 7D }
0011 1110 62 3E > 0101 1110 94 5E ^ 0111 1110 126 7E ~
0011 1111 63 3F ? 0101 1111 95 5F _
本附录的内容是信息丰富的，它描述了编码和比较记录类型名称到它们的二进制表示的示例。
将记录类型名称转换为二进制表示的示例：
表 4：转换记录类型名称为二进制表示
| 字符串表示 | 二进制表示（十六进制） |
|---|---|
| Sms | 53 6D 73 |
| sms | 73 6D 73 |
要编码类型名称的二进制表示，将字符串表示中的第个字符替换为附录 A 中的对应的二进制值。
在本例中，两个记录类型名称被认为是不同的，因为它们的二进制表示不相等。在比较类型字符串等价时，不考虑字符串、空白和其他语言比较规则中的字母大小写。只考虑二进制表示。
本附录内容是信息丰富的。
有两种基本方法可以相互关联 NDEF 记录。第一个称为“引用关联”，它相当于一个扁平的层次结构或一个对象列表。
当通过引用关联记录时，上下文通常由消息中的第一个记录给出。这以 MIME 所使用的关联模型相同。例如，如果您希望将具有两个 PNG 附件的电子邮件表示为 NDEF 消息，则首先将电子邮件装入一条记录（message/RFC822），然后将第一个 PNG 图像作为单独的记录（image/PNG），第二个 PNG 图像作为单独记录（image/PNG）。举例说明：
此方法允许应用程序将 PNG 图像从消息中移除，即使它不理解电子邮件。一般来说，在设计您自己的记录类型时，如果您的消息部分即使是单独的，也是有价值的，也就是说，即使上下文不被理解，您也应该通过引用来选择关联。如果您正在移动大量数据，则引用关联也是一个很好的模型，因为它允许您利用 NDEF 的分块特性。此外，它还允许处理在消息完成之前从接收端开始（这就是为什么在消息开始时声明上下文是好的原因之一）。
第二种方法称为“遏制关联”。这是一个分层模型（与 XML 或 HTML 完全不同），其中 NDEF 记录的内容部分包含 NDEF 消息。当您希望在记录间暗示强关系，或需要序列化已经是分层格式的信息，这是非常有用的。此外，如果您要在消息中发送同一类型的多个对象，您可能希望使用遏制模型，然后将它们串在一个列表中（所以是的，混合这些模型是可能的和非常明智的）。
例如，智能海报记录定义了一个 URI 加上一些关于该 URI 的附加元数据。添加的元数据对于没有 URI 本身的应用程序并不有用，事实上，它将是相对无意义的。举例说明：
这种情况下，NDEF 消息有两条记录。第一条是智能海报，包含一个 URI、一个标题文本记录、一个操作和一个配置记录；而另一个只是一个普通的 vCard（使用 vCard 标准）。（在这种情况下，没有为 vCard 定义特定的上下文，因此应用程序可以忽略它，也可以将其用于某种目的；这是一个实现细节。一般来说，让记录描述不同事物、假设某些特定的上下文或处理模型可能会导致互操作性问题。）
无论如何，由于文本、操作和配置与 URI 紧密耦合（如果没有适当的配置，URI 甚至可能无法获取，如果配置定义了本地访问点），它们使用遏制模型比引用模型工作得更好。
这些例子都没有显示 ID 字段的任何使用，它可以在两个模型中以相同的效率使用。通过引用关联，第一个记录通常列出它使用的 ID，并以这种方式定义上下文；在使用遏制关联时，ID 通常被用来表示记录的作用（例如，“应使用 ID 为‘config’的记录来定义访问点。）
当然，应用程序可以自由地混合和匹配这些关联类型。在给定的情况下，没有有力而快速的规则可以说哪一个更好，而且按照设计，它允许应用程序开发人员具有最大的灵活性。
第三种方法不造成使用，作法是使用排序（例如，记录 #1 总是表示某些东西，记录 #2 表示其它东西，记录 #3 又表示其它东西），但这在通常情况下不是一个好主意，因为你不能依赖 NDEF 处理器的任何特定行为。有可能当您的应用程序接收到 NDEF 消息时，记录可能已经被插入或删除。不要依赖于任何特定于实现的行为。这在任何经验丰富的开发人员看来都是显而易见的，但在匆忙的最后期限中很容易忘记。
在这次讨论中提出的建议是因为开发人员很可能在某一时刻面临着将 NDEF 记录相互关联的需要，并且很好地为所有人提供了一些最佳实践和约定。阅读一个新的规范可能是困难的，希望像这样的讨论将减轻开发人员的工作。
;